Madeira：Wine+FEX-Emu+DXMT 在 ARM 设备上运行 Windows 程序

1. 从“Madeira”这个名字说起：它到底想解决什么问题

第一次看到“Madeira”这个项目名，很多人会以为是葡萄酒相关的项目，毕竟马德拉酒确实有名。但结合关键词里的 Wine、FEX-Emu、DXMT、x86-64 来看，这里的 Wine 显然指的是那个著名的兼容层项目，而不是饮品。Madeira 这个名字大概率是在向 Wine 生态致敬——马德拉岛以葡萄酒闻名，而 Wine 本身就是“Wine Is Not an Emulator”的递归缩写，用产地来命名一个围绕 Wine 生态的工具，逻辑上说得通。

那 Madeira 到底要做什么？从关键词组合推断，它瞄准的是一个非常具体的痛点：在非 x86 架构的设备上，通过 Wine 生态运行 Windows 应用和游戏。这里涉及三个核心技术组件：Wine 负责提供 Windows API 的兼容实现，FEX-Emu 负责把 x86-64 指令翻译成 ARM64 指令，DXMT 负责把 Direct3D 调用翻译成 Metal 调用。三者叠加，才能让一个原本为 Windows x86-64 编译的程序，在 ARM 设备上跑起来。

这个组合解决的是什么问题？简单说，就是让 ARM 设备（比如 Apple Silicon Mac、部分 ARM Linux 设备）能够运行那些没有 ARM 原生版本的 Windows 软件和游戏。传统的做法是虚拟机或者远程桌面，但虚拟机需要完整的 Windows 系统镜像，资源占用大，而且图形性能经过多层转换后损失严重。Madeira 的思路是走兼容层路线，不模拟整个操作系统，只翻译必要的 API 和指令，理论上效率更高。

适合谁来参考？如果你是在 ARM 设备上折腾 Windows 软件的用户，或者对 Wine 生态、指令翻译、图形 API 转换感兴趣的技术爱好者，这个项目值得关注。如果你只是想在 Mac 上跑某个 Windows 小工具，可能现成的商业方案更省事，但如果你想理解底层发生了什么，或者想参与贡献，那 Madeira 的技术路线就很有研究价值。

提示：Wine 生态的项目命名经常玩文字游戏，Madeira 既呼应了 Wine，又暗示了“产地”的概念，这种命名方式在开源社区很常见，理解名字背后的逻辑有助于快速定位项目定位。

2. Wine + FEX-Emu + DXMT 三层架构的协作逻辑

2.1 为什么需要三层而不是一层

很多人第一次接触这类方案时会问：Wine 不是已经能跑 Windows 程序了吗，为什么还要 FEX-Emu 和 DXMT？答案在于架构差异。Wine 本身只解决了 API 层面的兼容问题——它把 Windows 的系统调用翻译成 POSIX 调用，把 Windows 的库文件替换成开源实现。但 Wine 不负责指令集翻译，它假设你的 CPU 能直接执行目标程序的机器码。

在 x86-64 设备上，这个假设成立，所以 Wine 可以独立工作。但在 ARM64 设备上，Windows 程序编译出来的是 x86-64 指令，ARM CPU 根本不认识。这时候就需要 FEX-Emu 出场，它负责把 x86-64 指令动态翻译成 ARM64 指令。这个过程叫“二进制翻译”，不是模拟，因为不模拟整个硬件环境，只翻译指令流。

那 DXMT 呢？Windows 游戏和应用大量使用 Direct3D 渲染，而 ARM 设备上主流图形 API 是 Metal（Apple 平台）或 Vulkan（Linux 平台）。DXMT 的作用就是把 D3D 调用转换成 Metal 调用，让图形渲染能够利用本地 GPU 加速。如果没有 DXMT，Wine 只能用软件渲染或者 OpenGL 转换层，性能会差很多。

三层各司其职：FEX-Emu 解决“CPU 看不懂指令”的问题，Wine 解决“系统调用不匹配”的问题，DXMT 解决“图形 API 不兼容”的问题。缺一层，整个链路就断了。

2.2 各层的性能开销与瓶颈在哪里

三层叠加意味着每次调用都要经过多次转换，性能开销不可避免。FEX-Emu 的指令翻译有缓存机制，热代码翻译一次后可以重复使用，但冷代码首次执行时延迟明显。Wine 的 API 转换大部分是轻量级的函数跳转，开销相对小，但涉及文件系统、注册表、网络等复杂操作时，转换成本会上升。DXMT 的图形转换是性能大头，尤其是着色器编译和状态切换，处理不好会严重掉帧。

实测中常见的瓶颈排序是：图形转换 > 指令翻译 > API 转换。所以优化重点通常放在 DXMT 的着色器缓存和 FEX-Emu 的翻译缓存上。Madeira 如果要做性能调优，这两个方向是绕不开的。

2.3 这套组合的适用边界

不是所有 Windows 程序都能在这套架构下跑起来。依赖内核态驱动的程序基本没戏，比如需要安装驱动级别的反作弊系统、需要直接访问硬件的专业软件。依赖 .NET 或 Java 运行时的程序相对好办，因为运行时本身可以跑在兼容层上。游戏方面，DX9 到 DX11 的支持相对成熟，DX12 和 Vulkan 的转换还在完善中。

另外，32 位程序的兼容性通常比 64 位好，因为 32 位指令翻译更成熟，而且很多老程序对系统 API 的依赖更简单。如果你要测试某个程序能否运行，先看它是不是 64 位、是不是依赖内核驱动、用的是哪个版本的 D3D，这三个信息基本能判断成功率。

3. 在 ARM 设备上跑通第一个 Windows 程序的完整路径

3.1 环境准备：别急着装 Wine，先把基础依赖理清楚

很多人一上来就找 Wine 的安装包，结果装完发现跑不起来，回头查日志才发现缺了一堆依赖。正确的顺序是先确认系统环境，再按依赖层级逐步安装。

第一步是确认 CPU 架构和系统版本。在终端执行uname -m，如果是aarch64或arm64，说明是 ARM64 设备。然后确认系统发行版和版本号，不同发行版的包管理器和库路径不同，后续安装命令会有差异。

第二步是安装 FEX-Emu。FEX-Emu 通常需要从源码编译或者用预编译包，具体取决于发行版。编译时需要 CMake、Clang 或 GCC、Python 等基础工具。如果发行版仓库里有 FEX-Emu 包，优先用包管理器安装，省去编译时间。

第三步是配置 Wine。Wine 在 ARM64 上运行时需要 FEX-Emu 作为指令翻译后端，所以 Wine 的配置里要指定使用 FEX-Emu。具体做法是设置环境变量或者修改 Wine 的配置文件，让它在执行 x86-64 程序时调用 FEX-Emu 而不是直接执行。

第四步是安装 DXMT。DXMT 通常以 Wine 的 DLL 形式提供，需要放到 Wine 的库目录下，并在 Wine 配置中启用。有些发行版会把 DXMT 打包成独立的包，安装后自动配置。

注意：不同发行版的库路径和配置方式差异很大，网上教程只能参考思路，具体命令要以你的系统为准。遇到报错先看日志，Wine 的日志通常会指出缺失的库或配置错误。

3.2 创建 Wine 前缀并验证基础功能

Wine 前缀（prefix）是 Wine 模拟的 Windows 环境，每个前缀相当于一个独立的 Windows 安装。建议为不同类型的程序创建不同的前缀，避免依赖冲突。

创建前缀的命令是WINEPREFIX=/path/to/prefix wineboot -u，这会初始化一个 64 位前缀。如果需要 32 位前缀，加上WINEARCH=win32环境变量。初始化完成后，可以用wine notepad测试基础功能，如果能弹出记事本窗口，说明 Wine 本身工作正常。

接下来测试 FEX-Emu 是否生效。找一个简单的 x86-64 Windows 程序，比如一个命令行工具，用 Wine 运行它。如果程序能执行并输出结果，说明 FEX-Emu 的指令翻译链路通了。如果报“无法执行二进制文件”之类的错误，检查 FEX-Emu 的配置是否正确。

最后测试 DXMT。找一个使用 D3D 渲染的简单程序，比如一个老游戏或者 D3D 测试工具。如果能正常渲染画面，说明 DXMT 的图形转换链路通了。如果黑屏或崩溃，检查 DXMT 的 DLL 是否放对位置，以及 Wine 的 DLL 覆盖设置是否正确。

3.3 安装和运行目标程序的实操细节

安装 Windows 程序时，直接用wine setup.exe运行安装程序。安装过程中可能会遇到乱码问题，这是因为 Wine 默认的中文字体配置不完整。解决办法是安装中文字体到 Wine 的字体目录，或者在 Wine 配置中指定系统字体。

运行程序时，如果遇到缺少 DLL 的报错，可以用winetricks安装对应的运行库。winetricks 是一个脚本工具，可以自动下载和安装常见的 Windows 运行库，比如 .NET Framework、Visual C++ Redistributable、DirectX 运行库等。对于游戏，通常需要安装 d3dx9、vcrun2019、dotnet48 等。

如果程序启动后闪退，先看终端输出。Wine 会把错误信息打印到终端，常见的错误包括缺少 DLL、API 未实现、图形初始化失败等。根据错误信息搜索解决方案，通常能在 Wine 的 AppDB 或相关论坛找到答案。

4. 乱码、闪退、性能差：三类高频问题的排查链路

4.1 Wine 中文乱码的根因与修复

Wine 乱码是最高频的问题之一，表现为程序界面显示方块、问号或者乱码字符。根因是 Wine 默认的字体映射不包含中文字体，或者字体替换规则不正确。

排查链路是这样的：先确认系统里有没有中文字体，用fc-list :lang=zh查看。如果没有，先安装中文字体包。然后检查 Wine 的字体目录，通常在~/.wine/drive_c/windows/Fonts/，看看有没有中文字体文件。如果没有，把系统的中文字体复制过去，或者用 winetricks 安装字体。

接下来检查注册表中的字体替换规则。Wine 通过注册表把 Windows 字体名映射到实际字体文件，如果映射缺失或错误，就会乱码。可以用wine regedit打开注册表编辑器，定位到HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\FontSubstitutes，添加或修改字体替换项。

一个更省事的办法是用 winetricks 的fonts相关选项，比如winetricks corefonts安装微软核心字体，winetricks cjkfonts安装中日韩字体。安装后重启 Wine 程序，乱码通常能解决。

提示：如果只有部分程序乱码，可能是该程序使用了特殊的字体渲染方式，比如自绘字体或嵌入字体。这种情况下，字体替换可能无效，需要针对该程序单独处理。

4.2 程序闪退的逐步排查方法

闪退的原因很多，排查时要按层次逐步缩小范围。第一层是 Wine 本身的问题，比如前缀损坏、配置错误。可以尝试新建一个干净的前缀，重新安装程序，看是否还会闪退。如果新前缀正常，说明原前缀有问题，可能是某个 DLL 被覆盖或者注册表被改坏。

第二层是依赖缺失。用wine运行程序时加上WINEDEBUG=+loaddll环境变量，可以看到程序加载了哪些 DLL，哪些加载失败。根据缺失的 DLL 用 winetricks 安装对应的运行库。

第三层是 FEX-Emu 的指令翻译问题。有些 x86-64 指令 FEX-Emu 可能不支持或者翻译有误，导致程序崩溃。可以查看 FEX-Emu 的日志，看是否有未实现的指令或者翻译错误。如果确认是 FEX-Emu 的问题，可以尝试更新到最新版本，或者向 FEX-Emu 项目反馈。

第四层是 DXMT 的图形转换问题。如果程序在初始化图形时崩溃，可能是 DXMT 不支持某些 D3D 特性。可以尝试切换 DXMT 的配置，比如禁用某些高级特性，或者回退到软件渲染测试是否是图形问题。

4.3 性能优化的几个实际抓手

性能差的表现通常是帧率低、卡顿、加载慢。优化要从瓶颈入手，先确认瓶颈在哪一层。可以用WINEDEBUG=-all关闭调试输出减少开销，用FEX_DEBUG=0关闭 FEX-Emu 的调试日志。然后分别测试 CPU 密集和 GPU 密集的场景，判断瓶颈在指令翻译还是图形转换。

如果瓶颈在 FEX-Emu，可以尝试启用翻译缓存，让热代码翻译一次后重复使用。FEX-Emu 通常有配置项控制缓存大小和策略，适当增大缓存可以减少重复翻译。另外，确保 FEX-Emu 使用的是最新版本，新版本通常有性能改进。

如果瓶颈在 DXMT，可以尝试启用着色器缓存，避免每次运行都重新编译着色器。DXMT 的配置里通常有缓存相关的选项，开启后首次运行会慢一些，但后续运行会快很多。另外，降低游戏内的图形设置，比如分辨率、阴影质量、抗锯齿等，也能显著提升帧率。

如果瓶颈在 Wine 的 API 转换，可以尝试减少跨层调用，比如把频繁访问的文件放到内存盘，减少文件系统开销。对于网络密集型程序，检查 Wine 的网络配置，确保没有不必要的代理或重定向。

5. 从 Madeira 看兼容层方案的设计取舍

5.1 为什么不做全模拟而选择兼容层

全模拟（比如 QEMU 模拟整个 x86 系统）的优点是兼容性好，几乎能跑任何 x86 程序，但缺点是性能损失大，因为每条指令都要经过模拟器的解释执行。兼容层方案只翻译必要的部分，大部分调用直接映射到本地系统，性能损失小得多。

Madeira 选择兼容层路线，说明它更看重性能而不是极致的兼容性。这个取舍在游戏场景下尤其明显：全模拟跑 3D 游戏基本不可玩，而兼容层方案在优化得当的情况下可以达到可玩的帧率。代价是部分依赖内核态驱动的程序无法运行，但这部分程序在普通用户场景中占比不高。

5.2 组件选型背后的考量

FEX-Emu 而不是 QEMU 的用户态模拟，是因为 FEX-Emu 专注于 x86-64 到 ARM64 的指令翻译，不做全系统模拟，开销更小。DXMT 而不是 DXVK，是因为 DXVK 把 D3D 转成 Vulkan，而 Apple 平台对 Vulkan 的支持有限，Metal 才是原生 API。在 Linux ARM 设备上，DXVK 可能更合适，但在 Apple Silicon 上，DXMT 是更自然的选择。

Wine 作为 API 兼容层是成熟方案，生态完善，社区活跃，遇到问题容易找到资料。而且 Wine 支持插件式配置，可以灵活替换图形后端、指令翻译后端，这为 Madeira 这样的集成方案提供了基础。

5.3 这套方案的天花板在哪里

兼容层方案的天花板主要受限于三个方面：指令翻译的覆盖率、图形 API 的转换完整度、以及反作弊和数字版权管理系统的兼容性。指令翻译方面，FEX-Emu 对大多数常用指令支持良好，但一些冷门指令或新扩展指令可能缺失。图形方面，DXMT 对 D3D11 的支持相对成熟，D3D12 和光追还在完善中。反作弊系统方面，很多在线游戏的反作弊会检测运行环境，兼容层容易被识别并拒绝运行。

所以 Madeira 这类方案更适合单机游戏、老游戏、生产力工具，而不是最新的在线竞技游戏。如果你主要玩单机大作或者用 Windows 独占的生产力软件，这套方案值得折腾。如果你主玩在线竞技游戏，建议还是用原生 Windows 设备。

6. 实操中积累的几个经验教训

折腾 Wine 生态这些年，有几个教训是反复踩坑才记住的。第一个是不要混用不同来源的 Wine 包和 DXMT 包，版本不匹配会导致各种奇怪的问题。最好用同一个发行版仓库或者同一个项目的发布包，确保组件之间的兼容性。

第二个是善用独立前缀。很多人图省事把所有程序装在一个前缀里，结果某个程序安装了特定版本的运行库，把另一个程序依赖的运行库覆盖了，导致后者崩溃。为每个重要程序创建独立前缀，虽然占磁盘空间，但能避免大量冲突问题。

第三个是日志是你的朋友。Wine 和 FEX-Emu 的日志信息很丰富，遇到问题先看日志，比盲目搜索效率高得多。把日志级别调高，重现问题，然后根据日志中的错误信息定位原因，这个流程能解决大部分问题。

第四个是不要追求最新版本。Wine 和 FEX-Emu 的开发版可能引入新特性，但也可能引入新 bug。如果当前版本能稳定运行你需要的程序，没必要频繁升级。等新版本经过一段时间验证后再升级，能避免很多不必要的麻烦。

第五个是社区资源比官方文档更实用。Wine 的 AppDB 里有大量用户提交的兼容性报告和配置方案，遇到冷门程序时，先搜 AppDB 看有没有人已经跑通了，能省很多时间。FEX-Emu 和 DXMT 的 issue 区也经常有开发者回复，遇到疑似 bug 可以去搜索或提问。

提示：如果你在 ARM 设备上跑 Windows 程序时遇到性能问题，先确认是不是用了软件渲染。很多情况下，DXMT 没有正确加载，Wine 回退到了软件渲染，导致帧率极低。检查 Wine 的日志中是否有 DXMT 相关的加载信息，确认图形后端是否正确初始化。