Plugin DLL dependencies

gigaman · Post by *gigaman » 2007-01-21, 20:12 UTC

The solution is actually quite simple - you shouldn't use LoadLibrary(dll_file), but rather LoadLibraryEx(dll_file, NULL, LOAD_WITH_ALTERED_SEARCH_PATH) - then the 3rd (statically linked) library would be loaded from the same directory as the plugin file - see here. The SetCurrentDirectory() trick probably works, but current directory is a process-wide setting, i.e. it might interfere with other threads, even if you set the original "current directory" back after you have loaded your library.

I still don't understand why Total Commander itself uses LoadLibrary() to load the plugins, instead of LoadLibraryEx with this flag; I'd almost call it a bug.

tbeu · Post by *tbeu » 2007-01-22, 07:54 UTC

gigaman wrote:I still don't understand why Total Commander itself uses LoadLibrary() to load the plugins, instead of LoadLibraryEx with this flag; I'd almost call it a bug.

Thank you, gigaman! You are absolutely right. If TC loads the plugin with alternate search order everything would just be fine and no dirty hacks are necessary. I believe LoadLibraryEx() is used by EFCommander as I did not experience such problems there.

Post by *ghisler(Author) » 2007-01-22, 20:45 UTC

LOAD_WITH_ALTERED_SEARCH_PATH

That's indeed an interesting idea. I wonder if it could have any negative impact on existing plugins if I changed from LoadLibrary to LoadLibraryEx...

tbeu · Post by *tbeu » 2007-01-23, 09:17 UTC

ghisler(Author) wrote:I wonder if it could have any negative impact on existing plugins if I changed from LoadLibrary to LoadLibraryEx...

Let us see in one more beta.

gigaman · Post by *gigaman » 2007-01-23, 21:27 UTC

ghisler(Author) wrote:
LOAD_WITH_ALTERED_SEARCH_PATH
That's indeed an interesting idea. I wonder if it could have any negative impact on existing plugins if I changed from LoadLibrary to LoadLibraryEx...

Well, normally it shouldn't cause any problems - but if somebody tuned their file/folder structure (of installed plugins) to work with LoadLibrary - then it would stop working (I mean, if somebody installed a plugin into a separate subfolder and then copied the needed statically linked libraries into the main TC folder - cause it wouldn't work otherwise). But I guess it's quite a rare case.

glipman · Post by *glipman » 2007-02-07, 22:48 UTC

This might also be a solution for my problem.

I have developed a viewer with Microsoft Visual Studio 2005. The WLX now depends on Microsoft's runtime libraries MSVCR80.DLL and MSVCP80.DLL.

Microsoft wants me to use an installer to install the DLL's somewhere around Windows\System32. For a simple install in Total Commander I prefer to put the DLL's next to my own WLX. However, they are currently only found when I put them in the same folder as Totcmd.exe.

When LoadLibraryEx is used I think I can put them next to my DLL, perhaps together with a manifest file.
It would certainly make my life a lot easier...

glipman · Post by *glipman » 2007-02-07, 22:55 UTC

ghisler(Author) wrote:
LOAD_WITH_ALTERED_SEARCH_PATH
That's indeed an interesting idea. I wonder if it could have any negative impact on existing plugins if I changed from LoadLibrary to LoadLibraryEx...

What about testing for a 'magic' file (eg. TOTCMD_LOAD_WITH_ALTERED_SEARCH_PATH.TXT) next to the WLX. When that file is found you use LoadLibraryEx. When it is not present you use the original LoadLibrary. This is backwards compatible with older plugins and advanced plugin developers can have it their way.
Another option: TOTCMDPLUGIN.INI next to the WLX with specific settings for the WLX. This would perhaps allow more features in the future.

Microsoft uses similar tricks with App_name.local or manifest files.

gigaman · Post by *gigaman » 2007-02-08, 22:17 UTC

glipman wrote:I have developed a viewer with Microsoft Visual Studio 2005. The WLX now depends on Microsoft's runtime libraries MSVCR80.DLL and MSVCP80.DLL.

I'm quite suprised it works at all. As I understand it, VC8 DLLs (such as MCVCR80.DLL) have a strange feature - on load, they check the main application executable and if it doesn't have the corresponding manifest, they show the R6034 error and fail to load.
So, I'd certainly suggest to use a static link for VC8-developed DLLs that are going to be used in non-VC8 applications (such as various plugins).

tbeu · Post by *tbeu » 2007-03-01, 07:39 UTC

ghisler(Author) wrote:LOAD_WITH_ALTERED_SEARCH_PATH

Any changes here in TC7PB4? At least not from the history.txt.

Post by *ghisler(Author) » 2007-03-02, 09:24 UTC

I haven't changed that because of the mixed reactions to this proposal here in the forum. The danger is high that _something_ will break in one of the hundreds of available plugins.

gigaman · Post by *gigaman » 2007-03-04, 15:25 UTC

How about an INI file option that would change the loading method, if the user really wants it? (such as me

)

Post by *ghisler(Author) » 2007-03-05, 19:49 UTC

Hmm, maybe - but I noticed something strange: A user has sent me his plugin source for testing. In this source, he tries to load a DLL from his plugin with LoadLibrary(..,LOAD_WITH_ALTERED_SEARCH_PATH). This works fine on Windows 2000 when the DLLs are in the plugin directory. However, it fails on Windows XP, I had to move the dlls to the system32 directory! Any ideas? Maybe this parameter isn't supported on XP?

gigaman · Post by *gigaman » 2007-03-05, 22:50 UTC

The parameter certainly is supported on XP and later.
http://msdn2.microsoft.com/en-us/library/ms682586.aspx

The difference between W2k and XP SP2 might be the "safe dll search mode" - but that shouldn't apply here...

Don't know... maybe some of the dependent DLLs used a different loading method and somehow caused a problem? Hard to say without the source...