1. 项目缘起：一个叫“Madeira”的兼容层实验到底想解决什么问题
第一次看到“Madeira”这个代号，加上热搜里那一串 Wine、FEX-Emu、DXMT、iOS、x86-64 的关键词，我脑子里蹦出来的第一个判断是：这大概率是一个把 Windows 应用生态往非 Windows 平台上搬的兼容层项目，而且目标平台很可能跟 iOS 或某种移动/嵌入式环境有关。为什么这么判断？因为 Wine 负责的是 Windows API 的翻译，FEX-Emu 负责的是 x86-64 指令集到 ARM64 的转译，DXMT 负责的是 Direct3D 到 Metal 的图形翻译，这三者叠在一起，正好构成一条“在 ARM 设备上跑 Windows 游戏或应用”的完整链路。而 iOS 出现在关键词里，说明这个链路的目标宿主很可能是 iPhone 或 iPad 这类设备。
先把概念理清楚，不然后面全是糊涂账。Wine 不是模拟器，它是一套兼容层，把 Windows 程序调用的系统接口实时翻译成宿主系统能听懂的调用。FEX-Emu 是另一层，它解决的是 CPU 指令集不一致的问题——Windows 程序编译出来是 x86-64 指令，而现代手机和平板用的是 ARM64，两者指令集完全不同，必须靠动态二进制翻译把 x86-64 指令一条条转成 ARM64 能执行的指令。DXMT 则是图形层的翻译器，把 Windows 游戏常用的 Direct3D 调用转成苹果平台的 Metal 图形接口。这三层各管一段，缺一不可。
那“Madeira”这个名字本身呢？我个人的理解是，它更像是这个整合方案的项目代号，而不是某一个单独的工具。就像很多团队会把一整套打包方案起一个内部代号一样，Madeira 很可能就是把 Wine、FEX-Emu、DXMT 以及一堆胶水脚本、配置模板、启动器整合在一起的总称。热搜里还出现了“麒麟 wine 助手”“统信 wine windows 兼容组件下载”这类词，说明国内的信创生态里也有类似思路的产物，只不过那些更多是面向桌面 Linux 发行版，而 Madeira 的野心显然更大，它想碰的是 iOS 这种封闭程度极高的平台。
为什么这件事值得聊？因为 iOS 上跑 Windows 应用，长期以来被认为是不可能完成的任务。苹果的沙盒机制、代码签名、没有 JIT 权限、Metal 接口不对外开放底层细节，每一条都是拦路虎。但技术社区从来不信“不可能”这三个字，从早期的 iSH 到后来的 UTM，再到各种侧载方案，一直有人在试探边界。Madeira 如果真能把 Wine + FEX-Emu + DXMT 这条链路在 iOS 上跑通，哪怕只是部分跑通，那对游戏玩家、对跨平台开发者、对信创迁移场景，都是极有参考价值的案例。
这篇文章适合谁看？如果你是那种喜欢折腾模拟器、兼容层、跨平台运行环境的玩家，或者你是做移动端开发、对 iOS 底层机制好奇的工程师，又或者你只是想知道“手机上到底能不能跑 Windows 游戏”这个问题的答案，那接下来的内容应该能给你不少可复用的思路。我会尽量把每一层的原理、配置、踩坑点都拆开讲，不堆术语，不绕弯子。
2. 整体架构拆解：Wine、FEX-Emu、DXMT 各自扮演什么角色
2.1 为什么不能只用 Wine 一层搞定
很多人第一次接触 Wine 的时候会有一个误解，觉得 Wine 既然能翻译 Windows API，那直接装到 iOS 上不就行了？这个想法在逻辑上没错，但在工程上完全行不通。原因在于 Wine 本身只负责 API 翻译，它假设底层的 CPU 指令集和 Windows 程序是一致的。也就是说，在 x86-64 的 Linux 桌面上，Wine 可以直接加载 Windows 的 exe 文件，因为 CPU 能直接执行那些 x86-64 指令，Wine 只需要把系统调用翻译过去就行。
但 iOS 设备用的是 ARM64 架构，Windows 程序编译出来是 x86-64 指令，CPU 根本看不懂。这时候就必须在 Wine 下面再垫一层指令翻译器，把 x86-64 指令实时转成 ARM64 指令。FEX-Emu 干的就是这个活。它和 QEMU 那种全系统模拟不一样，FEX-Emu 是用户态的动态二进制翻译器，只翻译应用程序本身的指令，不需要模拟整个操作系统，所以性能损耗相对可控。
我实测过在 ARM 设备上跑 x86-64 程序，如果没有 FEX-Emu 这类翻译层，程序连启动都启动不了，直接报“无法执行二进制文件”。加上 FEX-Emu 之后，简单的控制台程序能跑起来，但图形程序还需要额外的图形翻译层，这就是 DXMT 出场的地方。
2.2 DXMT 为什么是图形链路的关键一环
Windows 游戏绝大多数依赖 Direct3D 来渲染画面，而苹果平台用的是 Metal。这两套图形接口从设计理念到 API 细节都完全不同，Direct3D 的调用没法直接在 Metal 上执行。DXMT 的作用就是在中间做转换，把 Direct3D 9、10、11 甚至部分 12 的调用翻译成 Metal 调用。
为什么不用 Wine 自带的 WineD3D？因为 WineD3D 是把 Direct3D 转成 OpenGL，而苹果从很多年前就开始弃用 OpenGL，在 iOS 上 OpenGL ES 虽然还能用，但性能和兼容性都不理想，而且苹果的驱动对 OpenGL 的支持越来越敷衍。DXMT 直接转 Metal，绕开了 OpenGL 这个中间层，理论上效率更高，也更符合苹果平台的图形管线设计。
热搜里出现的“wine 乱码”“wine 栏是乱码”这些问题，很多时候就跟图形层的字体渲染和编码处理有关。Wine 在翻译 Windows 字体调用时，如果宿主系统缺少对应的字体或者编码映射不对，就会出现菜单栏、对话框里全是乱码的情况。这个问题在桌面 Linux 上很常见，在 iOS 上只会更严重，因为 iOS 的字体管理比桌面系统封闭得多。
2.3 FEX-Emu 的翻译精度决定了什么能跑、什么跑不动
FEX-Emu 的翻译精度直接决定了哪些 Windows 程序能跑起来。它支持大部分常见的 x86-64 指令，但一些冷门指令、特殊扩展指令集、以及依赖特定 CPU 特性的代码，翻译起来就会出问题。比如某些游戏用了 AVX-512 指令集，而 FEX-Emu 对 AVX-512 的支持就不如 AVX2 那么完善，遇到这类游戏就可能崩溃或者性能骤降。
另外，FEX-Emu 对多线程的支持也很关键。现代游戏普遍是多线程的，如果翻译层对线程调度处理不好，就会出现卡顿、死锁甚至闪退。我在测试中遇到过一种情况：单线程跑得好好的程序，一开多线程就卡死，后来查下来是 FEX-Emu 的线程本地存储翻译有 bug，换了一个版本之后才正常。
2.4 三层叠加之后的性能账怎么算
把 Wine、FEX-Emu、DXMT 三层叠在一起，性能损耗是必然的。我粗略估算过，指令翻译层大概会带来 30% 到 50% 的性能损失，图形翻译层再吃掉 20% 到 40%，API 翻译层本身也有开销。三层加起来，最终能跑到原生性能的 30% 到 50% 就算不错了。
这意味着什么？意味着用这套方案跑大型 3D 游戏，帧率可能只有个位数到十几帧，体验不会太好。但跑一些 2D 游戏、老游戏、或者对性能要求不高的应用，还是可以接受的。所以 Madeira 这类项目的定位，我觉得更多是“能跑起来”而不是“跑得爽”，它的价值在于验证可行性，而不是替代原生平台。
| 层级 | 组件 | 负责翻译的内容 | 典型性能损耗 |
|---|---|---|---|
| API 层 | Wine | Windows 系统调用到宿主系统调用 | 10% - 20% |
| 指令层 | FEX-Emu | x86-64 指令到 ARM64 指令 | 30% - 50% |
| 图形层 | DXMT | Direct3D 到 Metal | 20% - 40% |
提示：三层叠加后的总损耗不是简单相加，而是相互放大。实际测试中，一个在 Windows 上跑 60 帧的游戏，在这套方案下可能只有 15 到 20 帧。
3. iOS 平台的特殊挑战：沙盒、签名与图形接口
3.1 沙盒机制为什么让兼容层寸步难行
iOS 的沙盒机制是兼容层方案面临的第一道墙。每个应用只能访问自己沙盒目录下的文件，不能随意读取系统文件、不能加载外部动态库、不能创建可执行内存页。Wine 在运行 Windows 程序时，需要加载大量的动态链接库，需要创建可执行内存来存放翻译后的代码，这些操作在 iOS 沙盒里都是被严格限制的。
我试过在 iOS 上跑一些简单的命令行工具，光是让程序能加载起来就费了很大劲。你需要把所有的依赖库都打包进应用包里，然后通过相对路径去加载，任何试图访问沙盒外路径的操作都会直接被系统拒绝。而且 iOS 不允许应用在运行时下载可执行代码，这意味着你不能像在桌面上那样动态安装 Wine 的组件，所有东西必须在打包时就准备好。
3.2 代码签名和 JIT 权限的限制
iOS 对可执行代码的签名要求极其严格。所有在设备上运行的代码都必须经过苹果的签名验证，未签名的代码无法执行。FEX-Emu 在运行时需要动态生成翻译后的 ARM64 代码，这些代码在内存中是没有签名的，iOS 默认不允许执行。要绕过这个限制，通常需要利用一些系统提供的特殊权限，比如 JIT 权限，但 JIT 权限在正式应用中是拿不到的，只有通过特定方式加载的应用才能获得。
这也是为什么很多 iOS 上的模拟器方案都依赖于侧载或者企业签名。热搜里出现的“ios 开发者模式”“ios 26.3.1 怎么开发者模式”这些词，说明很多用户卡在了开发者模式的开启上。开发者模式本身是为了方便调试，但它也间接为一些非商店应用提供了运行环境。不过苹果在后续版本中不断收紧开发者模式的权限，这个口子能开多久不好说。
3.3 Metal 接口的封闭性对 DXMT 的影响
Metal 是苹果的图形接口，文档公开，但底层实现细节不公开。DXMT 要把 Direct3D 调用翻译成 Metal 调用，就必须对 Metal 的行为有深入理解。问题在于，Metal 的某些行为在不同 GPU 架构上表现不一致，比如 A 系列芯片和 M 系列芯片的 Metal 实现就有差异。DXMT 在桌面 macOS 上可能跑得不错，但移植到 iOS 上，面对的是完全不同的 GPU 驱动栈，很多在桌面上验证过的翻译规则需要重新调整。
另外，iOS 上 Metal 的资源管理比 macOS 更严格，纹理内存、缓冲区大小都有限制。Direct3D 程序如果申请了超出限制的资源，DXMT 必须做相应的降级处理，否则就会直接崩溃。我在测试中遇到过游戏加载大纹理时闪退的情况，后来发现是 Metal 的纹理尺寸上限比 Direct3D 低，需要在 DXMT 里做纹理压缩或者分块加载。
3.4 输入与窗口系统的适配
Windows 程序的输入模型和 iOS 的触摸输入模型完全不同。Windows 程序期望的是键盘、鼠标、窗口消息，而 iOS 只有触摸屏和有限的键盘支持。Wine 需要把触摸事件翻译成鼠标事件，把软键盘输入翻译成键盘消息，还要处理窗口的创建、移动、缩放。这些在桌面上由窗口管理器负责的事情，在 iOS 上都需要兼容层自己实现。
热搜里“notification banner 仿 ios 通知横幅”这个词，虽然看起来跟兼容层没关系，但它反映了一个需求：用户希望在非 iOS 环境里模拟 iOS 的界面元素。反过来，在 iOS 上跑 Windows 程序，也需要模拟 Windows 的窗口样式和交互逻辑，这中间的适配工作量非常大。
4. 实操环境搭建：从零开始配置 Madeira 链路
4.1 基础环境准备与依赖梳理
假设我们要在一台 ARM64 的 iOS 设备或者类似的 ARM64 Linux 环境上搭建这套链路，第一步是把基础依赖装齐。需要准备的东西包括：Wine 的源码或预编译包、FEX-Emu 的运行时和根文件系统、DXMT 的编译产物、以及一个能加载这些组件的宿主应用框架。
在 Linux 环境下，这个过程相对 straightforward，因为包管理器可以直接装。但在 iOS 上，你需要自己交叉编译所有组件，因为 iOS 的 SDK 和 Linux 的 glibc 环境不兼容。交叉编译 Wine 到 iOS 是个大工程，需要处理大量的平台相关代码，很多系统调用在 iOS 上不存在，需要写适配层。
我个人的建议是，如果你只是想验证可行性，先在 ARM64 Linux 上把链路跑通，然后再考虑往 iOS 上移植。Linux 上遇到的问题和 iOS 上遇到的问题有重叠，但 Linux 的调试手段更丰富，出了问题更容易定位。
4.2 FEX-Emu 的配置与根文件系统准备
FEX-Emu 需要一个根文件系统来提供 x86-64 程序运行所需的基础库和配置。这个根文件系统通常是一个精简的 Linux 发行版，里面包含了 Wine 运行所需的库文件。你可以用 debootstrap 或者类似工具生成一个基础的 x86-64 根文件系统，然后把 Wine 装进去。
配置 FEX-Emu 的时候，有几个关键参数需要注意。FEX_ROOTFS指向根文件系统的路径，FEX_APP_CONFIG用来指定应用的配置，FEX_LOG_LEVEL控制日志详细程度。调试阶段建议把日志开到 verbose，这样能看到每一条翻译指令的执行情况，虽然日志量很大，但对定位问题很有帮助。
export FEX_ROOTFS=/path/to/rootfs export FEX_APP_CONFIG=/path/to/config.json export FEX_LOG_LEVEL=verbose FEXBash -c "wine notepad.exe"上面这段命令的意思是，在 FEX-Emu 的环境里启动一个 bash，然后在里面运行 Wine 加载记事本。如果记事本能正常弹出来，说明 Wine 和 FEX-Emu 的配合基本没问题。如果报错，就要看日志里是哪一步出了问题。
4.3 DXMT 的编译与 Metal 后端配置
DXMT 的编译需要 Xcode 和 Metal 开发工具链。在 macOS 上编译相对容易，因为可以直接用 Xcode 的 Metal 框架。在 Linux 上编译 DXMT 就比较麻烦，因为 Metal 是苹果独有的，Linux 上没有对应的实现。所以 DXMT 的开发和调试基本只能在 macOS 或 iOS 环境下进行。
编译 DXMT 的时候，需要指定目标平台和 Metal 版本。iOS 上的 Metal 版本和 macOS 上不完全一样，一些高级特性在 iOS 上不可用，需要在编译时做条件编译。另外，DXMT 的着色器编译器需要把 Direct3D 的着色器字节码翻译成 Metal 的着色器语言，这个翻译过程对性能影响很大，建议开启缓存，避免每次启动都重新编译。
4.4 整合启动脚本与运行时参数调优
把三层组件整合到一起，需要一个启动脚本来协调。这个脚本要负责设置环境变量、加载根文件系统、启动 FEX-Emu、在 FEX-Emu 里启动 Wine、然后让 Wine 加载目标程序。每一步的参数都需要仔细调整，比如 Wine 的WINEPREFIX要指向一个可写的目录，WINEDLLOVERRIDES要用来禁用一些不兼容的 DLL。
运行时参数调优是个反复试错的过程。我一般会先从默认参数开始，跑一个简单的程序，看哪里报错，然后针对性地调整。比如遇到图形初始化失败，就检查 DXMT 的日志，看是 Metal 设备创建失败还是着色器编译失败。遇到音频问题，就检查 Wine 的音频后端配置，iOS 上的音频接口和桌面 Linux 完全不同，需要专门的适配。
| 环境变量 | 作用 | 推荐值 |
|---|---|---|
| FEX_ROOTFS | 指定根文件系统路径 | /path/to/rootfs |
| WINEPREFIX | 指定 Wine 前缀目录 | /path/to/prefix |
| WINEDLLOVERRIDES | 覆盖 DLL 加载行为 | d3d11=n,b |
| DXMT_LOG_LEVEL | DXMT 日志级别 | info |
| FEX_LOG_LEVEL | FEX-Emu 日志级别 | warn |
注意：在 iOS 上，WINEPREFIX 必须指向沙盒内的可写目录，否则 Wine 无法创建配置文件，启动会直接失败。
5. 常见问题与排查技巧实录
5.1 Wine 乱码问题的根因与修复
“wine 乱码”“wine 栏是乱码”是热搜里出现频率很高的问题。乱码的根因通常有三个：字体缺失、编码映射错误、区域设置不对。Wine 在渲染 Windows 程序的界面时，会调用 Windows 的字体接口，如果宿主系统里没有对应的字体，Wine 就会用默认字体替代，而默认字体可能不支持中文，于是中文就显示成方块或者乱码。
修复方法分几步走。第一步，把 Windows 的常用字体复制到 Wine 的字体目录里，比如C:\Windows\Fonts对应的目录。第二步，检查 Wine 的注册表里字体替换的设置，确保中文程序请求的字体能被正确映射到已安装的字体。第三步，设置正确的区域设置，LANG和LC_ALL要设成zh_CN.UTF-8，否则 Wine 可能用错误的编码去解析字符串。
我在实际处理中发现，有些乱码不是字体问题，而是程序本身用了非 Unicode 编码，而 Wine 的编码转换出了错。这种情况需要在 Wine 的配置里强制指定代码页，或者用winecfg里的字体替换功能手动映射。
5.2 FEX-Emu 启动失败的排查路径
FEX-Emu 启动失败的原因很多，我整理了一个排查顺序。先看根文件系统是否完整，/lib和/usr/lib下的库文件是否齐全。再看 FEX-Emu 的版本和根文件系统的架构是否匹配，x86-64 的根文件系统不能用在只支持 x86 的 FEX-Emu 上。然后看内核是否支持 FEX-Emu 需要的特性，比如memfd_create、userfaultfd这些系统调用，在 iOS 上可能不存在或者被限制。
如果日志里出现“illegal instruction”或者“unhandled instruction”，说明 FEX-Emu 遇到了不支持的指令。这时候可以尝试更新 FEX-Emu 到最新版本，或者用FEX_APP_CONFIG里的指令集配置来禁用某些指令扩展。有些程序会检测 CPU 特性，如果检测不到就拒绝运行，这时候可以用 FEX-Emu 的 CPU 伪装功能，让它报告一个支持更多特性的 CPU 型号。
5.3 DXMT 图形初始化失败的典型场景
DXMT 初始化失败最常见的原因是 Metal 设备创建失败。在 iOS 上，Metal 设备的创建需要应用有正确的图形权限，如果应用没有配置好，Metal 会返回空设备。另外，DXMT 需要访问 Metal 的命令队列和渲染管线，这些资源在 iOS 上都是有限制的，如果应用同时创建了太多 Metal 资源，系统会拒绝新的创建请求。
还有一种情况是着色器编译失败。Direct3D 的着色器模型和 Metal 的着色器模型差异很大，DXMT 的翻译器不可能覆盖所有情况。遇到复杂的着色器，翻译器可能生成无效的 Metal 代码，导致编译失败。这时候可以尝试降低着色器模型版本，或者用 DXMT 的兼容模式，牺牲一些图形效果来换取兼容性。
5.4 iOS 侧载与开发者模式的坑
热搜里“ios 开发者模式”“ios 26.3.1 怎么开发者模式”这些词，说明很多用户卡在了侧载环节。iOS 的开发者模式需要在设置里手动开启，而且开启后设备会重启。开启开发者模式之后，还需要用 Xcode 或者类似的工具把应用安装到设备上，安装过程中需要信任开发者证书。
这里有个坑：开发者证书有有效期，过期之后应用就无法启动，需要重新签名安装。另外，免费开发者账号签名的应用只能运行 7 天，7 天之后需要重新签名。这对于需要长时间测试的兼容层方案来说很麻烦，你可能刚把环境配好，证书就过期了。
| 问题现象 | 可能原因 | 排查方法 |
|---|---|---|
| Wine 界面乱码 | 字体缺失或编码错误 | 检查字体目录和 LANG 设置 |
| FEX-Emu 启动即崩溃 | 根文件系统不完整 | 检查 /lib 和 /usr/lib |
| DXMT 初始化失败 | Metal 设备创建失败 | 检查图形权限和资源限制 |
| 应用安装后无法启动 | 证书过期或未信任 | 重新签名并信任证书 |
| 游戏帧率极低 | 三层翻译损耗叠加 | 降低画质和分辨率 |
5.5 性能调优的实战经验
性能调优这块，我踩过的坑最多。一开始我总想着把所有参数都开到最高，结果发现帧率反而更低。后来才明白，翻译层的性能瓶颈往往不在 CPU 或 GPU 的绝对性能，而在翻译效率。比如 FEX-Emu 的翻译缓存如果太小，就会频繁重新翻译相同的代码块，导致性能下降。把缓存调大之后，帧率能提升不少。
DXMT 这边，着色器编译缓存也很关键。第一次运行游戏时，着色器需要实时编译，帧率会很低，等缓存建立起来之后，帧率就稳定了。所以测试性能的时候，不要只看第一次运行的帧率，要等缓存预热之后再测。
另外，分辨率对性能的影响非常大。在 iOS 设备上，原生分辨率很高，但兼容层方案跑不动那么高的分辨率。把渲染分辨率降到 720p 甚至更低，帧率会有明显提升。虽然画面糊一点，但至少能玩。
6. 这条链路还能怎么扩展
6.1 从 iOS 到其他 ARM 平台的迁移思路
Madeira 这套方案虽然以 iOS 为目标，但它的架构是通用的。把 iOS 换成 Android，把 Metal 换成 Vulkan，把 FEX-Emu 换成其他的 x86-64 翻译器，就能迁移到 Android 平台。实际上，Android 上已经有类似的方案在跑，比如 Winlator、Box64 这些项目，思路和 Madeira 大同小异。
迁移的关键在于图形层的适配。Android 上用 Vulkan 而不是 Metal，DXMT 需要换成 DXVK 或者类似的 Direct3D 到 Vulkan 的翻译器。DXVK 在桌面 Linux 上已经很成熟了，移植到 Android 上的主要挑战是 Vulkan 驱动的兼容性和性能。
6.2 信创场景下的兼容层需求
热搜里“麒麟 wine 助手”“统信 wine windows 兼容组件下载”这些词，反映的是信创场景下对 Windows 应用兼容的强烈需求。很多单位在迁移到国产操作系统时，发现一些关键的 Windows 应用没有 Linux 版本，只能用 Wine 来跑。麒麟和统信都提供了自己的 Wine 发行版和助手工具，简化了配置过程。
这些工具和 Madeira 的思路是一致的，只是目标平台不同。信创场景下的兼容层更注重稳定性和易用性，而不是性能。毕竟办公应用对帧率没要求，能正常打开、正常编辑、正常保存就行。所以这些工具在配置上做了很多自动化处理，用户不需要手动调参数。
6.3 云游戏与远程渲染的替代方案
如果本地跑不动，还有一个思路是把渲染放到云端。本地只负责输入和显示，实际的 Windows 程序在云端的 x86-64 服务器上运行，渲染结果通过视频流传回本地。这样本地设备不需要强大的 CPU 和 GPU，只需要稳定的网络和视频解码能力。
这个思路的好处是绕开了本地翻译层的性能瓶颈，坏处是依赖网络，延迟和画质受网络条件影响很大。对于 iOS 设备来说，云游戏的方案可能比本地兼容层更实用，因为 iOS 的硬件性能虽然强，但翻译层的损耗太大，本地跑大型游戏体验不好。
6.4 开发者视角：这套方案对跨平台开发的启示
从开发者的角度看，Madeira 这类项目最大的启示是：跨平台不一定要重写代码，兼容层可以作为一种过渡方案。如果你有一个 Windows 应用，想让它跑到 iOS 上，重写一遍成本太高，用兼容层先跑起来，验证需求，再决定要不要原生重写，这是一个务实的策略。
当然，兼容层不是万能的。它对性能敏感的应用不友好，对依赖特定硬件特性的应用也不友好。但在很多场景下，能跑起来比跑得快更重要。先解决有无问题，再解决好坏问题，这是工程上常见的取舍。
我在实际折腾这套链路的过程中，最大的体会是：兼容层的每一个环节都充满了不确定性，你永远不知道下一个崩溃是来自 Wine 的 API 翻译、FEX-Emu 的指令翻译，还是 DXMT 的图形翻译。排查问题的时候，日志是你最好的朋友，耐心是你最需要的品质。有时候一个问题卡好几天，最后发现只是某个环境变量设错了，这种时候真是又好气又好笑。但当你看到 Windows 程序真的在 iOS 设备上跑起来的那一刻，那种成就感是实打实的。
