> Maybe that's actually > what's needed, but it sure looks fishy. And what connection does the > build toolchain version have to the runtime environment anyway?
The CRT version is tied to the compiler version. It has mainly to do with matching allocators.
In UNIX terms, the compiler and libc are tightly coupled on Windows and each executable or shared library links to the C library provided by the compiler that built the DLL or EXE. It's normal to link a program with multiple C runtime libraries if that program is composed of one or more DLLs that were each compiled by a different toolchain and therefore linked to a different C runtime ... which is common in the Windows binary distribution model.
"msvcrt.dll" is the best-known C runtime, the one bundled in Windows. It's ancient and buggy and retained only for backward compatibility. mingw has to pile hacks upon hacks around it to use it.
Microsoft has been bundling the C runtime libraries with the compiler since at least Visual Studio 7. Application installers are expected to silently run an installer for the C runtime library before installing the application. They do not use the C runtime library from the operating system.
You might have seen "Visual Studio Redistributable" packages installed by various app installers. That's what they are - they're making sure the specific C runtime they are built against is installed.
It's a bit like, on UNIX, each shared library expecting to have a different libc. One expects libc-2.20.so, one expects libc-2.19.so, etc. Each with linkage private to the shared library that loaded it. (We have this to a lesser degree with libgcc, but everyone uses one version of gcc for building everything on a given system so in practice it makes no difference.)
This is why applications on Windows must be very careful not to malloc() memory in one DLL and free() it in another, etc. They're effectively leaking it and freeing unallocated memory at the same time because the two C libraries have separate memory management structures.
It lets applications be composed of binary-distributed components from different vendors, using different toolchains. Want to build new parts of an app with VS 2017 while compiling your legacy components with VS 7, linking with a libabc built using mingw32 by a vendor who won't show you the source, and linking a libxyz built with an ancient version of Borland C from sources you lost 5 years ago? You can do that.
I don't pretend it's a good idea, but it does have advantages sometimes.
