一个个人开发的 64 位 hobby OS，现在能跑部分 Windows 游戏了。

主角是 Astral。作者的目标很具体：让 Windows-only 游戏 Cogmind 在自己的系统上跑起来。Cogmind 是 32 位 Windows 程序，Astral 是 64 位 OS，中间隔着 Wine、图形栈、WoW64、内核 LDT 支持，以及一堆会在半夜把人劝退的兼容细节。

这事别读歪。Astral 还不是游戏系统，也谈不上挑战 Windows 或 Linux。它目前更像一次技术验证：一个独立 OS 如果想摸到日用桌面的边，难点早就不只是“能不能 boot”。

Astral 现在跑通了什么，哪里还卡着

这次进展的起点并不体面：原有 Wine 移植很不完整，连 notepad.exe 都不稳定。作者补上 MinGW 后，Wine 的基础能力才开始可用，notepad.exe 的“另存为”也不再崩。

游戏层面，结果有亮点，但不是大获全胜。

程序 / 游戏当前状态说明
FTL可玩核心运行路径已经打通
Cogmind可玩作者最初想跑起来的 Windows-only 游戏
Deltarune能启动图形路径已有可见成果
Steam部分可用可安装、更新，但 Chromium 启动相关 GetInterfaceAddresses() 问题会导致崩溃
Chromium / Firefox失败浏览器类程序仍没有进入可用状态
Unity 游戏普遍失败wine-mono 卡在 MonoManager ReloadAssembly
部分 Steam DRM 游戏失败还没到主菜单就被挡住
Noita、Spooky’s Jumpscare Mansion能启动但慢说明能跑和好用之间还有很长一段
Half-Life失败Wine C++ runtime 中 assert

所以最准确的说法是：Astral 已经能跑部分 Windows 游戏，不是已经能流畅运行大量 Windows 游戏。

这对两类人最有用。

对 OS 开发者，它提供了一个路线提示：如果目标是桌面可用，别只盯着内核和窗口系统。Wine、Mesa、X.org、/dev/dri、网络接口、运行时、DRM、浏览器，全都得进入待办列表。

对独立游戏和复古游戏玩家开发者，它说明小体量 Windows 游戏可能更早成为 hobby OS 的兼容样本。Steam、Unity、Chromium 这类大依赖栈，短期仍应观望，不适合作为迁移依据。

真正的硬门槛，是 Wine 背后的系统债

Wine 不是虚拟机，也不是模拟器。它是兼容层，把 Windows 程序期待的 API、二进制格式和调用方式，转成类 Unix 系统能接住的东西。

听起来像装一个包。实际是拆一座旧城。

作者先补 MinGW，让 Wine 能编译 PE DLL。到这一步，最基础的 Windows 程序才开始稳定。一个记事本，成了系统兼容性的体温计。

接着卡在图形栈。Astral 原本有 OpenGL，但 Wine 需要 EGL。问题是 Astral 的 Mesa 端原本没有 EGL，Mesa 的 xlib 后端也不支持这条路。

作者只能改走 DRI，也就是 Direct Rendering Infrastructure。它让应用更直接地和 GPU 打交道，也把问题从 Wine 推到了 Mesa、X.org 和 /dev/dri 路径上。

这就是桌面 OS 的现实：你以为自己在移植 Wine，实际在修 Mesa；你以为在修 Mesa，实际在补 X.org 路径；你以为图形栈通了，内核又伸手要账。

Cogmind 还带来另一个硬点：32 位 Windows 程序要跑在 64 位 Astral 上。

作者用 Wine 的 WoW64 支持，在 64 位进程里运行 32 位 Windows 二进制，不需要完整 32 位 Unix 用户态。但这要求内核支持 LDT，也就是 Local Descriptor Table，用来给每个进程配置 x86 段描述符。

这听着像考古。可今天的桌面兼容性，本来就经常是考古。

后面还有更典型的细节：Cogmind 分数上传失败，表面看像网络栈问题，根因却是 PE-to-Unix 转换里少保存了一个寄存器，引发未定义行为。

这种 bug 最能说明问题。桌面可用性不是靠一句“我们支持 Windows 程序”赢来的，而是靠寄存器、路径、回调、系统调用一点点抠出来的。

hobby OS 想日用，脏活才是分水岭

我更在意的不是 Astral 跑起了几个游戏，而是它把操作系统叙事里最容易被美化的部分戳破了。

内核、调度器、文件系统，适合写进项目介绍。用户真正会不会留下，常常死在浏览器、显卡驱动、字体、输入法、音频、网络边角和兼容层。

早期铁路也有类似问题。铁轨铺通只是开始，真正让铁路成为基础设施的，是时刻表、信号、车站调度、维修和票务。类比不完全一样，但结构很像：宏大工程拿掌声，日常系统靠脏活续命。

“天下大事，必作于细。”放在 Astral 这里不虚。它这次做对的，恰好是那些不光鲜的细节。

但热情不能替代约束。

Steam 还只是 partial。Chromium 启动相关的 GetInterfaceAddresses() 问题没有解决，浏览器和 Steam 客户端就会继续卡。Unity 游戏依赖 wine-mono，目前也没有走通。部分 DRM 游戏失败，更说明真实游戏生态不是单个 exe 能代表的。

接下来最该看三件事：

观察点为什么关键对谁有影响
Chromium / Firefox 能否启动并稳定运行浏览器是现代桌面的底座，也关系到 Steam 内嵌组件OS 开发者、桌面生态观察者
Unity 与 wine-mono 是否跑通大量独立游戏依赖这条链游戏开发者、兼容性测试者
DRI / Mesa / X.org 补丁能否持续维护一次截图不等于长期可用想复现或移植 Astral 经验的开发者

这也给读者一个现实动作。

如果你是普通玩家，不该因为这条进展就考虑迁移系统。现在适合看热闹、看技术路线，不适合押日用。

如果你是写 hobby OS 的开发者，倒可以把优先级往下压一层：少一点“我也要做漂亮桌面”的冲动，多一点“我先让 notepad、FTL、浏览器安装器别崩”的耐心。后者难看，但更接近可用。

我的判断很简单：Astral 不是在宣布 Windows 游戏属于 hobby OS 了。它只是证明，独立 OS 的可用性边界已经移动。

过去的边界是能不能启动内核。今天的边界是能不能接住现实世界几十年堆出来的软件债。

模型可以漂亮，内核可以漂亮，窗口系统也可以漂亮。桌面生态最难看的地方，是接口灰尘。谁愿意趴下去擦，谁才可能往前走半步。

这次更像一次技术验血。结果不完美，但血管已经通了一段。对 Astral 来说，这比一张“能跑游戏”的截图重要得多。