开源项目 demoscene-recomp 近日上线，借助一种冷门却极为硬核的转译架构，直接在现代浏览器中原生复活了 1992 至 1993 年间的四部经典 DOS Demoscene 演示片。这批作品包括 Future Crew 拿下 Assembly 1992 冠军的《Unreal》、次年在 Assembly 1993 夺冠的传奇之作《Second Reality》，以及 Triton 摘得 Computer Crossroads 1993 桂冠的《Crystal Dream II》与 NoooN 的《Stars: Wonders of the World》。
这绝不是在网页端套一个 DOS 模拟器那么简单。它没有搬用沉重的虚拟机，也没有像多数网页特效那样用现代图形接口重写视觉逻辑，而是开辟了数字遗产保存的第四种路径：通过记录重编译管线，将当年榨干 x86 硬件极限的机器码逐指令转换为 C 代码，再编译至 WebAssembly。这意味着三十年前依靠黑客技巧写就的时序奇迹，第一次以近乎零损耗的原生形态落在了现代网页里。
绕开黑盒模拟与人工重写的第三种解法
要理解 demoscene-recomp 的特殊之处，必须先看清复古计算机遗产在现代重现时的两难困境。早期 DOS 时代的 Demoscene 开发者习惯直接向硬件端口写指令，广泛调用未公开的 VGA 显卡特性（如 Mode X）与实模式中断，其视觉同步极度依赖 80386 乃至 80486 处理器上精确到时钟周期的指令执行时间。在今天的浏览器环境回放这些作品，行业此前只有三条相对成熟的路径。
第一种是 js-dos 这类方案，利用 DOSBox 或 DOSBox-X 编译出的 WebAssembly 模块打包执行原始二进制文件。这种做法分发最便捷，但本质上是黑盒模拟，无法精准还原特定主板时序，且伴随着整个操作系统的初始化开销。第二种是 PCem-WebAssembly，虽然提供了多线程的完整硬件级周期仿真，但其计算负载过高、配置极为繁琐，在移动端和普通网页中几乎无法顺畅跑满帧率。第三种则是像 second-reality-js 这类手工重写项目，开发者借助调试工具理解原始画面后，用 JavaScript 和 WebGL 重新编码实现，虽然运行流畅，却在重构过程中丢失了原始机器码的执行逻辑与硬件互操作细节。
demoscene-recomp 避开了这两端的妥协。它既不维护庞大的模拟器状态机，也不靠人工猜想去重构视觉管线，而是把整个 Demo 的运行过程视为一条确定性的指令执行流，开创了面向 WebAssembly 的静态追踪重编译范式。
指令追踪到 WebAssembly 的四步管线
项目实现高保真度的核心在于一套严格的转译与校验流水线。它并非静态反编译全部死代码，而是利用底层模拟器完整运行目标演示片，追踪并记录下 CPU 实际执行过的每一段机器码及其消耗的时钟周期。
随后，转译引擎将这些执行轨迹逐条映射到结构化的 C 语言代码中，把当时 16 位与 32 位混合的 x86 指令逻辑固化为纯粹的时序函数。紧接着，这些 C 代码连同最小化的硬件外设模型——包括系统定时器、标准 VGA 显示卡以及声霸卡（Sound Blaster）——统一通过编译器输出为跨平台的 WebAssembly 模块。
最后一步也是最关键的保真工序：重编译产物会回放并对照模拟器的原始事件。每次中断触发、I/O 端口访问以及光栅渲染帧，都必须发生在完全相同的虚拟时间戳上。得益于这套严密的机制，Demo 自带的原版加载器、解压程序、音乐回放逻辑和 3D 多边形渲染管道，全部以 1993 年编写时的状态原样运行。网络端传输的原始数据文件未作任何修改，只是被重编译后的 WebAssembly 运行时按需读取。
剥离系统冗余却原样锁死硬件时钟，程序便获得了超越虚拟机的轻盈。
70Hz 物理断层与声卡边界
即便工程设计足够巧妙，这套方案在现代硬件生态中依然面临物理层面的局限。
首要问题是显示刷新率的物理错位。DOS 时代的标准 VGA 文本与图形模式运行在固定的 70 Hz 场频下，当年 Demo 中著名的丝滑等离子水波与平滑卷轴，完全依赖垂直消隐期同步。现代大部分办公显示器与笔记本屏幕的基础刷新率通常为 60 Hz。如果强行在 60 Hz 屏幕上渲染 70 Hz 的帧流，会出现不可避免的帧抖动与画面撕裂。项目作者明确提醒，必须在支持 70 Hz、140 Hz 或更高刷新率的电竞显示器上，才能真正还原那份如黄油般顺滑的原始视觉质感。
硬件模拟范围同样存在取舍。回顾历史，Future Crew 的《Unreal》最初在 Assembly 1992 发布时，最低硬件门槛是 80386 芯片配约 600 KB 的自由常规内存，其后来的 1.1 版本加入了对经典 Gravis Ultrasound（GUS）声卡的支持。由于 demoscene-recomp 目前仅精简建模了最为普及的 Sound Blaster（声霸卡），这意味着更高级的 GUS 硬件混音特性在现阶段管线中暂未还原。
- 结论.demoscene-recomp 证明了二进制重编译在网页端数字文物保存中的可行性，它摆脱了对笨重全系统虚拟机的依赖，兼具轻量分发与微秒级精准度。
- 风险.该管线高度依赖预先记录的静态执行流，若面对包含大量自修改代码或复杂保护模式的商业 DOS 软件，转译与测试成本将呈几何级上升。
对于档案机构与编译器工程师而言，这套架构提供了一个极具参考价值的开源标本。它证明了数字遗产的永续保存既不需要让模拟器吞噬所有算力，也不必以牺牲历史原貌为代价去重写代码。通过在执行流层面锁定时序，哪怕是三十年前专为 386 裸机打造的极限代码，也能在当下的浏览器沙盒中分秒不差地流转。