I have some C++ code that I compile to various platforms, namely Linux 32/64 bits, Windows 32/64 bits. For the Windows part, I use the latest gcc compiler provided by mingw-w64 package. The trouble I am having is that the 32-bit compilation drags the libc API that Microsoft provides through msvcrt.dll, and that DLL has some problems:
- is not distributable (it comes with Windows and is not replaceable)
- has versions (every Windows version has a different one, with added functionality)
- it depends on other Windows DLLs, meaning the ecosystem of libraries that are around that particular version of the DLL, that are part of the system too.
mingw uses a specific version, so it won't run by default on older versions, for example in Windows XP: it will require entry points to non-existent APIs.
I tried linking statically, but to no avail, msvcrt.dll always gets dragged (-static, -static-libgcc, -static-libstdc++, you name it).
I tried, rather candidly, replacing the msvcrt.dll that comes with Windows XP with one that works in a more recent Windows version, but that prevents Windows XP from booting at all.
I tried copying the correct msvcrt.dll to my executable path, but as it is a library everybody uses, it's already loaded and Windows won't load another instance from a different file.
I tried patching my executable so it will call the same DLL but with a different name and so fool Windows to load a more recent version only for my executable, and that first step works, but it starts a nightmare of DLL dependencies that can never be satisfied, because it will bring in other system libraries like ntdll.dll that also have to be patched and so on.
I tried browsing through several questions on this topic here and in different forums regarding this same problem, but everything boils down to the idea that msvcrt.dll is a library that you should not worry about, but that is simply not true, there is a plethora of compatibility problems about it.
I am aware that mingw is slowly leaving behind older operating systems like Windows XP, but I would really like a solution to a problem that should not to be as complicated as it seems. I started by downgrading mingw-w64-i686-libwinpthread and mingw-w64-i686-winpthreads from the current 7.0.0.5325 down to a not so far away 7.0.0.5273 to avoid a call to GetTickCount64(), an API introduced in Vista. Once I fixed that, it asks me for _mkgmtime32(), from msvcrt.dll, that was introduced in version 7 of the DLL, and that obviously is not present in the DLL that comes with Windows XP.
I am aware as well that I want to use C++17 with an operating system that is almost 20 years old, but it is overwhelmingly popular still, at least in the third world. Anyone has any insight about this?