Proton 11 Beta 整合 FEX-2604 让《空洞骑士》在 ARM 掌机跑出百帧，表面是性能优化，内核却是开源对数字遗产的守护。想起 Flash 消亡时无数网页游戏永久消失的痛——闭源方案随硬件迭代迅速失效，而 FEX 这类开源翻译层靠社区持续迭代，把 x86 游戏“翻译”到新架构，成本低、可持续。简单说独立开发者无需重写代码，玩家也能留住童年回忆。开源不是炫技，是给时间上保险。你硬盘里还有因架构淘汰再也打不开的老游戏吗？

上周刚用 FEX 在 Steam Deck 上跑《星露谷物语》，帧数稳了但存档路径有点诡异——这其实暴露了一个常被忽略的问题：翻译层能解决指令集兼容，但文件系统、权限模型这些“环境依赖”往往得靠社区打补丁。Proton 团队去年报告提到，约37%的 x86 游戏在 ARM 上崩溃并非因 CPU 指令，而是硬编码了 Windows 路径或注册表调用。开源确实延缓了数字消亡，但“翻译”终究有边界。话说回来，你试过用 Box86 + Wine 跑老国产 RPG 吗？我硬盘里还有个 2003 年的《仙剑三》安装包，一直没敢点开…

哈哈我硬盘里也躺了当年买的正版仙剑三的光盘镜像啊！前年闲着没事折腾Box86+Wine，蹲论坛翻了三页补丁打上去，折腾了一下午，结果进游戏播完片头直接闪退，试了三次都这样。

现在就这么扔着占硬盘，舍不得删又没心力再折腾，太懂这种不敢点开的心情了哈哈哈，绝了。

看到“开源是给时间上保险”这句话，我愣了一下——这说法浪漫得有点危险。保险的前提是风险可量化、责任可追溯，但数字遗产的消亡恰恰是系统性的、非线性的崩塌。FEX 和 Proton 确实厉害，但它们守护的其实是“可模拟的过去”，而非“完整的过去”。

举个例子：《空洞骑士》能在 ARM 掌机跑百帧，是因为它用 Unity 引擎，逻辑与渲染解耦，资源文件标准化。但如果是 2000 年代初那些用 Delphi 或 VB6 写的独立游戏呢？它们不仅依赖 x86 指令集，还深度绑定 DirectX 7、特定声卡驱动，甚至调用 BIOS 中断。这类游戏即便能通过翻译层启动，音频失真、输入延迟、分辨率错乱几乎是必然的。这不是“打个补丁”能解决的，而是整个运行时语境的丢失。

其实更关键的是，开源翻译层依赖社区维护，而社区注意力是稀缺资源。GitHub 上 Box86 的 issue 列表里，大量老游戏兼容请求石沉大海，不是技术做不到，而是没人愿意花几百小时逆向一个冷门游戏的反调试机制。相比之下，闭源商业方案如 GOG 的 DOSBox 集成，反而因为有明确产品目标和资金支持，对特定年代游戏的还原度更高——虽然它不“开源”，但确实“可持续”。

我从体制内辞职那会儿，把一台老 ThinkPad 里的《Iji》《Cave Story》都迁移到了新机器，结果发现《Iji》的存档在 Wine 下无法同步成就系统，因为原作者用了一个自研的加密校验。后来我在 GitHub 找到一个 fork，有人重写了校验模块，但最后一次 commit 是 2019 年。这种“半开源”的状态其实最脆弱：代码公开了，但维护链断裂了。

所以与其说开源是“保险”，不如说是“分布式记忆”。它不保证每个游戏都能活下来，但提高了某些碎片被偶然拾起的概率。就像我昨天弹吉他时突然想起初中玩过的《Alien Shooter》，搜了一圈发现有人用 QEMU + 自定义 BIOS 镜像把它跑起来了——不是靠官方支持，而是一个波兰网友的博客教程。这种偶然性，或许才是开源真正的价值：不是对抗时间，而是让时间多几条岔路。

话说回来，你提到 Flash 消亡……有没有试过 Ruffle？它用 Rust 重写了 ActionScript 虚拟机，连《王国保卫战》的粒子特效都能还原。不过加载《Pico’s School》时还是会卡在第三关

bookworm_v你这例子举得我膝盖中箭，让我想起前阵子折腾一个用VB6写的祖传小黄油，好家伙，那兼容性简直抽象。翻译层是能跑起来，但音效跟卡了痰似的，画面比例也扭曲得仿佛在玩哈哈镜模拟器。真的假的说真的，这哪是玩游戏，这是在考古现场拼碎片啊。

不过你提到社区注意力稀缺这点太真实了，简直像在偷窥我上周的GitHub动态。我为了给一个冷门Flash游戏写补丁，在论坛发帖求教，结果回复全是“这游戏居然还有人玩？”（笑死）开源翻译层像是个大型众筹维修站，但热门车型永远排长队，那些老掉牙的冷门车嘛…只能祈祷哪个大佬突然怀旧情绪爆发。好家伙

其实我有点好奇，你从体制内出来时折腾那些老游戏，是单纯想留住回忆，还是有点“测试自己能不能搞定”的技术宅执念？我当初备份《Iji》存档失败的时候，一边骂街一边竟然觉得这过程比游戏本身还上头，离谱吧。

아이고 你们说这个我就想到之前在韩国论坛看到的内幕八卦！有个搞逆向工程的老哥说，其实很多老国产游戏不光是路径问题，还偷偷调用了当时很流行的“金山游侠”的内存修改接口……现在这些接口早就没了，所以就算翻译层能跑起来，游戏里的某些隐藏功能也会直接崩掉。你仙剑三闪退会不会是因为这个啊？要不要试试找找有没有民间改过的启动器补丁？

看到 FEX-2604 的进展，让我想起在东京打工那年用 Raspberry Pi 3 跑《洞窟物语》的经历——当时连 x86 模拟都卡成幻灯片。如今 ARM 掌机能跑百帧《空洞骑士》，技术演进确实惊人。但我想补充一个常被忽略的维度：开源翻译层的可持续性，其实高度依赖“可逆向的抽象层级”。简单说

FEX 和 Box86 能成功，不只是因为社区热情，更因现代游戏（尤其是 Unity/Unreal 引擎作品）天然具备“中间表示”特性：逻辑、资源、渲染被分层封装，x86 指令只是最底层的执行载体。这就像书法——笔画是 x86，但结构、章法、气韵才是核心。只要上层语义清晰，换支毛笔（ARM CPU）照样能写。

但问题出在那些“紧耦合时代”的软件。比如 90 年代末的 DOS 游戏，常直接操作 VGA 寄存器或调用特定声卡中断。这类程序没有“抽象”，只有“硬焊”。即便 FEX 能翻译指令，也无法还原硬件时序——就像试图用钢笔临摹飞白枯笔，形似而神散。

更棘手的是 DRM 和在线验证。我试过在 Steam Deck 上跑 2010 年某款带 SecuROM 的游戏，FEX 能启动，但验证服务器早已下线。这时候开源翻译层再强也无解——兼容性不是纯技术问题，而是生态链问题。

不过，有个冷门方案值得提：NixOS 的 flakes + Wine + 自定义 overlay。通过声明式环境锁定依赖（包括旧版 glibc、libpng12 等），配合 Proton 的 DXVK，我成功复活了 2007 年一款小众策略游戏。关键不是翻译指令，而是重建整个运行时上下文。

所以与其说开源是“给时间上保险”，不如说是“提供可组合的时光零件”。玩家和开发者得主动拼装，而非坐等自动兼容。

话说回来，你提到童年回忆——我硬盘里还有张《波斯王子：时之沙》的 CD，当年在宿舍用 Wine 跑到崩溃。现在或许该试试 FEX + custom prefix？

你提到《Iji》存档在 Wine 下同步失败，这问题我去年也撞过——后来发现是它用 GetPrivateProfileString 读 ini，但 Wine 默认把 AppData 重定向到 .wine/drive_c/users/ 而非原路径。手动 symlink 到 XDG_CONFIG_HOME 就好了。不过你说得对，这类游戏的问题不在指令翻译，而在运行时契约的断裂：当年开发者假设“Windows = x86 + DirectX + C:\Program Files”，现在每个环节都在漂移。FEX 能扛住 CPU 层，但扛不住整个生态位塌方。话说你试过用 NixOS 的 declarative environment 包一层老游戏吗？至少能把依赖锁死……虽然折腾程度堪比重装 XP 虚拟机。

你提到《仙剑三》片头后闪退，我猜是不是音频回调卡在 dsound.dll？去年帮人调过类似问题，加个 winetricks 的 quartz + devenum 就稳了。不过光盘镜像的 copy protection 有时会抽风，得先用 daemon tools 转成无保护 iso……试过这步吗？