Re: report from the bleeding edge (VS 2017)

[Guy Harris <guy () alum mit edu>]

On Feb 14, 2018, at 5:15 PM, Gerald Combs <gerald () wireshark org> wrote:

> As far as library compatibility goes, according to
>
> https://docs.microsoft.com/en-us/cpp/porting/binary-compat-2015-2017
>
> we *should* be able to build using Visual C++ 2017 and use libraries compiled with Visual C++ 2015. I did a test 
> build here using Visual C++ 2017 and the "msvc2015" Qt component here and it seems to work OK. Dependencies[1] 
> reports that it's using msvcp140.dll and vcruntime140.dll.

OK, so

        https://blogs.msdn.microsoft.com/vcblog/2014/06/10/the-great-c-runtime-crt-refactoring/

says that for VS 2002, 2003, 2005, 2008, 2010, 2012, and 2013, the C/C++ run-time library version was tied to the 
compiler version, so that something built with version X had to use version X's CRT - meaning that if it used a 
dynamically-linked CRT, it needed to find the version X CRT's DLL.  It says that for VS 2015, the CRT was split into 
multiple parts, and that:

        the VCRuntime, with vcruntimeXXX.dll names, is still tied to the compiler;

        the AppCRT, with appcrtXXX.dll names, will have a stable ABI, so that Microsoft can update it for a new 
compiler but programs built with the older version will work with the newer version (i.e., the way the C/system library 
on UN*Xes with dynamically-linked shared libraries and ABI guarantees have worked since, err, umm, forever) - this 
library contains most of the routines that are directly called (including, I infer from the reference to "the heap", 
the memory allocation routines, as well as the "standard I/O library" routines that work with FILE *'s and *possibly* 
the UN*X-like I/O wrappers);

        the DesktopCRT, with desktopcrtXXX.dll names, will also have a stable ABI - this library contains the remaining 
directly-called routines, with the ones not available in the Windows Store and Windows Phone platforms being in the 
DesktopCRT.

They also indicate that the libraries with msvcpXXX.dll are the STL libraries ("cp" - "C Plus plus"?) and that those 
won't have a stable ABI.

        https://blogs.msdn.microsoft.com/vcblog/2015/03/03/introducing-the-universal-crt/

mentions the "Universal CRT", and says that the AppCRT and DesktopCRT were combined into the Universal CRT, with the 
names ucrtbase.dll for the release version and ucrtbased.dll for the debug version, with *no* version number, as it's 
not tied to the compiler.  To quote that post:

        "1. The Universal CRT is a Windows operating system component. It is a part of Windows 10. For Windows versions 
prior to Windows 10, the Universal CRT is distributed via Windows Update. There are Windows Update MSU packages for 
Windows Vista through Windows 8.1. Currently these MSU packages are installed as part of the VCRedist installation. In 
a future build of Visual Studio 2015, these MSU packages will also be distributed separately as part of the Universal 
CRT SDK and made available for download on support.microsoft.com.

        2. If you build software designed for use on Windows operating systems where the Universal CRT is not 
guaranteed to be installed (i.e., Windows 8.1 and below), your software will need to depend on the above mentioned 
Windows Update packages to install the Universal CRT.

        3. If you currently use the VCRedist (our redistributable package files), then things will just work for you as 
they did before. The Visual Studio 2015 VCRedist package includes the above mentioned Windows Update packages, so 
simply installing the VCRedist will install both the Visual C++ libraries and the Universal CRT. This is our 
recommended deployment mechanism. On Windows XP, for which there is no Universal CRT Windows Update MSU, the VCRedist 
will deploy the Universal CRT itself.

        4. If you currently statically link the Visual C++ libraries, then things will continue to work just as they 
currently work for you.  We strongly recommend against static linking of the Visual C++ libraries, for both performance 
and serviceability reasons, but we recognize that there are some use cases that require static libraries and we will 
continue to support the static libraries for those reasons.

        5. There will not be a merge module for the Universal CRT. If you currently use the CRT merge modules and still 
want to deploy the Visual C++ libraries centrally, we recommend that you move to the above mentioned Windows Update 
package or to the VCRedist. Alternatively, you may choose to link statically to the Universal CRT and the Visual C++ 
libraries.

        6. Updated September 11, 2015:  App-local deployment of the Universal CRT is supported.  To obtain the binaries 
for app-local deployment, install the Windows Software Development Kit (SDK) for Windows 10.  The binaries will be 
installed to C:\Program Files (x86)\Windows Kits\10\Redist\ucrt.  You will need to copy all of the DLLs with your app 
(note that the set of DLLs are necessary is different on different versions of Windows, so you must include all of the 
DLLs in order for your program to run on all supported versions of Windows)."

The libraries you mention are the parts of the C/C++ runtime that *aren't* in the Universal CRT, so presumably the 
version of those libraries may still matter.

I don't know

        1) whether all of what they said is still true;

        2) if so, whether it *really* works right.

There are some discussions in which people aren't all that convinced.  See, for example, the discussions for

        https://blogs.msdn.microsoft.com/vcblog/2016/04/18/c-runtime-deployment-why-choosing-applocal/

one comment of which points to

        
https://support.microsoft.com/en-us/help/835322/applications-that-bypass-globally-serviced-side-by-side-assemblies-may

with "Recommended practices for software developers who use side-by-side assemblies" (is that an issue for us?), and see

        
https://blogs.msdn.microsoft.com/vcblog/2016/02/24/stuck-on-an-older-toolset-version-move-to-visual-studio-2015-without-upgrading-your-toolset/

in which "still not squaloghepardo" says:

        Wrote an email last week to James McNellis. No reply yet, seems it either got lost in his spam filter or he is 
too busy. I’m currently stuck on the Windows 10 Universal C Runtime:
        Connect Bug 1773279 bug-in-sntscanf-s got fixed around the end of last year. However there never was an updated 
vcredist (latest version https://www.microsoft.com/en-us/download/details.aspx?id=49984 – Visual Studio 2015 Update 1). 
Only the Windows 10 Universal C Runtime got the bug fix.
        In the blog post https://blogs.msdn.microsoft.com/vcblog/2015/03/03/introducing-the-universal-crt/ you guys 
talked about only needing the vcredist for redistribution:

        “If you currently use the VCRedist (our redistributable package files), then things will just work for you as 
they did before. The Visual Studio 2015 VCRedist package includes the above mentioned Windows Update packages, so 
simply installing the VCRedist will install both the Visual C++ libraries and the Universal CRT. This is our 
recommended deployment mechanism. On Windows XP, for which there is no Universal CRT Windows Update MSU, the VCRedist 
will deploy the Universal CRT itself.”

        Unfortunately that is no longer the case. Is there a plan to update the vcredist package or do I have to 
include the Windows 10 Universal C Runtime from now on in my installers? Relying on the customer to have run windows 
update is not an option.

        I’m waiting for this fix now for way over three months. I really want to finally upgrade from VS 2010…

So does the Universal CRT at all affect what we should be doing when building and packaging?
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe