Unable to load DLL with dependencies in the same directory when using fully qualified path name

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Unable to load DLL with dependencies in the same directory when using fully qualified path name

Richard Sargent
Administrator
I have found that under Windows 10, specifying a fully qualified DLL file name has problems if the DLL depends on other DLLs in its directory.

I think this is due to a "recent" change in DLL search order. See https://docs.microsoft.com/en-us/windows/win32/dlls/dynamic-link-library-search-order.
If a DLL has dependencies, the system searches for the dependent DLLs as if they were loaded with just their module names. This is true even if the first DLL was loaded by specifying a full path.

It looks like VMprPlatformLibraryPrimGetAddress may be responsible for actually loading the DLL

Previously, I published a short script for checking whether a DLL is loadable. It relied on #loadLibrary:. Unfortunately, it could not tell you why the DLL wasn't loadable, only that it could or could not be loaded. #loadModule: under Windows 10 seems incapable of loading the GemStone/S GCI RPC library DLL when using a fully qualified path name.

I have determined that OSHmodule class>>#loadLibraryEx:hFile:dwFlags: is capable of loading that same DLL when the flags LOAD_LIBRARY_SEARCH_DLL_LOAD_DIR and LOAD_LIBRARY_SEARCH_DEFAULT_DIRS are provided. (16r00000100 and  16r00001000, respectively).


I expect to be able to work around this problem for GBS by explicitly loading the module when I first attempt to use it, rather than let VAST do so. However, this strikes me as something that should be corrected in VAST, too. I know the problem has affected others over the years.
Enter code here...


--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/va-smalltalk/c9e511ff-2333-4544-a1a9-4f062f0f1376%40googlegroups.com.
Reply | Threaded
Open this post in threaded view
|

Re: Unable to load DLL with dependencies in the same directory when using fully qualified path name

Richard Sargent
Administrator
Attaching the script, for people to be able to find and use.

On Wednesday, April 15, 2020 at 1:31:42 PM UTC-7, Richard Sargent wrote:
I have found that under Windows 10, specifying a fully qualified DLL file name has problems if the DLL depends on other DLLs in its directory.

I think this is due to a "recent" change in DLL search order. See <a href="https://docs.microsoft.com/en-us/windows/win32/dlls/dynamic-link-library-search-order" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fwindows%2Fwin32%2Fdlls%2Fdynamic-link-library-search-order\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGUQCMPevIBehace-Cfk_mgt1I4Sg&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fwindows%2Fwin32%2Fdlls%2Fdynamic-link-library-search-order\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGUQCMPevIBehace-Cfk_mgt1I4Sg&#39;;return true;">https://docs.microsoft.com/en-us/windows/win32/dlls/dynamic-link-library-search-order.
If a DLL has dependencies, the system searches for the dependent DLLs as if they were loaded with just their module names. This is true even if the first DLL was loaded by specifying a full path.

It looks like VMprPlatformLibraryPrimGetAddress may be responsible for actually loading the DLL

Previously, I published a short script for checking whether a DLL is loadable. It relied on #loadLibrary:. Unfortunately, it could not tell you why the DLL wasn't loadable, only that it could or could not be loaded. #loadModule: under Windows 10 seems incapable of loading the GemStone/S GCI RPC library DLL when using a fully qualified path name.

I have determined that OSHmodule class>>#loadLibraryEx:hFile:dwFlags: is capable of loading that same DLL when the flags LOAD_LIBRARY_SEARCH_DLL_LOAD_DIR and LOAD_LIBRARY_SEARCH_DEFAULT_DIRS are provided. (16r00000100 and  16r00001000, respectively).


I expect to be able to work around this problem for GBS by explicitly loading the module when I first attempt to use it, rather than let VAST do so. However, this strikes me as something that should be corrected in VAST, too. I know the problem has affected others over the years.
Enter code here...


--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/va-smalltalk/f1238ef2-60dc-4fd4-9a64-d85b6e61f531%40googlegroups.com.

ValidateLoadableDLLExtended.st (725 bytes) Download Attachment