Wireshark · Wireshark-dev: Re: [Wireshark-dev] report from the bleeding edge (VS 2017)

[Guy Harris <guy@xxxxxxxxxxxx>]

On Feb 14, 2018, at 5:15 PM, Gerald Combs <gerald@xxxxxxxxxxxxx> 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?