Madeira 项目解析：Wine + FEX-Emu + DXMT 在 ARM 设备上运行 Windows 应用

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

第一次看到“Madeira”这个项目名，很多人会以为是葡萄酒产地的工具，或者某个海岛旅游相关的应用。但把关键词里的 Wine、FEX-Emu、DXMT、iOS、x86-64 这几个词摆在一起，方向就清楚了：这是一个围绕在非 x86 平台上运行 Windows 应用的兼容层项目，而且它的野心不止于桌面端，还把手伸向了 iOS 这类 ARM 架构的移动设备。

Wine 本身不是模拟器，它是一个“兼容层”，把 Windows 的 API 调用翻译成宿主系统能听懂的调用。这个翻译过程不需要虚拟化整个 Windows 内核，所以开销比虚拟机小得多。但问题在于，Wine 在 x86 的 Linux 或 macOS 上跑得好，是因为指令集一致，CPU 能直接执行 Windows 程序的机器码。一旦宿主换成 ARM 架构的设备，比如 Apple Silicon 的 Mac 或者 iPhone、iPad，指令集对不上，就必须再加一层“指令翻译”，把 x86-64 的机器码实时翻译成 ARM64 能执行的指令。FEX-Emu 干的就是这件事。

所以 Madeira 的核心链路可以粗略理解为：Windows 应用 → Wine 翻译 Win32/Win64 API → FEX-Emu 翻译 x86-64 指令 → 宿主系统（可能是 iOS、macOS、Linux ARM）执行。而 DXMT 则是这条链路上负责图形的那一环，它把 Direct3D 调用翻译成 Metal，让游戏和图形界面能在 Apple 的图形栈上跑起来。

这套组合解决的是一个非常具体的痛点：你手头只有一台 ARM 设备，但某个 Windows 软件或游戏你非用不可，又不想开虚拟机、不想买 x86 机器。Madeira 想做的，就是把这套“Wine + FEX-Emu + DXMT”的拼装方案打包成一个相对可用的整体，降低普通用户自己折腾的门槛。

适合读这篇内容的人有三类：一是想在 ARM Linux 或 macOS 上跑 Windows 程序的技术爱好者；二是对 iOS 上运行桌面级应用感兴趣、想了解可行性的开发者；三是单纯对 Wine 生态和指令翻译技术好奇、想搞清楚这些组件怎么协作的人。下面我会按“为什么这样选型”“各组件怎么配合”“实际会遇到什么坑”“怎么排查”这几个角度，把 Madeira 这类项目背后的东西拆开讲。

2. 为什么是 Wine + FEX-Emu + DXMT 这个组合

2.1 Wine 在 ARM 平台上的天然短板

Wine 的设计初衷是“在 POSIX 系统上运行 Windows 程序”，它假设宿主 CPU 能直接执行目标程序的指令。在 x86 Linux 上，这个假设成立，所以 Wine 只需要处理 API 翻译，不需要碰指令集。但到了 ARM 平台，Windows 程序编译出来的是 x86 或 x86-64 机器码，ARM CPU 根本不认识。这时候你有两个选择：一是用完整的虚拟机模拟一颗 x86 CPU，比如 QEMU 的全系统模拟，性能损失巨大；二是用用户态的指令翻译，只翻译应用程序的指令，系统调用还是走宿主内核，FEX-Emu 就是后者。

FEX-Emu 的工作方式有点像“即时编译”：它把 x86-64 的指令块翻译成 ARM64 的指令块，翻译结果可以缓存起来重复使用。第一次执行某段代码会慢，后面就快了。这种方案比全系统模拟轻量得多，因为它不需要模拟整个硬件环境，只需要处理用户态指令。但代价是兼容性不可能做到 100%，某些依赖特定 CPU 行为或未文档化指令的程序会出问题。

2.2 DXMT 补上图形这块拼图

Wine 自带一个叫 WineD3D 的组件，负责把 Direct3D 翻译成 OpenGL。但在 Apple 平台上，OpenGL 已经被标记为废弃，Metal 才是亲儿子。DXMT 的思路是直接把 D3D 翻译成 Metal，跳过 OpenGL 这一层，理论上能拿到更好的性能和更少的兼容性问题。对于游戏来说，这一步至关重要，因为图形翻译的效率直接决定帧率。

DXMT 目前主要覆盖 D3D11 和部分 D3D12 的特性，D3D9 及更早的版本还是走 WineD3D 更稳妥。所以在实际配置时，你需要根据目标程序使用的图形 API 来决定启用哪条路径。如果程序是 D3D11 的，DXMT 优先；如果是老旧的 D3D9 游戏，可能 WineD3D 反而更省心。

2.3 为什么不是 CrossOver 或 Parallels

有人会问，既然有 CrossOver 这种商业方案，为什么还要自己拼 Wine + FEX-Emu？原因有几个：CrossOver 在 Apple Silicon 上的方案也是基于 Wine 和 Rosetta 2 的，但 Rosetta 2 只在 macOS 上可用，iOS 上没有。而 Madeira 这类项目想覆盖的是更广的 ARM 设备，包括 iOS 和 ARM Linux。另外，自己拼装意味着你可以控制每个组件的版本和配置，遇到问题时能深入排查，而不是等商业公司发更新。

注意：在 iOS 上运行 Wine 类方案，受限于系统的沙盒机制和签名策略，实际能做的事情比 macOS 和 Linux 少得多。很多在桌面端可行的操作，到了 iOS 上会被系统限制挡住。这一点在后面会详细说。

3. 指令翻译层 FEX-Emu 的实际工作方式与配置要点

3.1 FEX-Emu 的翻译缓存机制

FEX-Emu 在第一次遇到一段 x86-64 代码时，会把它翻译成 ARM64 指令，然后把翻译结果存到一个缓存目录里。下次再执行同一段代码，直接读缓存，省掉翻译时间。这个缓存目录的位置和大小是可以配置的，默认可能在用户主目录下的某个隐藏文件夹里。如果你发现某个程序第一次启动特别慢、后面就快了，大概率就是 FEX-Emu 在建立缓存。

缓存带来的一个副作用是：如果你更新了 FEX-Emu 的版本，旧缓存可能不兼容，需要清掉重建。清缓存的操作通常是删除缓存目录，然后重新启动程序让它重新翻译。这个操作在排查“更新后程序反而跑不起来”这类问题时非常有用。

3.2 多线程与单线程的取舍

FEX-Emu 有一个配置项控制它是否使用多线程翻译。多线程翻译能加快首次翻译速度，但在某些程序上可能引入不稳定的问题，因为翻译线程和执行线程之间的同步可能出岔子。如果你遇到程序随机崩溃、画面卡死但声音还在走这类现象，可以试试关掉多线程翻译，用单线程模式跑一遍，看问题是否消失。

这个取舍的逻辑是：多线程翻译追求的是“首次启动快”，单线程翻译追求的是“运行稳”。对于日常使用的程序，首次启动慢几秒可以接受，但运行中崩溃是不可接受的。所以我的建议是默认用单线程，除非你确实需要频繁启动大量不同的程序。

3.3 环境变量与启动参数

FEX-Emu 通过环境变量来控制行为，常见的几个包括：

• FEX_TSOENABLED：控制是否启用 x86 的内存序模拟。x86 是强内存模型，ARM 是弱内存模型，某些多线程程序依赖 x86 的内存序行为，关掉这个可能导致数据竞争问题。
• FEX_ROOTFS：指定一个根文件系统路径，用于提供 Windows 程序需要的某些系统库。
• FEX_MULTIBLOCK：控制是否启用多块翻译，影响翻译粒度和性能。

这些变量不需要全部手动设置，很多会被 Wine 的启动脚本自动处理。但当你需要微调时，知道它们的存在能帮你快速定位问题。比如某个多线程程序在 ARM 上跑出奇怪的结果，可以试试打开FEX_TSOENABLED，虽然会损失一点性能，但能换来正确性。

4. 图形翻译 DXMT 的启用条件与常见故障

4.1 DXMT 和 WineD3D 的切换逻辑

Wine 默认用 WineD3D 处理所有 Direct3D 调用。要启用 DXMT，你需要确保 DXMT 的 DLL 被正确注册到 Wine 的配置里，并且设置相应的环境变量告诉 Wine 优先使用 DXMT。通常的做法是把 DXMT 提供的d3d11.dll、dxgi.dll等文件放到 Wine 的前缀目录里，覆盖或替代原有的 DLL。

但这里有个坑：不是所有程序都兼容 DXMT。有些程序会检测 DLL 的版本号或签名，发现不是微软原版就拒绝运行。遇到这种情况，你可能需要换回 WineD3D，或者用工具伪装 DLL 信息。这个问题的排查方法是：先看程序是否启动，如果启动后黑屏或闪退，再检查 Wine 的日志里有没有 D3D 相关的报错。

4.2 Metal 着色器编译卡顿

DXMT 把 D3D 着色器翻译成 Metal 着色器时，第一次遇到某个着色器会有编译开销。如果程序在运行中动态生成大量着色器，你会看到周期性的卡顿。这个现象在游戏里特别明显，比如进入新场景时帧率骤降，过几秒又恢复。

缓解办法是提前“预热”着色器，有些游戏支持预编译着色器缓存的选项，打开它能减少运行中的卡顿。另外，Metal 的着色器缓存也可以持久化，下次运行同一程序时直接读缓存。这个缓存的清理和 FEX-Emu 的缓存类似，更新图形驱动或 DXMT 版本后可能需要清掉重建。

4.3 图形相关的常见报错与含义

这张表不是穷举，但覆盖了大部分常见情况。排查时先看报错关键词，再对照可能原因，能省不少时间。

5. 在 iOS 上跑这套方案的现实约束

5.1 沙盒与签名：两道绕不过去的墙

iOS 的沙盒机制决定了每个应用只能访问自己的容器目录，不能随意读写系统其他位置。Wine 需要创建一个“前缀”目录来模拟 Windows 的 C 盘结构，这个目录必须放在应用自己的容器里。这本身可行，但问题是 Wine 的某些组件需要执行动态生成的代码，而 iOS 对可执行内存的管理非常严格，JIT（即时编译）在普通应用上是受限的。

FEX-Emu 的翻译过程本质上就是 JIT，它需要把翻译出来的 ARM64 指令写到可执行内存里再跳过去执行。在 macOS 上，这需要关闭 SIP 或者给应用特定的权限；在 iOS 上，普通应用根本没有这个权限。所以如果你看到有人在 iOS 上跑 FEX-Emu，大概率是利用了开发者模式或者某些企业签名提供的额外权限，而不是普通用户能直接复现的。

5.2 开发者模式能带来什么

iOS 的开发者模式主要是为了调试应用，它放宽了一些限制，比如允许应用加载未签名的动态库、允许更灵活的内存管理。但即便如此，JIT 权限也不是随便就能拿到的，通常需要应用具备特定的 entitlement，而这些 entitlement 只有通过特定渠道分发的应用才能获得。

所以对于普通用户来说，在 iOS 上跑 Madeira 这类方案的可行性很低。更现实的做法是在 macOS 或 ARM Linux 上跑，这两个平台对 JIT 和动态库加载的限制宽松得多。如果你只是想在 iPhone 上玩 Windows 游戏，目前更靠谱的方案还是串流，而不是本地翻译执行。

5.3 iOS 上的替代思路

如果你确实需要在 iOS 设备上访问 Windows 应用，可以考虑远程桌面类的方案：在 x86 机器或云主机上跑 Windows，然后用 iOS 设备远程连接。这种方式不涉及指令翻译，兼容性最好，但对网络质量有要求。另一种思路是用 Web 技术重写应用，把计算放到服务端，iOS 端只做展示和交互。这两种方案都比本地翻译执行更稳定，只是适用场景不同。

6. 从零搭建时的环境准备与依赖检查

6.1 宿主系统的选择

搭建这套环境，宿主系统的选择很关键。目前比较成熟的是 ARM64 的 Linux 发行版，比如 Ubuntu ARM64 或 Fedora ARM64。这些系统对 Wine 的支持比较完善，FEX-Emu 也有现成的包可以安装。macOS 上因为 Apple 的 Rosetta 2 已经能翻译 x86-64，所以 FEX-Emu 的必要性没那么强，但如果你想跑的是 Windows 程序而不是 macOS 程序，Wine 还是需要的。

选择宿主时需要考虑几个因素：内核版本是否支持所需的内存管理特性、图形驱动是否支持 Metal 或 Vulkan、包管理器里是否有现成的 Wine 和 FEX-Emu 包。如果这些条件都满足，搭建过程会顺利很多。

6.2 依赖组件的安装顺序

安装顺序会影响后续的配置难度。我的建议是：

1. 先装 FEX-Emu，确认它能独立运行一个简单的 x86-64 Linux 程序。这一步验证指令翻译层是否工作正常。
2. 再装 Wine，确认它能运行一个简单的 Windows 程序（比如记事本）。这一步验证 API 翻译层是否工作正常。
3. 然后把两者结合起来，让 Wine 通过 FEX-Emu 运行 Windows 程序。这一步验证两层翻译的协作。
4. 最后装 DXMT，测试图形程序。这一步验证图形翻译层。

这个顺序的好处是每一步都有明确的验证目标，出问题时能快速定位是哪一层的问题。如果一上来就全部装好再测试，出了问题很难判断是哪个组件配置错了。

6.3 验证每一步是否成功

验证 FEX-Emu 是否工作，可以跑一个 x86-64 的 Linux 命令行工具，比如uname -m在 FEX-Emu 环境下应该输出x86_64而不是aarch64。验证 Wine 是否工作，可以跑wine notepad，看能否弹出记事本窗口。验证 DXMT 是否工作，可以跑一个简单的 D3D11 测试程序，看能否正常渲染。

每一步验证通过后再进行下一步，这样即使后面出问题，你也能确定前面的基础是牢的。这个“分步验证”的思路在排查复杂系统时非常有用，不要嫌麻烦跳过。

7. 实际运行中的典型故障与排查链路

7.1 程序启动即崩溃：先看日志再猜原因

程序启动就崩溃是最常见的问题，原因可能出在 FEX-Emu、Wine、DXMT 任何一层。排查的第一步是拿到日志。Wine 有WINEDEBUG环境变量可以控制日志级别，比如WINEDEBUG=+loaddll会打印 DLL 加载信息，WINEDEBUG=+d3d会打印 D3D 相关日志。FEX-Emu 也有自己的日志输出，通常在启动时加一个参数就能打开。

拿到日志后，先找第一个报错，而不是最后一个。因为后面的报错往往是第一个报错引发的连锁反应。比如你看到一堆Failed to load d3d11.dll，那问题就是 DXMT 的 DLL 没放对位置，而不是 D3D 本身有问题。

7.2 界面乱码：字体和编码的双重问题

Wine 在非中文环境下经常出现界面乱码，这是因为 Wine 默认的字体配置不包含中文字体，或者编码设置不对。解决办法是往 Wine 的前缀里安装中文字体，比如把 Windows 的宋体或黑体复制到drive_c/windows/Fonts目录，然后在注册表里设置字体替换规则。

编码问题则更隐蔽一些。有些程序依赖系统的区域设置来决定使用哪种编码，如果 Wine 的区域设置和程序预期的不一致，就会显示乱码。可以在 Wine 的配置里把区域设置改成zh_CN.UTF-8或zh_CN.GBK，看哪种能让程序正常显示。

7.3 性能突然下降：检查缓存和后台进程

如果程序之前跑得好好的，突然变慢，先检查两件事：一是 FEX-Emu 的翻译缓存是否被清掉了，导致重新翻译；二是是否有后台进程在占用 CPU 或内存。FEX-Emu 的翻译过程是 CPU 密集型的，如果同时有其他重负载任务，翻译速度会明显下降。

另一个可能的原因是 Metal 着色器缓存失效，导致运行中重新编译着色器。这种情况通常发生在更新了图形驱动或 DXMT 之后。解决办法是让程序重新跑一遍，等缓存重建完成，性能就会恢复。

7.4 网络功能异常：Wine 的网络栈与宿主不同

Wine 的网络栈是独立实现的，它把 Windows 的 socket 调用翻译成宿主系统的 socket 调用。大部分情况下这没问题，但某些程序会依赖 Windows 特有的网络行为，比如特定的 TCP 选项或注册表里的网络配置。如果程序能启动但网络功能异常，可以先检查 Wine 的网络配置，确认 DNS 和代理设置是否正确传递。

还有一个常见问题是证书。Windows 程序可能依赖系统的证书存储，而 Wine 的证书存储是独立的，需要手动导入证书。如果程序报 SSL 错误，可以试试把宿主系统的证书导出，再导入到 Wine 的证书存储里。

8. 性能调优的几个实操方向

8.1 翻译缓存的预热与持久化

FEX-Emu 的翻译缓存默认可能放在临时目录里，重启后就没了。你可以通过配置把它放到一个持久化的目录，这样每次重启后不用重新翻译。具体做法是设置FEX_CACHE_DIR环境变量指向一个固定路径，并确保这个路径有足够的空间。

预热则是另一个思路：在正式使用前，先跑一遍程序的主要功能，让 FEX-Emu 把常用代码路径都翻译好。这样正式使用时就不会遇到首次翻译的卡顿。对于游戏来说，可以先进训练模式或低负载场景跑一圈，再进正式对战。

8.2 图形设置的取舍

DXMT 的性能和图形设置密切相关。降低分辨率、关闭抗锯齿、减少阴影质量，都能显著减轻翻译层的负担。因为翻译层需要处理的像素和着色器指令少了，帧率自然就上去了。如果你发现某个游戏在 DXMT 下帧率不理想，先试试把画质调到最低，看帧率是否改善。如果改善了，说明瓶颈在图形翻译，可以逐步调高画质找到平衡点。

另一个技巧是限制帧率。有些游戏在无限制帧率下会跑满 CPU，导致翻译层没有足够的 CPU 时间来做翻译，反而造成卡顿。把帧率限制在 30 或 60，给翻译层留出余量，整体体验可能更流畅。

8.3 CPU 亲和性与优先级调整

FEX-Emu 的翻译线程和执行线程可能在不同的 CPU 核心上跑。如果宿主系统的调度器把这两个线程放到同一个核心上，性能会受影响。你可以用taskset或类似的工具把翻译线程绑定到特定的核心，把执行线程绑定到另一组核心，减少争抢。

优先级调整则是另一个方向：把 Wine 和 FEX-Emu 的进程优先级调高，让它们在 CPU 资源紧张时能优先获得时间片。这个操作在 Linux 上用nice或chrt就能做，但要注意不要调得太高，否则可能影响系统其他关键进程。

9. 这套方案适合谁，不适合谁

9.1 适合的场景

如果你是一个喜欢折腾的技术爱好者，手头有 ARM 设备，想跑一些对性能要求不高的 Windows 程序，比如老游戏、办公软件、小工具，这套方案是值得一试的。它的优势在于不需要虚拟机，资源占用相对小，而且所有组件都是开源的，你可以深入定制。

另一个适合的场景是开发测试。如果你需要验证某个 Windows 程序在 ARM 环境下的行为，但又不想买 x86 机器，可以用这套方案快速搭一个测试环境。虽然不能保证 100% 还原真实 Windows 的行为，但对于大部分兼容性测试来说够用了。

9.2 不适合的场景

如果你追求的是“开箱即用”的体验，这套方案不适合你。它的配置过程涉及多个组件，每个组件都有自己的坑，没有一定的技术基础很难搞定。商业方案如 CrossOver 或虚拟机软件虽然要花钱，但省心得多。

如果你需要跑的是对性能要求很高的 3A 游戏或专业图形软件，这套方案也不适合。指令翻译和图形翻译的开销叠加起来，性能损失可能达到 50% 甚至更多。这种情况下，原生 x86 机器或云游戏方案是更好的选择。

9.3 投入产出比的现实评估

从投入产出比来看，这套方案适合那些“折腾本身就是乐趣”的人。如果你把搭建过程当作学习机会，了解指令翻译、API 翻译、图形翻译的原理，那投入的时间是值得的。但如果你只是想尽快用上某个 Windows 程序，那直接买一台便宜的 x86 迷你主机可能更划算。

我在实际使用中的体会是：这套方案的价值不在于替代 Windows，而在于提供一种可能性。它让你在 ARM 设备上也能接触到 Windows 生态，虽然不完美，但足够打开一扇门。随着 FEX-Emu 和 DXMT 的持续更新，兼容性和性能都在慢慢改善，未来值得期待。

10. 几个容易被忽略的细节和后续可扩展方向

10.1 时区和区域设置的传递

Wine 默认可能不会继承宿主系统的时区和区域设置，导致程序显示的时间不对，或者日期格式不符合预期。解决办法是在 Wine 的注册表里手动设置时区和区域，或者在启动脚本里通过环境变量传递。这个细节很小，但会影响用户体验，特别是对于依赖时间戳的程序。

10.2 音频子系统的选择

Wine 支持多种音频后端，比如 PulseAudio、ALSA、CoreAudio。在 ARM Linux 上，PulseAudio 通常是默认选择，但在某些发行版上可能需要手动配置。如果程序没有声音，先检查 Wine 的音频驱动设置，确认它用的是宿主系统支持的音频后端。

10.3 后续可扩展的方向

这套方案的后续扩展可以往几个方向走：一是自动化配置脚本，把繁琐的手动步骤封装成一键脚本，降低使用门槛；二是兼容性数据库，收集哪些程序在哪些配置下能跑、哪些不能跑，方便用户查询；三是性能分析工具，帮助用户定位瓶颈在翻译层还是图形层。

这些方向都需要社区协作，单靠一个人很难做全。如果你对某个方向感兴趣，可以从自己遇到的问题出发，把解决过程整理成文档或脚本分享出来。这种“从问题到方案”的积累，正是这类项目能持续进步的动力。