SDL 把 DOS 支持合进主线：真正稀缺的不是怀旧，而是把旧平台做成工程边界

SDL 项目主线合并了 PR #15377，标题是“Add DOS platform support (DJGPP)”。这次合入 53 个 commits，把 DOS 平台支持正式并入 libsdl-org/SDL 的 main 分支。

别误会，这不是 SDL 宣布“重返 DOS 市场”。材料只能说明一件事：SDL 现在有了一套基于 DJGPP 的 DOS 后端，能跑、能编、能测，并且覆盖了游戏运行最关键的几块底层能力。真正有价值的地方，也正在这里。

DOS 支持进了 SDL 主线，但边界写得很清楚

这次支持的对象不是现代 Windows 命令行，也不是某种复古皮肤，而是面向 DJGPP 工具链的 DOS 平台移植。对游戏开发者来说，关键词是：显示、声音、输入、时间、线程、文件系统和构建链路都有人接上了。

缺口也写在明面上：没有音频录制；没有 SDL_LoadObject 共享库加载；SDL_TIME 没做原生实现，而是复用 DJGPP POSIX 层里的 gettimeofday。测试主要来自 DOSBox 加 DevilutionX，真实硬件还没测。

这几条限制很关键。DOS 机器、声卡、BIOS、VESA 实现之间的差异，本来就像早期 PC 兼容生态的一地碎玻璃。模拟器里通了，不等于每块老 Sound Blaster、每台 486 或奔腾机都稳。

这件事重要在工程，不重要在情怀

“温故而知新”这句话放在这里不该被读成怀旧鸡汤。它对应的是一个具体工程问题：当平台老到没人愿意碰，兼容层还能不能把混乱收束成清晰边界。

SDL 的价值一直不是炫技，而是替上层项目挡住平台差异。Windows、Linux、macOS、主机、移动端，各有窗口、音频、输入、线程模型。DOS 更麻烦：没有现代操作系统那套舒适抽象，硬件访问、内存模型、设备中断、计时机制都带着年代的毛刺。

这次 PR 的意义，是把这些毛刺打包进 SDL 的平台层。对 DevilutionX 这类复古游戏移植项目、DOS 生态维护者、做软件保存和兼容性研究的人来说，它减少的不是一两行代码，而是一整套“我该不该自己写底层适配”的决策成本。

横向看，很多开源项目对旧平台的态度常见两种：要么口头支持，实际没人敢碰；要么散落在民间 fork 里，能跑但不可维护。SDL 这次更像铁路统一轨距。轨道本身不生产货物，但轨距一统一，货才能更便宜地流动。不完全一样，软件平台没有铁路那种强制标准权力；但底层接口一旦进主线，复用成本和维护预期都会变。

最该盯的不是能不能跑，而是谁来承担真实硬件的脏活

我更在意一个现实变量：后续有没有人把它从 DOSBox 带到真实硬件上。PR 作者已经说得很坦白，没有真实硬件测试，没加的功能主要也是因为缺少可靠测试办法。

这不是瑕疵遮掩，反而是工程诚实。老平台兼容最怕“截图能跑”。真正麻烦的是边缘声卡、怪异 BIOS、VESA 兼容差异、游戏杆校准、不同机器上的计时漂移。DOS 世界没有今天这种统一驱动模型，很多问题只能靠硬件、耐心和用户回报慢慢磨。

对开发者的建议也很明确：如果你维护的是 SDL 上层项目，现在可以认真评估 DOS 移植路径，但别把它当成已覆盖所有老机器的承诺。适合先在 DOSBox、特定硬件目标、保存项目和复古发行包里试水。商业化复古硬件或大规模兼容承诺，最好等真实硬件测试积累之后再说。

这次 SDL 少见地做对了一件小而硬的事：没有把旧平台当流量梗，也没有夸成战略回归。它只是把一段技术债切成了平台边界。开源基础设施最值钱的时候，往往不是发布大词，而是有人愿意替后来者把烂泥路铺成窄路，哪怕只通向 DOS。