Problem running IRender after loading Twilight.

Al Hart

I ran SketchUp through ProcMon to watch what libraries are getting loaded when NXT works and when it doesn't. It appears that when it doesn't work, Windows is unable to locate the arobjects.dll. Why having Twilight running makes any difference for that, I can't imagine. Certainly Twilight is not actively impacting it. It doesn't appear to be a VC++ problem either (thought I'm not certain), as you can see the 2005 (VC8) dlls are loaded in the images.

Sorry, yes, I meant IRender.

Thanks Chris,

This could be a big help. It may be something simple, like that the problem is that the Twilight DLL is changing the default folder in Windows, and we just need to change it back before loading our DLL.

Chris_at_Twilight

I think I've got it. Twilight adds it's own directory to the DLL search path. According to Microsoft documentation, simply adding a directory to the search path (not changing, just adding), switches the DLL search mode from "Default". Probably IRender is not setting it's own search paths, but relying on the "default". You can see more about it here: http://msdn.microsoft.com/en-us/library/ms686203%28VS.85%29.aspx

I've modified Twilight to restore the "default" search mode and IRender works after that. However, if there are any plugins loaded before Twilight who are using a modified dll search path, switching to "default" mode can impact them in the same way. So either way, there is no really "safe" method. One way or the other has a potential to impact other plugins. As notareal said, dll hell.

I guess the best "safe" practice is to set your own dll search path, load your dll, then restore to the default. If everyone did that it would probably avoid all these issues.

Al Hart

@chris_at_twilight said:

Certainly Twilight is not actively impacting it.

With Twilight not loaded, it looks for arobjects.dll in:

c:\Program Files\Google\SketchUp 7, --- then in
c:\Windows\system32
c:\Windows\system
c:\Windows, --- and then in the current folder,
c:\Program Files\Render Plus Systems\IRender_nXt\bin_nxt
(where it finds it)

With Twilight loaded, it looks in

c:\Program Files\Google\SketchUp 7, --- then in
c:\Program Files\Google\SketchUp 7\Twilight, --- then
c:\Windows\system32
c:\Windows\system
c:\Windows,

but never in c:\Program Files\Render Plus System

Does Twilight make a ruby call, or a Windows call, to change the DLL search path?
(I am wondering because it looks in the twilight folder before the windows folder)

If so, then we could make a similar call to add "c:\Program Files\Render Plus Systems\IRender_nXt\bin_nxt" to the DLL search path.

Thanks,

Chris_at_Twilight

@al hart said:

@chris_at_twilight said:

Certainly Twilight is not actively impacting it.

Does Twilight make a ruby call, or a Windows call, to change the DLL search path?
(I am wondering because it looks in the twilight folder before the windows folder)

If so, then we could make a similar call to add "c:\Program Files\Render Plus Systems\IRender_nXt\bin_nxt" to the DLL search path.
Thanks,

Yes, exactly. If you set your search path immediately before loading the dll, that should resolve the problem. This is probably a good idea no matter what because, according to Microsoft, the DLL search that is finding the arobjects.dll is looking in the "current path". Since many things can influence the current path, it's probably not safe to rely too much on it.

I've added code to Twilight to restore the "default" search path immediately after loading the dll, and that seems to work well, so I suggest doing that also.

Al Hart

@chris_at_twilight said:

I've added code to Twilight to restore the "default" search path immediately after loading the dll, and that seems to work well, so I suggest doing that also.

I presume you are doing this in Ruby.

I suspect you are not restoring the search path, because Twilight still seems to be in it when IRender nXt is trying to load its DLL.

Can you send the two lines of Ruby code? (set path and restore path).
I want to see why the restore path is (apparently) not working.

Al Hart

@chris_at_twilight said:

If you set your search path immediately before loading the dll, that should resolve the problem.

Thanks for your help on this, we are setting ENV["PATH"] before loading the DLL and it seems to work better now.

Chris_at_Twilight

Sorry for the confusion. I meant, with the next release, this will be added. The current publicly available release does not 'reset' the dll search path.

The code I'm using is Windows API. SetDllDirectory (more on it here: http://msdn.microsoft.com/en-us/library/ms686203%28VS.85%29.aspx)

Al Hart

@chris_at_twilight said:

Sorry for the confusion. I meant, with the next release, this will be added. The current publicly available release does not 'reset' the dll search path.

The code I'm using is Windows API. SetDllDirectory (more on it here: http://msdn.microsoft.com/en-us/library/ms686203%28VS.85%29.aspx)

AHA.

I turns out that we were using SetCurrentDirectory() to define the DLL path, and depending on the LoadLibrary defaults which include the current directory.

When you call SetDllDirectory(), with a path name, the current directory is no longer used, so our logic no longer worked.

If you had called SetDllDirectory() again with a blank name to reset it, then the current directory logic is restored. So that is what was causing the original problem.

We are going to switch to using SetDllDirectory() ourselves, which will eliminate this problem, but we both need to be carefull to reset it so we don't mess up anyone else who is depending on the current directory method of loading DLLs

Chris_at_Twilight

@al hart said:

We are going to switch to using SetDllDirectory() ourselves, which will eliminate this problem, but we both need to be carefull to reset it so we don't mess up anyone else who is depending on the current directory method of loading DLLs

@chris_at_twilight said:

I've added code to Twilight to restore the "default" search path immediately after loading the dll, and that seems to work well, so I suggest doing that also.

My suggestion exactly. It's already been implemented in Twilight and will be in place in the next release.

Al Hart

We have released new versions of IRender nXt which fix this problem.

Thanks for your help Chris.