"Side By Side Assemblies" Bring DLL Hell 2.0
"For those unfamiliar with the Microsoft world, native microsoft applications written in C++ rely on dynamic libraries. Two of them are infamous: MSVCRT.DLL and MFCxx.dll. Because of software evolution and security fixes, multiple versions of these DLLs were often present in the system, causing application instability."
GOTOHELL.DLL: Software Dependencies and the Maintenance of Microsoft Windows (PDF)
Windows is not a Microsoft Visual C/C++ Run-Time delivery channel
Linus Torvalds: "Shared libraries are not a good thing in general." | HN discussion
Wikipedia:
"a lightweight drop-in replacement for the (currently only Microsoft, so compatible with Intel C/C++ & Visual C++) runtime library."
32 bit versions are compiled with Microsoft Visual C++ 7 (2003) compiler. They are not linked with the standard C or C++ libraries that comes with this compiler. Instead, most of them are linked with a dynamic library I call minwcrt (Minimal Windows C Run-Time Library) linking them to crtdll.dll instead of msvcrt.dll. This makes them run in all versions of Win32 without additional dll files. This is also the reason why the exe files are very small. Source for this library is available as part of the source archive mentioned in the top of this document. Some other tools are linked to msvcrt.dll to support formatting 64-bit integers and similar features not available in crtdll.dll. This means that some such tools may require updated MS VC++ runtime dll files on Windows NT 3.51, Windows 95 or Win32s.
The mingw-w64 project "is a complete runtime environment for gcc to support binaries native to Windows 64-bit and 32-bit operating systems."
samuelsebastian succinct review: "Fast, Actual, Easy. ( I never use MSVC ) I like no install , direct to use, compact, working , things."
Chris Wellons' Small, Freestanding Windows Executables: However, [Mingw-w64] has one glaring flaw inherited from MinGW: it links against msvcrt.dll, an ancient version of the Microsoft C runtime library that currently ships with Windows. Besides being dated and quirky, it’s not an official part of Windows and never has been, despite its inclusion with every release since Windows 95. Mingw-w64 doesn’t have a C library of its own, instead patching over some of the flaws of msvcrt.dll and linking against it. ... Sometimes I’d prefer to be more direct: skip the C library altogether and talk directly to the operating system. On Windows that’s the Win32 API. Ultimately I want a tiny, standalone .exe that only links against system DLLs.
Dr. Dobb's: Avoiding the Visual C++ Runtime Library
Linking statically to the CRT Library always increases the size of the application/library, sometimes dramatically so, particularly when building small application/libraries. Also, where multiple dynamic modules form part of an application, there can be multiple statically linked copies of the same code throughout the working set of a process, which is not only costly in space terms, but can cause memory locality problems. In such circumstances, the memory allocated by one module's CRT Library will cause a crash if it is passed to another module's CRT Library for deallocation.
Linking dynamically can cause dependency problems (including version incompatibilities and distribution problems) in addition to increases in load times. Because the CRT DLL is not part of the Win32 system libraries, it is even possible to encounter older systems in which it is not installed. (Windows 95 OSR1 does not ship with MSVCRT.dll as part of the operating system distribution.) Furthermore, Microsoft has encountered program-breaking incompatibilities between versions of MSVCRT.dll ("Bug++ of the Month," WDJ, May 1999), which is also something we developers are very keen to avoid. Finally, since the DLL version is only available in multithreaded form, it can also lead to subtle, but significant, performance costs.
/windows | May 01, 2021