ntdll/kernel32: LoadLibrary fails to load some dependent libs

Clinton Stimpson cjstimpson at utwire.net
Sat Apr 7 00:46:11 CDT 2007

Vitaliy Margolen wrote:
> Clinton Stimpson wrote:
>> So I have this case:
>> An application that can load libraries at runtime (plugins).
>> Plugins reside in a different directory than the application directory.
>> Some plugins have dependent dlls found only in the plugin directory.
>> Wine fails to load the dependent dlls.
>> I can copy the dependent dlls into the application directory and the
>> plugins load successfully.
> How are you starting your application? With what exact command from what
> directory?
> Also please check if you have
> [HKLM\Software\Microsoft\Windows\CurrentVersion\App Paths\<app.exe>] key
> and if you have, try running you program with the following command
> (replacing "app.exe" with the executable name):
> cd ~ && wine start app.exe
>> I traced the execution into ntdll/loader.c : load_native_dll
>> load_path included the the application directory and some system paths.
>> name is the full path of the library to load.
>> The call to fixup_imports fails.
>> Should the path to the library be added to load_path in
>> load_native_dll?  Or is there another appropriate way to fix this?
> This doesn't sound to be correct. You need to make a test first and
> verify it's functionality on windows first.
> Vitaliy

Well, I went and made a couple dlls to try on Windows, and apparently 
Windows doesn't do what I thought it did.  I thought I had seen that 
behavior before (but I guess the app I thought I saw it in was modifying 
the PATH environment variable at run time).

Anyway, the dependent library is MFC42.dll.  On Windows, I had one in 
the system32 folder.  I tried to delete it to figure out the behavior, 
but Windows always restores it immediately.  So I guess that's the 
reason it works on Windows.

In Wine, I don't have a MFC42.dll in the system32 folder.

Thanks anyway for your time.


More information about the wine-devel mailing list