Boost logo

Boost :

Subject: Re: [boost] [config] Changes to reflect Visual C++ "15" preview 5
From: Billy O'Neal (VC LIBS) (bion_at_[hidden])
Date: 2016-10-11 15:36:06


>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).aspx#standard_search_order_for_desktop_applications

  1. The directory from which the application loaded.
  2. The system directory. Use the GetSystemDirectory<https://msdn.microsoft.com/en-us/library/windows/desktop/ms724373(v=vs.85).aspx> 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 GetWindowsDirectory<https://msdn.microsoft.com/en-us/library/windows/desktop/ms724454(v=vs.85).aspx> 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-dlls-anyway/> 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 <boost-bounces_at_[hidden]> on behalf of Olaf van der Spek <ml_at_[hidden]>
Sent: Tuesday, October 11, 2016 12:24 PM
To: boost_at_[hidden]
Subject: Re: [boost] [config] Changes to reflect Visual C++ "15" preview 5

On Mon, Oct 10, 2016 at 5:28 PM, Billy O'Neal (VC LIBS)
<bion_at_[hidden]> wrote:
> 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>, <string_view>) to 140; 150 is not yet ready to ship.

<string_view>, at last :p

On Mon, Oct 10, 2016 at 6:41 PM, Billy O'Neal (VC LIBS)
<bion_at_[hidden]> wrote:
>>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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk