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