Principia 回到 Windows XP：卡住它的不是性能，是新工具链

Principia 是一款 2014 年的物理解谜游戏。它现在又被拿来试着跑回 Windows XP。

这件事有意思的地方不在怀旧。作者不是宣布官方恢复 XP 支持，也不是证明 XP 还能安全承担现代桌面使用。他做的是一次兼容性实验：目标系统是 Windows XP/NT 5.1，目标架构是 32 位 i686-w64-mingw32，运行库选 MSVCRT，而不是 UCRT。

反常点在这里：游戏本身并不算难。Principia 原本面向 2012 年前后的手机硬件，图形需求主要是 OpenGL 2.0，历史上也曾在 XP 上运行过。真正挡路的，是今天想把它重新编出来时，底下那套工具链和依赖已经换了时代。

老游戏适合 XP，新工具链不适合

从应用条件看，Principia 不是那种天然拒绝旧系统的软件。它没有绑定 DirectX 12，没有塞进现代浏览器内核，也不是重在线服务框架驱动的游戏。

SDL 仍然支持 XP，这也给了实验空间。按理说，只要能避开新 API，做一个 XP 可执行文件并不荒唐。

但项目当前官方 Windows 构建使用的是 MSYS2 的 LLVM mingw-w64 工具链。这条路线对 XP 不友好。UCRT、libc++ 和相关支持库，普遍把最低系统预期抬到了 Vista 或 Windows 7 之后。

作者于是换了路线：自建 GCC、binutils 和 mingw-w64 工具链。听起来笨，但可控。

这里的判断很直接：旧系统兼容不是只看应用代码。编译器、标准库、运行库，任何一层默认前进半步，都可能让 XP 直接掉队。

作者在自建工具链时遇到的坑也说明了这一点。GMP 在 GCC 15+ 默认 C23 语义下构建失败。GCC 16 的 libstdc++ 又出现了对 Vista+ API GetDynamicTimeZoneInformation 的依赖，需要借鉴 w64devkit 的补丁做动态探测。

这不是游戏代码太重。是底座在迁移。

真正费劲的是依赖库，不是 EXE

能编出面向 XP 的程序，只是第一关。Principia 还要带上 curl、Freetype、libjpeg-turbo、libpng、SDL、zlib 等依赖。

这些库都常见。但常见不代表还照顾 XP。

curl 是最典型的麻烦点。8.19.0 已经放弃 Windows XP。8.18.0 仍会在 XP 的 msvcrt.dll 里寻找不存在的 freopen_s。作者最后退到 8.17.0。

这一步只能理解成兼容性选择，不能理解成安全建议。XP 本身已经不适合现代联网环境，网络库降级还会放大风险。要把 XP 接入公网，不能靠“能运行”给自己壮胆。

GTK3 也卡住了桌面体验。Principia 桌面版原本用 GTK3 处理对话框，但 GTK3 依赖树太重。作者没有立刻恢复旧 GTK2 方案，也没有继续追老 GTK3，而是暂时改用实验性的 Dear ImGui 对话框。

代价也很清楚：部分对话框还没有实现。所以这个 XP 构建目前不能说完整可用，只能说已经走到可启动、可验证方向的阶段。

对开源游戏维护者来说，这里有一个很实际的动作：如果还想保旧系统，就要把工具链版本、运行库路线、依赖库上限写进构建文档，最好进 CI。只写“源码支持 Windows”不够。

对做 Windows 交叉编译的人来说，也要把“最低系统版本”当成构建产物的一部分。升级 mingw-w64、LLVM、GCC、curl 或 C++ 标准库时，不该只看能不能编过，还要查有没有新引入的系统符号。

接下来别看 XP 复活，要看能不能稳定复现

作者已经做过 Wine 烟测，也在 XP 虚拟机里确认程序能启动到 OpenGL 驱动报错阶段。这至少表明，当前 EXE 和 DLL 暂时没有立刻撞上 XP 缺失符号。

但虚拟机的 OpenGL 支持不够理想。实机测试仍然是关键变量。尤其是这类老系统兼容，虚拟机能启动不等于真实机器能玩，驱动层经常才是最后一关。

后面最该观察的不是“XP 能不能复活”。这个问题太大，也不安全。更现实的观察点有三个：

• 这套 GCC/binutils/mingw-w64 工具链能不能被别人稳定复现；
• curl、SDL 等依赖版本能不能锁住，同时避免新的 XP 断点；
• Dear ImGui 对话框能不能补到日常可用，而不只是跑通启动流程。

如果这三点做不到，这次构建就更像一次成功的兼容性考古。如果能做到，它对同类开源老游戏会有参考价值。

我更在意的是这个提醒：旧软件被旧系统甩下，常常不是因为它跑不动，而是因为维护者已经很难用今天的工具，为昨天的系统稳定生产软件。沉舟侧畔，水路早改。