Can't the newer global msvcp140.dll override this older local one?
Nope. The loader doesn't do version comparisons. (And even if we could convince Windows to change the loader to do that, there's no way they're going to backport such a change to all the platforms we support) Once a copy of that DLL is in the process further calls to LoadLibrary with the same DLL name return a reference to the already loaded copy. The search order the system uses is: https://msdn.microsoft.com/en-us/library/windows/desktop/ms682586(v=vs.85).a... 1. The directory from which the application loaded. 2. The system directory. Use the GetSystemDirectoryhttps://msdn.microsoft.com/en-us/library/windows/desktop/ms724373(v=vs.85).a... function to get the path of this directory. 3. The 16-bit system directory. There is no function that obtains the path of this directory, but it is searched. 4. The Windows directory. Use the GetWindowsDirectoryhttps://msdn.microsoft.com/en-us/library/windows/desktop/ms724454(v=vs.85).a... function to get the path of this directory. 5. The current directory. 6. The directories that are listed in the PATH environment variable. Note that this does not include the per-application path specified by the App Paths registry key. The App Paths key is not used when computing the DLL search path. So app-local "wins". We could KnownDll https://blogs.msdn.microsoft.com/larryosterman/2004/07/19/what-are-known-dll... the thing which would mean let the system version override the app-local version, but that breaks in the other direction -- older system DLL with newer app-local deployed copy would cause the app depending on the new exports to load the system32 one instead and fail due to missing exports.
Don't kill stuff, offer users a better way to do it instead.
We're open to suggestions :). We've been saying the "better way" is the redist, or static linking, for years.
Of course, that'd have to work on W7 as well, not just W10.
Even if the redist was bundled with the OS that still wouldn't help here, because Win7 shipped ~6 years before VS2015 :). Time machines and all that.
Billy3
________________________________
From: Boost
Feedback from customers was that breaking bincompat every year was too rapid.
What's the problem for them? Most of the time there's two years between releases anyway and VS15 is unlikely to be released this year, so 2017 - 2015 > 1 ;)
We don't want to get into maintaining a bunch of separate forks. We are still maintaining, providing bugfixes for, and adding new features (like <variant>, <any>,
) to 140; 150 is not yet ready to ship.
Why adding export symbols for char16_t and char32_t is considered a breakage?
2. An application is installed which uses a previous copy of msvcp140.dll, such as that shipping now with Visual Studio 2015 RTM.
Can't the newer global msvcp140.dll override this older local one?
This is why we tried very hard to kill support for app-local DLL deployment, so that we could add features and bugfixes the same way the operating system does e.g. for kernel32.dll, but that was received badly.
Don't kill stuff, offer users a better way to do it instead. Personally I link the runtime statically :p but if Windows could take care of installing the redist DLLs for me I'd use that instead. Of course, that'd have to work on W7 as well, not just W10. _______________________________________________ Unsubscribe & other changes: https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.boost.org%2Fmailman%2Flistinfo.cgi%2Fboost&data=01%7C01%7Cbion%40microsoft.com%7Cc1fa5d22f7bf45ee0a4008d3f20c4073%7C72f988bf86f141af91ab2d7cd011db47%7C1&sdata=v%2F3MwTGvEi7Za6jZzgOH8%2FSbktz9U03n6Tr%2FpxCcoys%3D&reserved=0