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

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.

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...