On Mon, Oct 10, 2016 at 5:28 PM, Billy O'Neal (VC LIBS)
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.