ARM设备运行Windows游戏：Wine+FEX-Emu+DXMT跨平台兼容实战

1. 从"Madeira"这个名字说起：一个跨平台兼容层的真实需求

第一次看到"Madeira"这个项目名，很多人会以为是某个度假岛屿或者葡萄酒品牌——毕竟马德拉岛确实以加强型葡萄酒出名。但放在当前的技术语境里，结合 Wine、FEX-Emu、DXMT、x86-64 这些关键词，它指向的其实是一个非常具体的方向：在非 x86 架构的平台上，把 Windows 应用和游戏跑起来。

这个需求不是凭空冒出来的。过去几年，ARM 架构的设备性能突飞猛进，Apple Silicon 的 Mac、高通骁龙 X Elite 的笔记本、各种 ARM 服务器和掌机层出不穷。但问题在于，大量存量软件——尤其是 Windows 生态里的游戏、行业工具、老版本专业软件——依然是 x86-64 指令集编译的。你不可能要求所有开发者重新编译一遍，于是"翻译层"就成了刚需。

Madeira 在这个背景下扮演的角色，可以理解为一个整合层或者发行版性质的项目：它把几块原本各自为战的技术拼在一起，让普通用户不用自己去折腾编译参数和依赖关系。这几块技术分别是：

• Wine：负责把 Windows 的 API 调用翻译成 POSIX 系统调用，解决"软件以为自己在 Windows 上"的问题；
• FEX-Emu：负责把 x86-64 指令翻译成 ARM64 指令，解决"CPU 看不懂这些机器码"的问题；
• DXMT：负责把 Direct3D 调用翻译成 Metal，解决"图形 API 对不上"的问题。

这三者缺一不可。Wine 再强，遇到 x86-64 的二进制它也没法直接执行；FEX-Emu 能翻译指令，但如果没有 Wine 提供 Windows 运行时环境，程序连启动都启动不了；而 DXMT 则是让游戏画面能真正显示出来的最后一环。

我之所以对这个方向感兴趣，是因为过去半年我一直在折腾 ARM 设备上跑 Windows 游戏这件事。踩过的坑包括但不限于：Wine 中文全是乱码、Gecko 组件下载失败导致安装程序卡死、DXMT 版本和 Wine 版本对不上导致黑屏。这些问题在官方文档里往往一笔带过，但在实际操作中每一个都能让你卡上大半天。下面我把这些经验系统地整理出来，希望能帮到同样在这条路上摸索的人。

提示：本文讨论的是在合法拥有软件授权的前提下，于非 Windows 平台上运行自己已有的 Windows 程序，属于个人技术研究范畴。请确保你的使用场景符合相关软件的许可协议。

2. Wine 在 ARM 上的真实工作链路：不只是"装个兼容层"那么简单

2.1 Wine 到底翻译了什么，没翻译什么

很多人对 Wine 有个误解，以为它是个"模拟器"。其实 Wine 的全称是 "Wine Is Not an Emulator"，它做的是API 层面的翻译，不是指令层面的模拟。具体来说，当一个 Windows 程序调用CreateFileW这个 API 时，Wine 会拦截这个调用，然后转成 Linux 或 macOS 上的open()系统调用。程序本身还是以原生指令在 CPU 上跑的。

这就带来一个关键结论：Wine 本身不解决 CPU 架构不匹配的问题。在 x86-64 的 Linux 上，Wine 可以直接跑 x86-64 的 Windows 程序，因为指令集是一样的。但在 ARM64 设备上，Windows 程序是 x86-64 机器码，CPU 根本执行不了，这时候就必须有 FEX-Emu 这样的指令翻译层介入。

所以完整的链路是这样的：

Windows 程序 (x86-64 机器码) ↓ 由 FEX-Emu 翻译指令 ARM64 机器码 ↓ 调用 Windows API Wine 拦截并翻译成 POSIX 调用 ↓ 图形调用 DXMT 把 D3D 翻译成 Metal ↓ 屏幕显示

理解这个链路非常重要，因为它决定了你排查问题的方向。比如程序启动就崩溃，可能是 FEX-Emu 的指令翻译出了问题；程序能启动但界面乱码，那是 Wine 的字体和区域设置问题；程序能跑但画面黑屏，那大概率是 DXMT 或图形驱动的问题。不同环节的症状完全不同，盲目换版本只会浪费时间。

2.2 FEX-Emu 的配置要点：为什么你的程序跑得比别人慢

FEX-Emu 的默认配置是偏向兼容性的，性能上会保守一些。我在实际使用中发现几个能明显提升体验的调整点：

第一是TSO（Total Store Ordering）模式。x86 架构的内存模型比 ARM 强，为了保证多线程程序的正确性，FEX-Emu 默认会开启 TSO 模拟，这会带来性能损耗。如果你的程序是单线程的或者对内存顺序不敏感，可以尝试关闭 TSO 来换取性能。但要注意，关闭 TSO 可能导致某些多线程程序出现难以复现的崩溃，所以游戏类应用建议保持默认。

第二是JIT 缓存。FEX-Emu 会把翻译过的代码缓存起来，第二次运行同一个程序时会快很多。缓存目录默认在~/.cache/fex-emu/下，如果你发现某个程序第一次跑特别慢、后面就正常了，这是正常现象。但如果缓存目录所在的分区空间不足，缓存写入失败，程序就会一直很慢。我建议把这个目录放在 SSD 上，并且预留至少几个 GB 的空间。

第三是多线程编译。FEX-Emu 在首次翻译大程序时会占用大量 CPU，如果你在同时跑其他任务，会感觉整个系统卡顿。可以在配置里限制它使用的核心数，牺牲一点启动速度换取系统响应性。

2.3 Wine 前缀（Prefix）的管理：别把所有程序塞进一个瓶子

Wine 的 prefix 机制是很多人忽略的重点。默认情况下，所有程序都装在~/.wine这一个前缀里，时间长了会互相污染——某个程序装的运行库可能和另一个程序冲突，注册表也会越来越乱。

我的做法是按用途分前缀：游戏一个、办公软件一个、开发工具一个。创建新前缀的命令很简单：

WINEPREFIX=~/.wine-games winecfg

这条命令会创建一个新的前缀并打开配置界面。之后运行程序时都要带上WINEPREFIX环境变量，或者写个脚本封装起来。

分前缀的好处是隔离性好，某个前缀玩坏了直接删掉重建，不影响其他程序。代价是每个前缀都要单独装运行库，磁盘占用会翻倍。对于 SSD 空间紧张的用户，可以只给游戏分独立前缀，其他程序共用一个。

注意：删除前缀前一定要确认里面没有你需要的数据。有些程序的存档和配置就存在 prefix 里，删了就找不回来了。

3. 中文乱码、Gecko 缺失、DXMT 黑屏：三个高频坑的完整排查链路

3.1 Wine 中文乱码：从字体缺失到区域设置的逐层定位

Wine 中文乱码是我遇到最多的求助问题，症状通常是：程序界面能显示，但所有中文都变成了方块或者问号。这个问题的根因有好几层，需要逐层排查。

第一层：系统字体缺失。Wine 本身不带中文字体，它会去调用系统字体。如果你的系统没装中文字体，Wine 自然找不到。解决办法是安装一套完整的中文字体，比如思源黑体或者文泉驿。装完之后，Wine 需要重新扫描字体缓存，可以删除~/.cache/wine/下的字体缓存文件让它重建。

第二层：Wine 的字体替换规则。即使系统有中文字体，Wine 也未必知道该用哪个字体来替换 Windows 的宋体、黑体。这需要在注册表里配置字体替换。具体路径是HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\FontSubstitutes，把SimSun、SimHei这些映射到系统里实际存在的中文字体。

第三层：区域设置（Locale）。如果 Wine 的 locale 是en_US.UTF-8，某些程序会认为当前环境不支持中文，从而不加载中文字体。把 locale 设成zh_CN.UTF-8往往能解决一部分问题。但要注意，locale 设置会影响程序的日期、货币格式，有些游戏会因为区域不对而出现奇怪的显示，需要权衡。

第四层：程序自带的字体。有些程序会把字体打包在自己的目录里，这种情况下乱码可能是字体文件本身损坏或者版本不兼容。可以尝试用winetricks安装corefonts和cjkfonts来补齐。

排查顺序建议从第一层开始，逐层往上。我见过太多人一上来就改注册表，结果发现只是系统没装中文字体，白白折腾半天。

3.2 Gecko 和 Mono 组件下载失败：离线安装的正确姿势

Wine 在首次运行某些程序时会提示安装 Gecko（用于 HTML 渲染）和 Mono（用于 .NET 支持）。这两个组件体积不小，而且下载源在国外，网络不好的时候经常卡住或者失败。

失败的表现是：程序启动时弹出一个对话框，说 Gecko 安装失败，然后程序要么卡死要么直接退出。更麻烦的是，有些程序不会明确告诉你缺了 Gecko，只是默默地不显示某些界面。

解决办法是提前离线安装。Gecko 和 Mono 的安装包可以从 Wine 的官方发布渠道获取，下载对应版本的.msi文件后，用下面的命令安装：

WINEPREFIX=~/.wine wine msiexec /i wine-gecko-xxx.msi WINEPREFIX=~/.wine wine msiexec /i wine-mono-xxx.msi

版本号必须和你的 Wine 版本匹配，否则装了也没用。可以在 Wine 的安装目录下找到它期望的版本号，通常在share/wine/wine.inf文件里能看到。

提示：如果你用的是发行版打包的 Wine，Gecko 和 Mono 可能已经被打包成独立的系统包，直接通过包管理器安装即可，不需要手动下载 msi。

3.3 DXMT 黑屏与花屏：版本匹配和图形后端选择

DXMT 是把 Direct3D 翻译成 Metal 的组件，主要用在 macOS 上。它的黑屏问题通常有三个原因：

原因一：DXMT 版本和 Wine 版本不匹配。DXMT 是作为 Wine 的一个模块加载的，接口必须对得上。如果你用的是自己编译的 Wine，DXMT 也要用对应版本编译。用发行版 Wine 的话，要确认 DXMT 的发布说明里写明了支持的 Wine 版本范围。

原因二：图形后端选择错误。DXMT 支持多种 Metal 后端配置，有些游戏在默认配置下会黑屏，但切换到另一个后端就正常了。这个需要在 DXMT 的配置文件里调整，具体参数因版本而异，建议查阅对应版本的文档。

原因三：游戏本身用了 DXMT 不支持的 D3D 特性。DXMT 对 D3D 的覆盖不是 100% 的，某些高级特性（比如特定的着色器模型或者纹理格式）可能还没实现。这种情况下只能等 DXMT 更新，或者换用其他翻译方案。

排查黑屏问题时，建议先开 Wine 的调试输出，看看有没有 DXMT 相关的报错。命令大概是：

WINEPREFIX=~/.wine WINEDEBUG=+dxmt wine your_game.exe

日志里如果出现 "unsupported" 或者 "failed to create" 之类的字样，基本就能定位到问题所在。

4. 从 Wine 到 iOS：跨平台兼容思路的延伸与边界

4.1 为什么 iOS 上的"兼容"是另一套逻辑

热词里出现了不少 iOS 相关的内容，比如 iOS 开发者模式、Xcode 打包、iOS 原生插件、WebView 自动播放等。这些和 Wine 看似不相关，但背后的思路有相通之处：都是在受限环境里想办法让程序跑起来。

不过 iOS 的情况和桌面 Linux/macOS 完全不同。iOS 是封闭系统，不允许用户自行安装未经签名的可执行文件，也不允许应用动态加载外部代码。这意味着 Wine 那套"拦截 API 调用"的思路在 iOS 上基本行不通——你没法在系统层面做翻译，只能在应用内部做文章。

所以 iOS 上所谓的"兼容"，通常是指这几种情况：

• WebView 里跑 Web 应用：这是最常见的，用 WKWebView 加载网页，本质上还是 Web 技术栈；
• 应用内嵌模拟器：比如某些复古游戏模拟器，它们把模拟器核心打包进 App，在应用内部运行；
• 远程串流：把计算放在远端，iOS 设备只负责显示和输入。

这几种方案各有各的限制。WebView 方案受限于浏览器的能力，比如热词里提到的"抖音 iOS WebView 不能自动播放"，就是 WebView 的自动播放策略导致的，需要用户交互才能触发播放。模拟器方案则受限于 App Store 的审核政策，很多类型的模拟器是不允许上架的。

4.2 iOS 开发者模式与真机调试的实际门槛

热词里"iOS 开发者模式"和"iOS 26.3.1 怎么开发者模式"出现频率很高，说明很多人在真机调试这一步卡住了。这里简单说一下流程，避免大家走弯路。

从 iOS 16 开始，苹果把开发者模式做成了一个需要手动开启的开关，位置在"设置 - 隐私与安全性 - 开发者模式"。但这个开关默认是隐藏的，只有当你把设备连接到 Xcode 或者安装了带有开发者签名的应用之后，它才会出现。

开启开发者模式后，设备会重启，重启后需要再次确认。这个设计是为了防止普通用户误装恶意应用，但对开发者来说确实多了一步。

真机调试还需要处理证书和描述文件的问题。免费账号可以申请个人开发证书，但签名的应用只有 7 天有效期，过期后需要重新签名。付费开发者账号（每年 99 美元）可以申请有效期一年的证书，并且可以上架 App Store。

热词里提到的"xcode 从证书配置到上架全流程"和"xcode 打包 iOS 突然很慢如何解决"，都是这个环节的典型问题。打包慢通常是因为 Xcode 在重新编译所有依赖，可以尝试清理 DerivedData 目录，或者检查是不是开了过多的编译优化选项。

4.3 跨平台项目的通用经验：隔离、版本锁定、日志先行

不管是 Wine 还是 iOS 开发，我在跨平台项目里总结出三条通用经验，这里分享出来：

第一，环境隔离。Wine 用 prefix 隔离，iOS 用虚拟环境或者容器隔离，Python 用 venv 隔离。隔离的核心目的是让不同项目的依赖互不干扰，出问题时可以快速回滚。

第二，版本锁定。Wine 和 DXMT 的版本必须匹配，Xcode 和 iOS SDK 的版本必须匹配，任何跨平台工具链都有版本兼容性矩阵。我习惯把每个项目的工具链版本记录在一个文档里，升级时对照着来，避免"升了一个组件结果全崩了"。

第三，日志先行。跨平台问题的排查难度远高于单平台，因为中间隔了好几层翻译。所以一定要养成开日志的习惯，Wine 用WINEDEBUG，iOS 用 Xcode 的控制台，把日志级别调到能看到警告和错误。很多问题在日志里其实写得很清楚，只是默认不显示。

5. 实操复盘：一次完整的 ARM 设备跑 Windows 游戏配置记录

5.1 环境准备与组件版本选择

下面记录一次我在 ARM64 Linux 设备上配置 Windows 游戏的完整过程，供参考。设备是某款 ARM 笔记本，系统是 Ubuntu 24.04 ARM64 版。

组件版本选择如下：

安装顺序很重要：先装 FEX-Emu，再装 Wine，最后配置 DXMT。因为 Wine 在编译时会检测 FEX-Emu 的存在，顺序反了可能导致 Wine 没有启用 x86-64 翻译支持。

5.2 逐步配置与验证

第一步，安装 FEX-Emu 并验证：

fex-emu --version

确认版本号正常输出。然后创建一个测试用的 x86-64 程序，用 FEX-Emu 跑一下，确认指令翻译正常工作。

第二步，安装 Wine 并创建独立前缀：

WINEPREFIX=~/.wine-game winecfg

在配置界面里，把 Windows 版本设成 Windows 10，把图形驱动设成 DXMT 对应的选项。这一步如果 DXMT 没装好，图形驱动选项里不会出现相关条目。

第三步，安装中文字体和运行库：

winetricks corefonts cjkfonts vcrun2019 dotnet48

vcrun2019和dotnet48是很多游戏和工具的必备运行库，提前装上能省去后面反复弹窗的麻烦。

第四步，安装 Gecko 和 Mono（如果 Wine 没有自动装）：

WINEPREFIX=~/.wine-game wine msiexec /i /path/to/wine-gecko.msi WINEPREFIX=~/.wine-game wine msiexec /i /path/to/wine-mono.msi

第五步，运行游戏并观察日志：

WINEPREFIX=~/.wine-game WINEDEBUG=+dxmt,+d3d wine game.exe 2>&1 | tee game.log

第一次运行会比较慢，因为 FEX-Emu 在翻译指令。等 JIT 缓存建立起来之后，第二次运行会快很多。

5.3 实测中遇到的意外与处理

实测过程中遇到了几个预料之外的问题，记录如下：

问题一：游戏启动后没有声音。排查发现是 Wine 的音频后端默认用了 PulseAudio，但系统实际用的是 PipeWire。在 winecfg 里把音频驱动改成 PipeWire 对应的选项后解决。

问题二：手柄识别不了。游戏能识别键盘但识别不了手柄。这是因为 Wine 需要额外的驱动来映射 Linux 的输入设备。装了winetricks xinput之后，手柄正常识别。

问题三：帧率不稳定，偶尔卡顿。观察发现是 FEX-Emu 的 JIT 缓存在写入时占用了磁盘 IO。把缓存目录移到内存盘（tmpfs）后，卡顿明显减少。但要注意，内存盘重启后数据会丢失，每次重启都要重新建立缓存。

问题四：游戏内中文显示为方块。按照前面 3.1 节的排查链路，最终定位到是游戏自带的字体文件在 ARM 上渲染有问题。用 winetricks 强制替换字体后解决。

这些问题在官方文档里基本找不到，都是靠开日志、逐层排查、反复试错才解决的。我把它们记录下来，就是希望后来者能少走一些弯路。

6. 关于跨平台兼容，我个人的几点体会

折腾了这么久，我最大的感受是：跨平台兼容没有银弹，只有权衡。Wine + FEX-Emu + DXMT 这套组合能解决大部分问题，但它不是万能的。有些程序就是跑不起来，有些能跑但性能损失很大，有些今天能跑明天更新一下就崩了。

所以我的建议是：先确认你的核心需求是什么。如果只是偶尔用某个 Windows 软件，可能远程桌面或者虚拟机是更省心的选择。如果是要长期跑游戏，那就要做好持续维护的心理准备，因为工具链更新频繁，每次更新都可能带来新的问题。

另外，社区的力量很重要。Wine、FEX-Emu、DXMT 都是开源项目，遇到问题去对应的 issue 区搜一搜，往往能找到别人已经踩过的坑。我上面记录的很多解决方案，其实都是从社区讨论里学来的，只是整理成了更系统的形式。

最后分享一个小技巧：给每个游戏单独建一个启动脚本，把 WINEPREFIX、WINEDEBUG、FEX-Emu 的配置都写进去。这样启动游戏时不用记一堆环境变量，也方便针对不同游戏做不同的优化配置。脚本大概长这样：

#!/bin/bash export WINEPREFIX=~/.wine-game-xxx export WINEDEBUG=-all export FEX_TSOENABLED=1 cd "$WINEPREFIX/drive_c/Program Files/Game" wine game.exe "$@"

把WINEDEBUG设成-all可以关闭调试输出，减少性能开销。需要排查问题时再临时改成+dxmt,+d3d之类的。这个脚本放在桌面或者 PATH 里，用起来就很顺手了。