将WINE移植到新爱好操作系统

# Astral 来源：https://astral-os.org/posts/2026/04/03/wine-on-astral.html ## 将Wine移植到Astral 在Astral上运行Wine 几个月前，我发布了一篇关于我多年来一直在开发的业余操作系统Astral的文章，展示它运行Minecraft (https://astral-os.org/posts/2025/10/31/astral-minecraft.html)。自那以后，其他人也成功让现代版本的Minecraft以及Factorio（使用兼容glibc的libc）运行起来。然而，尽管这些游戏在制作或打包时已考虑让它们更容易在新操作系统上运行，但大多数游戏并非如此。许多游戏是闭源且为Windows编译的，这使得像Wine这样的工具成为运行它们的必需。 我最喜欢的游戏之一，Cogmind (https://store.steampowered.com/app/722730/Cogmind/)，就属于这一类。它是一个仅支持32位Windows的Roguelike游戏，我的目标是让它能在Astral上运行。虽然已有现成的Wine移植，但它极不完整，连`notepad.exe`都无法正常工作。要运行Cogmind，必须完成Wine的移植，这还意味着要在原本仅支持64位的操作系统上添加运行32位代码的能力。 ## 基本Wine功能 让Wine运行的第一步是下载MinGW并在Wine构建中启用它，因为编译PE DLL需要它。启用后，`notepad.exe`可以运行，选择“另存为”也不再崩溃了！ 在Astral上通过Wine运行记事本 ## 编译libEGL.so 仍然存在一个大问题：Wine是在没有OpenGL支持的情况下编译的。虽然Astral有OpenGL，但Wine明确需要EGL才能工作，而Astral的Mesa移植并未提供EGL。EGL将OpenGL等渲染API连接到窗口系统，Wine需要它来正确初始化图形。起初，这似乎是一个简单的修复——只需在Mesa中启用EGL。然而，Mesa在xlib后端上不支持EGL，这迫使我改用DRI后端。 DRI（直接渲染基础设施）允许应用程序更直接地与GPU通信，而不是通过X服务器。这让我陷入了一个需要修补Mesa才能使X.org服务器在没有`/dev/dri`的情况下启动的兔子洞。最终，我成功了，并让一款真正的游戏Deltarune启动起来： 在Astrol上通过Wine运行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可以运行了！游戏可玩性不错，除了游戏新闻和分数表上传功能无法使用外，没有其他明显问题。 在Astrol上通过Wine运行Cogmind ## 分数表上传损坏 这个错误的表现为：向Cogmind服务器打开的TCP连接在没有任何数据传输的情况下立即关闭。起初我以为是网络栈的问题，但事实并非如此。 让我怀疑是其他问题的是，Wine的调试日志函数`__wine_dbg_write`在WoW64中完全无法工作。深入挖掘Wine的代码后，我最终发现自己在`__wine_unix_call_dispatcher`函数中忘记保存一个寄存器。这破坏了PE到Unix的转换并导致了未定义行为。修复此问题后，分数表上传可以正常工作了！(https://cogmind-api.gridsagegames.com/scoresheets/ioAnPYS3gE8UVKGF4.txt) ## 更多游戏和其他程序 我还尝试在Wine下运行其他一些应用程序： | 程序 | 状态 | 备注 | |------|------|------| | FTL | 可用 | 可完全游玩。 | | Steam | 部分可用 | 可安装和更新；由于`GetInterfaceAddresses()`损坏，在Chromium启动时崩溃。 | | iexplore.exe | 部分可用 | 简单网站可渲染；复杂页面因与Steam相同的根本原因而崩溃。 | | Factorio | 部分可用 | 窗口打开但加载后无法继续。 | | Spooky's Jumpscare Mansion | 部分可用 | 启动但运行太慢，无法游玩。 | | Noita | 部分可用 | 启动但运行太慢，无法游玩。 | | 植物大战僵尸 | 不可用 | 在到达主菜单前被Steam DRM阻止。 | | 半条命 | 不可用 | Wine的C++运行库断言失败。可能是移植中缺少实现。 | | Firefox / Chromium | 不可用 | 安装程序失败；未达到可运行状态。 | | SCP: Containment Breach | 不可用 | 无法启动；原因尚未诊断。 | | Unity游戏（普遍情况） | 不可用 | Astral上的wine-mono似乎存在问题，Unity游戏卡在`MonoManager ReloadAssembly`上。 | 在Astrol上通过Wine运行Noita 在Astrol上通过Wine运行FTL 在Astrol上通过Wine运行iexplore.exe ## 最后的思考 移植Wine是一个有趣的挑战，也证明了业余操作系统可以运行比原先想象的更多的游戏，这是向业余操作系统成为可行日常系统方向迈出的一步。虽然仍存在一些粗糙的边角、性能问题和奇怪的崩溃，但核心功能已经可用。这也让我对Wine的内部运作学到了很多，尤其是在需要深入挖掘来修复PE到Unix转换时。 我现在与Wine移植相关的重大目标之一是让Steam正常工作，这也意味着Chromium可以运行。至于Astral，我计划在未来更专注于优化、新驱动程序和错误修复。内核方面还有很多改进空间。 感谢阅读！