我有一些可以编译到各种平台上的C ++代码，即Linux 32/64位，Windows 32/64位。对于Windows，我使用mingw-w64软件包提供的最新gcc编译器。我遇到的麻烦是32位编译拖累了Microsoft通过msvcrt.dll提供的libc API，并且该DLL存在一些问题：
mingw使用特定版本，因此默认情况下不会在较早版本上运行，例如在Windows XP中：它将需要不存在的API的入口点。
我尝试了静态链接，但无济于事，msvcrt.dll总是被拖动（-static，-static-libgcc，-static-libstdc ++，您为它命名）。
我相当坦率地尝试将Windows XP附带的msvcrt.dll替换为可在较新的Windows版本中运行的msvcrt.dll，但该操作完全阻止了Windows XP的启动。
我尝试将正确的msvcrt.dll复制到我的可执行路径，但是由于它是每个人都在使用的库，因此已经加载并且Windows不会从其他文件加载另一个实例。
我尝试修补可执行文件，以便它将调用相同的DLL，但使用不同的名称，因此愚蠢的Windows仅为我的可执行文件加载较新的版本，并且第一步起作用，但它开始了对DLL依赖项的噩梦，永远无法满足，因为它将引入其他系统库，例如ntdll.dll，这些系统库也必须进行修补等等。
我尝试在此处以及在不同的论坛中浏览有关此相同问题的几个问题，但是一切都归结为msvcrt.dll是一个您不必担心的库，但是那根本不是事实，那里有很多兼容性问题。
我知道mingw慢慢地抛弃了Windows XP等较旧的操作系统，但是我真的很想找到一个解决问题的方法，这个问题不应该看起来那么复杂。我首先将mingw-w64-i686-libwinpthread和mingw-w64-i686-winpthreads从当前的7.0.0.5325降级到最近的7.0.0.5273，以避免调用GetTickCount64（），这是Vista中引入的API。修复此问题后，它会要求我从msvcrt.dll中获得_mkgmtime32（），该文件是DLL的版本7中引入的，而Windows XP随附的DLL中显然没有该文件。
我也知道我想将C ++ 17与已经有近20年历史的操作系统一起使用，但是它仍然非常流行，至少在第三世界中仍然如此。有人对此有任何见识吗？
答案 0 :(得分：0)