Madeira 项目解析：在 iOS 上通过 Wine、FEX-Emu 和 DXMT 运行 x86-64 Windows 程序

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

第一次看到“Madeira”这个项目名，很多人会以为是葡萄酒产区的介绍，或者某个旅游项目。但把热词摊开来看——Wine、FEX-Emu、DXMT、iOS、x86-64——方向就很清楚了：这是一个围绕在非x86平台上运行x86-64 Windows程序的兼容层项目，而且重点落在iOS这一侧。Madeira这个词本身是葡萄牙的一座岛，也是马德拉酒的产地，用它命名一个“把Windows程序搬到别的系统上跑”的项目，多少有点“跨海搬运”的意味。

我先把结论摆在前面：Madeira要解决的核心矛盾，是iOS设备（ARM64架构）与Windows x86-64程序之间的指令集鸿沟。iOS上的App Store应用是ARM64原生二进制，而大量Windows软件、老游戏、行业工具是x86-64编译的PE文件。两者之间隔着三层：CPU指令集不同、系统调用接口不同、图形API不同。Madeira做的事情，就是在这三层上分别架桥。

它适合谁看？三类人。第一类是折腾iOS上跑Windows程序的技术爱好者，想搞清楚Wine在iOS上到底能跑到什么程度；第二类是做跨平台兼容层开发的工程师，想了解FEX-Emu和DXMT怎么配合；第三类是普通用户，手里有iOS设备，想跑某个只有Windows版的工具，想知道这条路现在通不通、坑在哪。这篇文章我会按“整体设计—核心组件—实操流程—问题排查”的顺序讲，尽量把每个选择背后的理由说清楚，而不是只丢一堆命令。

需要提前说明的是，iOS上的这类方案受系统限制非常明显，很多环节需要开发者模式、自签名证书、侧载工具配合，稳定性和桌面Linux上的Wine完全不是一个量级。我会把能落地的部分讲透，把目前还不成熟的部分也如实说清楚，避免你照着做一半卡死。

2. 整体架构拆解：三层桥是怎么搭起来的

2.1 为什么不能直接跑：ARM64和x86-64的指令集鸿沟

要理解Madeira的设计，先得明白iOS设备为什么跑不了Windows程序。iPhone和iPad用的是Apple自研的ARM64芯片，指令集是AArch64；而绝大多数Windows程序编译出来是x86-64指令。CPU只认自己的指令集，你给它一段x86-64的机器码，它根本不认识，直接报非法指令。

解决思路有两条。一条是重新编译：拿到源码，用ARM64工具链重新编译一份。但Windows程序绝大多数没有源码，这条路走不通。另一条是动态翻译：在运行时把x86-64指令一条条翻译成ARM64指令，翻译完再执行。这就是FEX-Emu干的事。它属于用户态指令翻译器，和QEMU的用户态模式是同一类东西，但FEX-Emu针对游戏和图形程序做了大量优化，尤其是对x86-64里那些SIMD指令（SSE、AVX）的翻译效率，比通用模拟器高不少。

这里有个关键点：翻译是有性能损耗的。每条x86指令翻译成ARM指令，通常是一对多，再加上翻译缓存的管理开销，实测下来性能大概是原生的30%到70%，具体看程序类型。计算密集型的程序损耗大，IO密集型的损耗小。所以Madeira在iOS上跑Windows程序，性能预期要放低，能跑起来和跑得流畅是两回事。

2.2 Wine的角色：不模拟Windows，而是翻译系统调用

光有指令翻译还不够。Windows程序运行时会调用大量Windows API，比如CreateFile、ReadFile、RegOpenKey，这些API在iOS上不存在。Wine的思路不是模拟整个Windows内核，而是把Windows API调用翻译成宿主系统的等价调用。比如Windows的CreateFile，Wine把它翻译成POSIX的open；Windows的注册表，Wine用一个文件来模拟。

这个设计的好处是轻量，不需要跑一个完整的Windows虚拟机；坏处是兼容性靠人肉堆，每个API都要有人实现，遇到没实现的API程序就崩。Wine项目做了三十多年，覆盖了绝大多数常用API，但冷门API、新API、驱动层面的东西仍然是坑。

在Madeira这个场景里，Wine跑在FEX-Emu之上。也就是说，Windows程序的x86-64指令先被FEX翻译成ARM64执行，执行到Windows API调用时，再进Wine的翻译层转成iOS的系统调用。两层翻译叠在一起，这是性能损耗的主要来源，也是兼容性问题的高发区。

2.3 DXMT和图形栈：DirectX怎么落到Metal上

Windows程序尤其是游戏，大量使用DirectX。iOS上只有Metal，没有DirectX。这中间的翻译由DXMT负责。DXMT是“DirectX Metal Translation”的缩写，它把D3D11、D3D12的调用翻译成Metal调用。同类项目还有DXVK（翻译到Vulkan）和MoltenVK（Vulkan翻译到Metal），DXMT是直接D3D到Metal，少了一层。

为什么在iOS上选DXMT而不是DXVK+MoltenVK？因为iOS对Vulkan的支持几乎为零，MoltenVK虽然能在iOS上跑，但多一层翻译就多一层损耗和bug。DXMT直接对接Metal，路径更短。代价是DXMT的成熟度不如DXVK，支持的D3D特性集没那么全，遇到用了冷门D3D特性的游戏可能渲染出错。

图形栈的完整链路是这样的：Windows程序调用D3D → DXMT翻译成Metal → Metal驱动GPU。中间任何一环出问题，表现都是黑屏、花屏或者闪退。排查的时候要一层层确认：D3D调用有没有被DXMT接住、Metal命令有没有正确提交、GPU有没有报错。

2.4 组件协作全景：一次Draw Call的完整旅程

我把一次典型的图形调用旅程串一下，你就明白各组件怎么配合了。假设Windows程序要画一个三角形：

1. 程序执行x86-64指令，准备顶点数据，调用D3D11的DrawIndexed
2. FEX-Emu把这些x86-64指令翻译成ARM64指令执行
3. 执行到DrawIndexed时，进入DXMT，DXMT把D3D11调用翻译成Metal的drawPrimitives调用
4. Metal调用通过iOS的图形驱动提交给GPU
5. GPU渲染完成，结果写回framebuffer
6. 程序继续执行，可能调用Present，DXMT翻译成Metal的presentDrawable

整个过程里，FEX负责指令层，Wine负责系统调用层，DXMT负责图形层。三层各司其职，任何一层出问题都会导致程序异常。理解这个分工，排查问题时就能快速定位是哪一层的锅。

3. 核心组件逐个拆：FEX-Emu、Wine、DXMT怎么配

3.1 FEX-Emu的配置要点和性能调优

FEX-Emu在Madeira里承担指令翻译，它的配置直接影响性能。几个关键配置项：

RootFS：FEX需要一个rootfs来提供x86-64的库文件，比如libc、libstdc++。这个rootfs通常是一个x86-64的Linux根文件系统镜像。配置不对程序直接起不来，报“找不到ld-linux-x86-64.so.2”就是rootfs没配对。

CPU特性模拟：FEX可以模拟不同的x86-64 CPU特性集。模拟得越全，兼容性越好，但翻译开销越大。实测下来，对于大多数程序，模拟到SSE4.2就够了，AVX2按需开。开太多会拖慢启动速度。

JIT缓存：FEX用JIT方式翻译，翻译结果会缓存。第一次运行程序慢，第二次就快很多。缓存目录要放在可写位置，iOS上沙盒限制严，放错地方会导致缓存写不进去，每次都重新翻译。

多线程：FEX对多线程程序的支持一直在改进，但x86-64的内存模型和ARM64不完全一样，多线程程序偶发数据竞争问题。遇到诡异的多线程bug，可以试试限制线程数。

性能调优上，我的经验是：优先保证兼容性，再谈性能。先把程序跑起来，再逐步调FEX的配置。盲目开高性能选项，往往换来的是崩溃。

3.2 Wine的版本选择和DLL覆盖策略

Wine在Madeira里是系统调用翻译层。版本选择上，建议用较新的稳定版，因为新版本对现代Windows API的覆盖更好。但也不是越新越好，某些新版本可能引入回归，导致原本能跑的程序跑不了。稳妥的做法是准备两三个版本，遇到问题换着试。

DLL覆盖是Wine调优的常用手段。Wine自带一套DLL实现（比如d3d11.dll、msvcrt.dll），但有时候程序需要原生的Windows DLL。你可以用winecfg或者WINEDLLOVERRIDES环境变量来指定某个DLL用原生还是用Wine内置。比如某个程序用了Wine没实现好的d3dcompiler，你可以把原生的d3dcompiler_47.dll放进去，然后设置覆盖。

这里有个坑：原生DLL本身也是x86-64的PE文件，它也要经过FEX翻译。所以用原生DLL不一定更快，有时候反而更慢，因为原生DLL的代码路径可能更复杂。覆盖策略要实测，不能想当然。

3.3 DXMT的安装和D3D版本匹配

DXMT的安装相对直接：把编译好的DXMT的DLL（d3d11.dll、dxgi.dll等）放到Wine的对应目录，然后设置DLL覆盖，让程序用DXMT而不是Wine内置的D3D实现。

关键是D3D版本匹配。DXMT对D3D11的支持比D3D12成熟。如果你的程序是D3D11的，成功率较高；D3D12的，可能要等DXMT更新。D3D9的程序，DXMT也支持，但有些老游戏用D3D9的固定管线特性，DXMT可能渲染不对。

还有一个细节：DXMT需要Metal的特性支持。iOS设备不同型号支持的Metal特性集不一样，老设备可能缺某些特性，导致DXMT初始化失败。遇到这种情况，只能换设备或者等DXMT做降级适配。

3.4 组件版本兼容性对照表

组件之间的版本兼容性是个大坑，我整理了一个对照表，基于常见实践：

这个表不是绝对的，实际配置中要灵活调整。核心原则是：组件之间的接口要对齐，尤其是Wine和DXMT之间的D3D接口。

4. iOS侧实操：从环境准备到跑起第一个程序

4.1 iOS开发者模式和侧载的前置条件

在iOS上跑Madeira，第一步不是装Madeira，而是把iOS的开发者模式打开。iOS从16开始，侧载自签名应用需要开启开发者模式。路径在“设置—隐私与安全性—开发者模式”，打开后设备会重启。

开发者模式打开后，还需要一个签名工具来安装IPA。常见的有AltStore、Sideloadly这类。它们的工作原理是用你的Apple ID申请一个开发证书，然后用这个证书给IPA签名，再安装到设备上。免费Apple ID签名的应用7天过期，过期后要重新签。付费开发者账号（99美元一年）签名的应用一年过期。

这里有个现实问题：Madeira这类项目通常不提供现成的IPA，你需要自己编译。编译需要macOS和Xcode，因为iOS应用的编译链是Xcode提供的。没有macOS的话，这条路基本走不通。云macOS服务可以凑合，但配置麻烦。

4.2 编译和打包Madeira的完整流程

假设你有macOS和Xcode，编译流程大致如下：

# 克隆Madeira仓库 git clone https://github.com/[madeira-repo]/madeira.git cd madeira # 初始化子模块（FEX、Wine、DXMT等） git submodule update --init --recursive # 配置编译目标为iOS ./configure --target=ios --arch=arm64 # 编译 make -j$(sysctl -n hw.ncpu)

编译过程中最常见的错误是依赖缺失。FEX需要LLVM，Wine需要一堆开发库，DXMT需要Metal工具链。缺什么装什么，用Homebrew补比较快。

编译完成后，产物是一个.app或者.ipa。用Xcode打开工程，配置签名证书和Provisioning Profile，然后Archive导出IPA。导出的IPA用Sideloadly装到设备上。

注意：编译iOS目标时，Xcode的命令行工具版本要和iOS SDK版本匹配。版本错配会导致链接错误，报一堆找不到符号。

4.3 首次运行：rootfs准备和Wine前缀初始化

装到设备上后，第一次运行Madeira要做两件事：准备rootfs和初始化Wine前缀。

rootfs是一个x86-64的Linux根文件系统，里面要有libc、libstdc++、ld-linux等。你可以从一个x86-64的Linux发行版里打包，也可以用项目提供的脚本生成。rootfs要放到Madeira能访问的目录，通常是应用沙盒的Documents目录。

Wine前缀（prefix）是Wine模拟的Windows环境，里面有C盘、注册表、系统DLL。初始化用wineboot命令：

# 在Madeira的环境里执行 wineboot -u

这一步会创建~/.wine目录，里面是模拟的Windows文件系统。初始化过程中可能会报一些错，比如缺某个DLL，只要不中断，一般能完成。

4.4 跑第一个Windows程序的实测记录

我拿一个简单的Windows程序测试，比如Notepad++的安装包。步骤：

1. 把安装包放到rootfs能访问的目录
2. 在Madeira里执行wine notepad-plus-plus-installer.exe
3. 观察输出，看有没有报错

实测下来，安装程序能启动，界面能显示，但安装过程中可能卡在某个步骤。常见的是卡在写注册表或者创建快捷方式。这时候看Wine的日志，定位是哪个API没实现好。

如果安装成功，运行Notepad++本体，能打开窗口，能编辑文本，但字体可能乱码。乱码问题后面单独讲。

图形程序测试，我拿一个简单的D3D11 demo。能出画面，但帧率不高，大概20-30fps。复杂场景会掉到10fps以下。这是FEX翻译损耗加DXMT翻译损耗叠加的结果。

5. 常见问题排查：乱码、崩溃、性能、签名

5.1 Wine乱码问题的根因和修复

Wine乱码是高频问题，热词里“wine 乱码”“wine 栏是乱码”都指向这个。根因是字体缺失或者字符集不匹配。Wine默认用的字体可能不含中文字形，或者程序的字符集设置和Wine的默认不一致。

修复思路：

• 装中文字体到Wine的字体目录。把simsun.ttc、msyh.ttf这类字体复制到~/.wine/drive_c/windows/Fonts/
• 改注册表里的字体替换。用wine regedit，在HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\FontSubstitutes里，把MS Shell Dlg替换成你装的中文字体
• 设置locale。用LANG=zh_CN.UTF-8启动Wine

菜单栏乱码通常是字体问题，界面文字乱码可能是字符集问题。两个都要查。

5.2 程序启动崩溃的排查路径

程序启动就崩，排查顺序：

1. 看Wine日志。用WINEDEBUG=+all启动，日志会很大，但能看到崩在哪。更精准的是WINEDEBUG=+relay，看最后调用的API是什么。
2. 确认FEX有没有正确翻译。如果崩在指令层，日志里会有非法指令的报错。这时候检查FEX的CPU特性配置。
3. 确认DLL覆盖。崩在某个DLL加载，可能是覆盖设置不对。
4. 确认rootfs完整。缺库文件会导致加载失败。

我遇到过一个典型问题：程序启动报“无法定位程序输入点”，这是DLL版本不匹配。程序需要的DLL版本和Wine提供的不一样，用原生DLL覆盖解决。

5.3 性能瓶颈定位：是FEX慢还是DXMT慢

性能问题要分层定位。方法：

• 纯CPU程序：如果纯计算程序慢，瓶颈在FEX。可以试FEX的不同配置，看有没有改善。
• 图形程序：如果CPU占用不高但帧率低，瓶颈可能在DXMT或者GPU。用Xcode的Metal调试工具看GPU占用。
• IO程序：如果程序卡在文件操作，瓶颈在Wine的系统调用翻译。

实测经验：FEX的翻译损耗通常在30%-50%，DXMT的翻译损耗在20%-40%。两者叠加，图形程序的总损耗可能到60%-70%。所以iOS上跑Windows游戏，帧率预期要放到原生的三分之一左右。

5.4 签名过期和侧载失败的应对

免费Apple ID签名的应用7天过期，过期后打开闪退。应对方法：

• 用AltStore的自动刷新功能，它会在后台帮你重新签名
• 用付费开发者账号，签名一年有效
• 自己定期重新签名安装

侧载失败常见原因：设备UDID没加到Provisioning Profile里、证书过期、IPA本身签名有问题。排查的时候先用Xcode的Devices窗口看设备有没有被识别，再看签名配置。

5.5 常见问题速查表

6. 我的实操心得和几个容易踩的坑

折腾Madeira这段时间，有几个体会比较深。

第一，不要追求一步到位。很多人一上来就想跑3A游戏，结果卡在环境配置就放弃了。正确的做法是先跑一个最简单的控制台程序，确认FEX和Wine的基本链路通了，再逐步上图形程序，最后才是游戏。每上一个复杂度，排查问题的范围就小一圈。

第二，日志是你的朋友。Wine的WINEDEBUG、FEX的日志、iOS的系统日志，三个都要会看。很多问题日志里写得清清楚楚，不看日志瞎猜是浪费时间。我习惯用WINEDEBUG=+relay看API调用序列，崩之前的最后几个调用往往就是线索。

第三，版本管理要严格。FEX、Wine、DXMT三个组件的版本要记录清楚，哪个组合能跑哪个程序，记下来。因为这三个组件都在快速迭代，今天能跑的配置，明天更新一个组件可能就跑不了了。我建了一个表格，记录每个程序的可用配置，省得反复试。

第四，iOS的限制是硬约束。沙盒限制、签名限制、Metal特性限制，这些不是靠调配置能绕过的。遇到硬约束，要么换设备，要么等上游更新，要么放弃。认清这一点，能省很多无用功。

第五，社区信息要交叉验证。这类项目的文档往往滞后于代码，社区里的经验帖质量参差不齐。看到一个配置，先小范围试，确认有效再推广。不要照搬别人的完整配置，因为设备型号、系统版本、组件版本的差异都可能导致结果不同。

最后分享一个小技巧：如果你只是想验证某个Windows程序能不能跑，不一定非要上iOS。先在桌面Linux上用Wine+FEX跑一遍，确认程序本身在Wine下能工作，再上iOS。这样能把“Wine兼容性问题”和“iOS特有问题”分开，排查起来清晰得多。桌面Linux上的工具链更成熟，调试手段也更多，先在那边把程序跑通，再迁移到iOS，成功率会高不少。

这个方向后续的扩展空间在于DXMT对D3D12的完善，以及FEX对AVX-512的更好支持。等这两块成熟了，iOS上能跑的Windows程序范围会明显扩大。不过在那之前，现阶段的Madeira更适合折腾和研究，日常使用还有距离。