Reputation: 5652
Some DLLs are special and the operating system will load the official installed copy regardless of whether another file by that name is found on the PATH.
What makes it special?
On versions of Windows earlier than Win10, the “universal CRT” might be installed via a MS-supplied official installer. Does that just happen to put it in the System32 directory where it is found, or does it also make it special?
Likewise for the compiler RTL redistributals (msvcp140.dll, vccorlib140.dll, vcruntime140.dll).
I suspect that programs that drop these locally, in the same directory as the EXE, and put that directory on the PATH, are causing load errors in unrelated programs that don't. In particular, if one of the DLLs is found along the path and is the wrong platform (32-bit vs 64-bit) that will cause a cryptic dialog box to appear when the program attempts to run.
Even though local installation of the aforementioned DLLs is discouraged in favor of using the official installers, does that actually work or will every app need to install locally to prevent being damaged by completely unrelated programs on the PATH?
How can a "local install" program (that is, just unpacking everything into a directory and running from there) cope? I'm especially interested in VS2015, 32-bit, and supporting the largest variety of old operating systems.
Upvotes: 0
Views: 61
Reputation: 5652
I realized that this works because
So, if DLL searching simply follows the documented rules, other programs on the PATH will not poison the DLL loading in the case where the DLL is in fact properly installed.
I have not checked in detail to see if any of the DLLs of interest have magical behavior beyond that, such that it will ignore load-ordering and search options that would cause some other file to be found in a mundane DLL. But I expect that the ms-api-* files that are known to the OS are indeed hard-wired (and those not known to an older OS are mundane).
Upvotes: 0