文章摘要
该文章介绍了作者在Astral操作系统上移植Wine的过程。此前Astral已能运行Minecraft等游戏，但许多Windows独占游戏需要Wine支持。作者以32位游戏Cogmind为目标，通过启用MinGW编译PE DLLs，成功让notepad.exe等基础功能正常运行。
文章总结
将Wine移植到Astral操作系统
几个月前，我分享过Astral——一个我多年来一直在开发的操作系统——成功运行《我的世界》的消息。此后，其他人也成功让《我的世界》现代版本以及《异星工厂》（通过兼容glibc的libc）运行起来。然而，这些游戏要么是专门为跨平台设计的，要么打包方式便于在新系统上运行，但大多数游戏并非如此。许多游戏是闭源的，且专为Windows编译，因此像Wine这样的兼容层对于运行它们至关重要。
我最喜欢的游戏之一《Cogmind》就属于这类情况。这是一款仅支持32位Windows的Roguelike游戏，我的目标就是让它在Astral上运行。虽然Astral已有Wine移植版，但极不完善，连记事本都无法正常使用。要运行《Cogmind》，必须完善Wine移植，这还意味着要在原本仅支持64位的系统中添加运行32位代码的能力。
基础Wine功能
第一步是下载MinGW并在Wine构建中启用它，因为编译PE动态链接库需要它。启用后，记事本可以运行，且“另存为”功能不再崩溃。
编译libEGL.so
仍有一个大问题：Wine编译时未启用OpenGL支持。虽然Astral支持OpenGL，但Wine明确需要EGL来工作，而Astral的Mesa移植版并未提供。EGL负责将OpenGL等渲染API连接到窗口系统，这是Wine正确初始化图形所必需的。起初看似简单——只需在Mesa中启用EGL即可。但Mesa在xlib后端不支持EGL，迫使我改用DRI后端。
DRI（直接渲染基础设施）允许应用程序更直接地与GPU通信，而非通过X服务器。这让我陷入困境：必须修补Mesa，使X.org服务器能在没有/dev/dri的情况下启动。最终我成功了，并成功运行了《Deltarune》这款游戏。
WoW64与32位Windows程序
由于《Cogmind》是32位而Astral是64位，需要更多基础设施。这通过Wine的WoW64模式实现，该模式无需任何32位Unix库。它通过在一个64位进程中运行32位Windows二进制文件，在需要时转换32位与64位系统调用和数据结构，从而避免构建完整的32位用户空间。
实现这一功能主要涉及在内核中支持LDT（局部描述符表），因为x86-64允许使用32位段描述符在长模式下运行32位代码。这些描述符定义了内存访问方式，对于代码段，还规定了处理器如何执行指令。LDT是定义这些段描述符的机制之一，并允许按进程配置它们。此外，还需要在Wine的信号和系统调用处理代码中进行精细的调整。
《Cogmind》成功运行！
在Astral移植版中实现WoW64支持并修复内核中的几个其他错误后，《Cogmind》终于可以运行了！游戏可玩，且无明显问题，仅游戏新闻和分数上传功能无法使用。
分数上传故障
该故障表现为：与《Cogmind》服务器的TCP连接建立后立即关闭，未传输任何数据。起初我以为是网络栈问题，但事实并非如此。
让我怀疑另有原因的是，Wine的调试日志函数__wine_dbg_write在WoW64模式下完全无法工作。深入Wine代码后，我最终发现自己在__wine_unix_call_dispatcher函数中忘记保存一个寄存器。这破坏了PE到Unix的转换，导致未定义行为。修复后，分数上传功能恢复正常。
更多游戏与程序
我还尝试运行了其他一些应用程序：
| 程序 | 状态 | 备注 |
|------|------|------|
| 《FTL》 | 正常 | 完全可玩。 |
| Steam | 部分 | 可安装和更新；因GetInterfaceAddresses()故障在Chromium启动时崩溃。 |
| iexplore.exe | 部分 | 简单网站可渲染；复杂页面因与Steam相同原因崩溃。 |
| 《异星工厂》 | 部分 | 窗口打开但卡在加载界面。 |
| 《Spooky's Jumpscare Mansion》 | 部分 | 启动但运行缓慢，无法游玩。 |
| 《Noita》 | 部分 | 启动但运行缓慢，无法游玩。 |
| 《植物大战僵尸》 | 故障 | 因Steam DRM阻止，无法进入主菜单。 |
| 《半条命》 | 故障 | Wine的C++运行时断言失败，可能是移植版缺少实现。 |
| Firefox / Chromium | 故障 | 安装程序失败，无法进入可运行状态。 |
| 《SCP：收容失效》 | 故障 | 无法启动，原因尚未诊断。 |
| Unity游戏（普遍） | 故障 | wine-mono在Astral上存在问题，Unity游戏卡在MonoManager ReloadAssembly。 |
最终感想
移植Wine是一次有趣的挑战，也证明了业余操作系统能运行比预期更多的游戏，这朝着让业余操作系统成为日常可用系统迈出了一步。虽然仍存在一些粗糙之处、性能问题和奇怪的崩溃，但核心功能已能工作。这个过程也让我深入了解了Wine的内部机制，尤其是在调试PE到Unix转换时。
我目前与Wine移植相关的一个重要目标是让Steam能正常工作，这也意味着Chromium能运行。至于Astral，我计划近期专注于优化、新驱动和错误修复。内核方面仍有大量改进空间。
感谢阅读！
评论总结
根据评论内容，总结主要观点如下：
1. 对操作系统标准化与兼容性的讨论 - 有评论呼吁为Windows老游戏建立类似“ROM格式”的标准化运行方案（评论1：“I wish people would start with a 'rom format' for windows games... no standardized way to run them”） - 另一观点指出，自制操作系统必须实现大量“遗留”接口（如TCP、POSIX）才能实用，难以独立创建新生态（评论3：“it cannot stand on its own... has to interface to the world and implement TCP, POSIX”）
2. 对自制操作系统价值的肯定 - 有开发者认为，自制OS可大幅简化通用系统的复杂性，满足个人计算需求，是绝佳实验平台（评论2：“we can remove much of the complexity... while still meeting our personal computing needs”） - 对Minecraft移植等具体成果表示赞赏（评论5：“very impressive work ; those writeups are a great read too”）
3. 技术实现层面的疑问 - 关注GPU驱动在自制OS上的实现难度（评论4：“how they got GPU drivers working for a hobby OS... I suspect this was difficult”） - 询问Wine是否原生运行，无需X服务器/模拟器（评论6：“Is this port running natively without using an X server / emulator?”）
4. 对多层兼容架构的惊叹 - 有评论对“自制OS支持Linux基础设施→支持Wine→支持Windows应用”的复杂堆叠表示震撼（评论7：“kind of crazy that we have a hobby OS that supports Linux infrastructure so that can support Wine infrastructure to support a Windows application”）
5. 思想实验：假设无历史包袱的OS设计 - 提出如果外星文明从零发明计算，自制OS会呈现何种形态（评论3：“as a thought experiment, as if aliens on another planet invented computing”）