Re: [boost] [config] Changes to reflect Visual C++ "15" preview 5

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

>Why adding export symbols for char16_t and char32_t is considered a breakage?

Because we support app-local deployment of P, we can't change its export surface in any way without breaking bincompat. Consider the following scenario:

1. A printer driver or similar application is installed using the "new" msvcp140.dll using the vc redist for Visual Studio "15".

2. An application is installed which uses a previous copy of msvcp140.dll, such as that shipping now with Visual Studio 2015 RTM.

3. Application starts, and user edits a document.

4. User tries to print. This attempts to load the print driver into the application's process.

5. The print driver looks for the new exports in msvcp140.dll, but the application's app-local copy, not the one installed by the redist, is already loaded into the process.

6. Print driver DLL can't find the new exports its looking for, and the program crashes.

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. (In that case, only the system copy of the DLL exists, and that one is maintained at the latest installed copy)

>You could just make those symbols point to the unsigned short and unsigned int API implementation that you already provide and recommend using in the MS Connect tickets.

We may be able to inject something like this with an additional static library but have been reluctant to do so -- the presence of the bug in the shipping product indicates that there is a gap in understanding of how these extension codecvt facets were/are intended to operate, and/or that such functionality was never tested.

>IMHO, this sort of bugs should have been fixed even before VC14 RTM, let alone the later updates.

Agreed [?]

Billy3
________________________________
From: Boost <boost-bounces_at_[hidden]> on behalf of Andrey Semashev <andrey.semashev_at_[hidden]>
Sent: Monday, October 10, 2016 9:23:05 AM
To: boost_at_[hidden]
Subject: Re: [boost] [config] Changes to reflect Visual C++ "15" preview 5

On 10/10/16 18:28, Billy O'Neal (VC LIBS) wrote:
>> So this library/compiler decoupling has the consequence of delaying
>> bug
> fixes users are waiting for. Shouldn't users be allowed to make the
> "break ABI" choice for themselves? I.E. supply both MSVCP140.dll and
> MSVCP150.dll with 140 the default initially, then 150 further down
> the road, then eventually no longer supply 140.
>
> Feedback from customers was that breaking bincompat every year was
> too rapid. 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.

Why adding export symbols for char16_t and char32_t is considered a
breakage? You could just make those symbols point to the unsigned short
and unsigned int API implementation that you already provide and
recommend using in the MS Connect tickets.

IMHO, this sort of bugs should have been fixed even before VC14 RTM, let
alone the later updates.

_______________________________________________
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%7C6e04e86bc94741ca7e3f08d3f129cb65%7C72f988bf86f141af91ab2d7cd011db47%7C1&sdata=O1TfA7t3x4z6KMDq3OE3SQSeRxpCY9M%2BkVOADdI0hFU%3D&reserved=0