Re: Crash with old Windows on new CPU

On 13 February 2016 at 23:45, Christian Ullrich <chris(at)chrullrich(dot)net>
wrote:

>
> > 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.

--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services