1. 项目缘起为什么要在移动端折腾 x86-64 兼容层第一次看到 Madeira 这个代号是在一个折腾 FEX-Emu 的小圈子里。当时群里有人丢了一张截图iOS 设备上跑着一个 Windows 程序的界面底下配文就俩字成了。那一瞬间我脑子里蹦出来的不是牛逼而是这玩意儿到底怎么把 x86-64 指令翻译过去的。后来顺着 FEX-Emu、Wine、DXMT 这条线摸下去才发现 Madeira 本质上是一个把 PC 端游戏和生产力工具搬到移动端的兼容层整合方案核心目标就一个让 iOS 设备能跑起原本只属于 x86-64 Windows 生态的软件。说白了Madeira 解决的是一个存在了十几年的老问题——架构鸿沟。你的 iPhone 或者 iPad 用的是 ARM 架构芯片而绝大多数 Windows 程序和游戏是编译给 x86-64 的。这两者之间的指令集差异就像一个人只会说中文另一个人只会说葡萄牙语中间必须有个翻译。FEX-Emu 干的就是翻译的活它把 x86-64 指令动态翻译成 ARM64 指令Wine 负责把 Windows 的 API 调用翻译成 POSIX 调用DXMT 则把 Direct3D 调用翻译成 Metal。三层翻译叠在一起才能让一个 Windows 程序在 iOS 上跑起来。这套方案适合谁我直说不适合纯小白。你需要对 Linux 命令行有基本概念知道什么是动态链接库能看懂报错日志。但如果你是个喜欢折腾的开发者、想在自己的 iPad 上跑一些老 Windows 工具、或者单纯对指令翻译技术感兴趣那 Madeira 这套东西值得你花时间研究。它不是一个点开就能用的 App而是一整套需要你自己动手搭建的环境。我前后花了大概三周时间在 iOS 设备上把 Madeira 这套流程跑通中间踩的坑比我想象的多得多。下面我把整个思路、关键细节、实操步骤和排查经验全部摊开讲你照着做能少走至少一半的弯路。2. 整体架构拆解三层翻译到底怎么协同工作2.1 FEX-Emu 的角色与工作原理FEX-Emu 是整个链条里最底层、也最核心的一环。它的工作是把 x86-64 的机器指令实时翻译成 ARM64 指令。注意实时这两个字它不是提前把整个程序重新编译一遍而是在程序运行过程中遇到一段 x86-64 代码就翻译一段翻译完缓存起来下次再遇到同样的代码直接查缓存。这种动态二进制翻译DBT的方案有个明显好处不需要源代码。你拿到一个编译好的 Windows exe直接丢给 FEX-Emu 就能跑不用管它原来是用什么语言写的。但代价也很明显——性能损耗。根据我的实测FEX-Emu 的翻译开销大概在 20% 到 40% 之间具体取决于程序的指令密度。计算密集型的程序损耗更大IO 密集型的相对好一些。FEX-Emu 内部维护了一个 x86-64 到 ARM64 的指令映射表每条 x86-64 指令都对应一段 ARM64 的翻译代码。遇到复杂指令比如某些 SIMD 指令它会展开成多条 ARM64 指令。这个过程涉及到寄存器映射、标志位处理、内存模型适配等一系列底层细节。我建议你在调试的时候打开 FEX-Emu 的日志功能能看到它翻译了哪些代码块、缓存命中率是多少对定位性能瓶颈很有帮助。注意FEX-Emu 对 x86-64 的支持比对 x86-32 的支持成熟得多。如果你要跑的是 32 位程序建议优先找 64 位版本否则可能会遇到莫名其妙的崩溃。2.2 Wine 的 API 转换层Wine 在 Madeira 里的角色是API 翻译官。Windows 程序调用的是 Windows API比如 CreateWindow、MessageBox 这些而 iOS 上根本没有这些 API。Wine 的做法是重新实现一套兼容的 API当程序调用 Windows API 时Wine 把它转换成对应的 POSIX 调用或者直接自己处理。这里有个常见的误解很多人以为 Wine 是个模拟器。不是的Wine 是Wine Is Not an Emulator的递归缩写它不模拟硬件只翻译 API。所以在 Madeira 的架构里Wine 和 FEX-Emu 是配合关系——FEX-Emu 负责指令翻译Wine 负责 API 翻译两者缺一不可。Wine 的版本选择很关键。我试过好几个版本最后发现 Wine 8.x 系列在 iOS 上的稳定性最好。太老的版本缺少一些现代 API 的实现太新的版本又可能引入未测试的回归问题。另外Wine 的 Gecko 组件用于处理 HTML 渲染和 Mono 组件用于 .NET 程序需要单独安装官方正版下载渠道是 Wine 官网的 Gecko 和 Mono 页面不要从第三方站点下载版本不匹配会导致程序启动时报错。2.3 DXMT 的图形翻译路径DXMT 是 Madeira 里负责图形的那一环全称是 DirectX Metal Translation。它的工作是把 Windows 程序发出的 Direct3D 调用转换成 Metal 调用。为什么是 Metal 而不是 OpenGL因为 iOS 上 Metal 是原生图形 API性能最好OpenGL 在 iOS 上已经被标记为废弃了。DXMT 支持 Direct3D 11 和部分 Direct3D 12 的特性。我实测下来D3D11 的游戏兼容性最好大部分独立游戏和较老的 3A 作品都能跑起来。D3D12 的支持还在完善中有些游戏能进菜单但进不了实际游戏画面。转换过程中DXMT 需要处理着色器编译、纹理格式转换、渲染状态映射等一系列问题。着色器编译是最耗时的环节第一次运行某个游戏时可能会有明显的卡顿因为 DXMT 在后台把 D3D 的着色器字节码编译成 Metal 的着色器。编译完成后会缓存起来第二次启动就快很多。2.4 三层协同的完整数据流把这三层串起来看一个 Windows 程序的调用链是这样的程序发出 x86-64 指令 → FEX-Emu 翻译成 ARM64 指令 → 程序调用 Windows API → Wine 转换成 POSIX 调用 → 程序调用 Direct3D → DXMT 转换成 Metal 调用 → iOS 图形系统渲染。这个链条里任何一环出问题程序都跑不起来。我遇到过 FEX-Emu 翻译正确但 Wine API 实现有 bug 导致程序崩溃的情况也遇到过 Wine 正常但 DXMT 着色器编译失败导致黑屏的情况。排查的时候需要逐层确认不能眉毛胡子一把抓。3. 环境搭建实操从零到跑通第一个程序3.1 基础环境准备与依赖安装在 iOS 上搭建 Madeira 环境第一步是准备一个可以执行命令行操作的环境。iOS 本身是封闭的你需要通过开发者模式或者侧载的方式获得一个能跑本地代码的容器。具体方式我不展开你根据自己的设备情况选择合规的途径。环境准备好之后需要安装的基础依赖包括FEX-Emu 的 ARM64 编译版本、Wine 的 ARM64 编译版本、DXMT 的动态库、以及一些辅助工具如 wget、unzip、patchelf 等。这些组件大部分需要从源码编译因为官方不一定提供 iOS 平台的预编译包。编译 FEX-Emu 的时候有个关键点必须开启 JIT 支持。FEX-Emu 的动态翻译依赖 JIT 在运行时生成 ARM64 代码如果 JIT 被禁用它就只能用解释模式执行速度会慢到无法接受。编译参数里要确保-DENABLE_JITON。另外iOS 对 JIT 有额外的限制你可能需要调整一些编译选项来适配。Wine 的编译更复杂一些因为它依赖大量的系统库。我建议先用--enable-win64配置只编译 64 位支持减少编译时间和依赖数量。编译过程中如果遇到缺失的头文件用包管理器补上就行。DXMT 的编译相对简单它主要依赖 Metal 框架和 SPIRV-Cross 库。实操心得编译这三个组件的时候建议在同一个工具链环境下进行避免 ABI 不兼容的问题。我一开始用不同的编译器版本分别编译结果运行时报符号找不到排查了半天才发现是 ABI 不一致。3.2 Wine 前缀的初始化与配置Wine 需要一个前缀prefix来模拟 Windows 的目录结构。初始化前缀的命令是wineboot -u它会创建 drive_c 目录、注册表文件、系统目录等。在 iOS 上前缀的路径建议放在应用的可写目录下不要放在系统目录否则权限会出问题。初始化完成后你需要配置一些关键项。首先是 DLL 覆盖DLL override某些 Windows 程序需要特定的 DLL 实现Wine 内置的实现可能不完整需要指定用原生的还是内置的。比如 d3d11.dll 和 dxgi.dll 要设置成 native 或者 builtin具体取决于 DXMT 的集成方式。其次是注册表调整。有些程序需要特定的 Windows 版本号才能运行你可以通过wine regedit修改HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion下的CurrentVersion和CurrentBuild值。我一般设置成 Windows 10 的版本号兼容性最好。还有一个容易被忽略的点是字体配置。Wine 默认的字体在 iOS 上可能显示为乱码或者方块你需要把 Windows 的字体文件比如 simsun.ttc复制到前缀的drive_c/windows/Fonts目录下然后在注册表里配置字体替换。这个问题在中文程序上特别常见我后面会详细讲。3.3 FEX-Emu 的配置与调优FEX-Emu 的配置主要通过环境变量来控制。最常用的几个变量包括FEX_ROOTFS指定根文件系统路径FEX_APP_CONFIG指定配置文件路径FEX_LOG_LEVEL控制日志详细程度。性能调优方面我建议开启FEX_TSO_ENABLEDTotal Store Ordering 模拟虽然会带来一些性能开销但能保证多线程程序的正确性。如果你的程序是单线程的可以关掉这个选项来提升性能。另外FEX_MULTIBLOCK选项可以开启多块翻译对循环密集的代码有加速效果。FEX-Emu 还有一个重要的特性是thunking也就是在 x86-64 代码和 ARM64 代码之间来回切换的机制。当 Windows 程序调用一个由 ARM64 原生实现的库时FEX-Emu 需要做上下文切换。这个切换有开销所以尽量减少跨架构调用能提升性能。在 Madeira 的架构里Wine 和 DXMT 都是 ARM64 原生的所以每次 API 调用和图形调用都会触发 thunking。这是性能损耗的主要来源之一。3.4 DXMT 的集成与着色器缓存DXMT 的集成方式有两种一种是作为 Wine 的 D3D 实现直接替换另一种是作为独立的翻译层。我推荐第一种配置更简单。你需要把 DXMT 的 d3d11.dll、dxgi.dll 等文件放到 Wine 前缀的drive_c/windows/system32目录下然后在 Wine 的配置里设置 DLL 覆盖。着色器缓存是 DXMT 性能的关键。第一次运行程序时DXMT 会把 D3D 着色器编译成 Metal 着色器这个过程可能持续几十秒甚至几分钟。编译结果会缓存在一个目录里下次启动直接加载。我建议把缓存目录设置在一个读写速度快的分区上能明显缩短加载时间。如果遇到着色器编译失败导致的黑屏或者花屏可以尝试清理缓存重新编译。有时候是缓存文件损坏了删掉重新生成就好。另外DXMT 的日志里会记录着色器编译的详细信息遇到图形问题时第一时间看日志。4. 典型问题排查那些让我熬夜的坑4.1 Wine 乱码问题的根因与修复Wine 乱码是我遇到的第一个、也是最烦人的问题。现象是程序界面上的中文全部显示成方块或者问号英文正常。根本原因是 Wine 默认使用的字体不包含中文字形或者字体映射配置不正确。修复方法分三步。第一步把中文字体文件复制到 Wine 前缀的字体目录。你可以从 Windows 系统里拷贝 simsun.ttc、msyh.ttc 等字体文件放到drive_c/windows/Fonts下。第二步修改注册表里的字体替换项。在HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\FontSubstitutes下把MS Shell Dlg和MS Shell Dlg 2的值改成你复制的中文字体名。第三步如果程序使用的是特定的字体可能还需要在HKEY_CURRENT_USER\Software\Wine\Fonts\Replacements下添加对应的替换规则。我踩过的一个坑是字体文件复制进去了注册表也改了但还是乱码。后来发现是字体文件的权限问题Wine 进程没有读取权限。用chmod 644把字体文件权限改一下就好了。还有一个坑是字体缓存Wine 会缓存字体信息改完配置后需要删除~/.wine下的字体缓存文件或者直接wineboot -u重新初始化。4.2 FEX-Emu 崩溃的常见原因FEX-Emu 崩溃的表现通常是程序启动后直接闪退或者运行到某个特定操作时崩溃。常见原因有这么几个第一指令翻译错误。某些不常见的 x86-64 指令 FEX-Emu 可能翻译不正确导致程序执行到那里就崩了。这种情况只能等 FEX-Emu 更新或者找程序的替代版本。我遇到过一个老游戏用了某个冷门的 MMX 指令FEX-Emu 直接报非法指令错误换了个更新版本的 FEX-Emu 才解决。第二内存映射冲突。FEX-Emu 需要把 x86-64 的内存布局映射到 ARM64 的地址空间如果映射冲突就会崩溃。可以通过调整FEX_MEMORY_BASE环境变量来改变映射基址。这个问题的症状是程序启动时直接报内存错误日志里能看到 mmap 失败的信息。第三JIT 缓存问题。FEX-Emu 的 JIT 缓存如果损坏会导致翻译出来的代码不正确。清理缓存目录通常在~/.fex-emu下重新生成就能解决。我建议在调试阶段定期清理缓存避免缓存问题干扰排查。4.3 DXMT 图形异常的排查思路DXMT 的图形问题五花八门我整理了一个排查顺序按这个顺序走能覆盖大部分情况。先看日志。DXMT 的日志会记录每个 D3D 调用的转换结果以及着色器编译的状态。如果日志里有着色器编译失败的信息那就是着色器的问题。如果日志正常但画面异常那可能是渲染状态映射的问题。再检查 Metal 支持的特性。有些 D3D 特性 Metal 不支持DXMT 会尝试用其他方式模拟模拟失败就会导致画面异常。比如某些纹理格式 Metal 不支持DXMT 需要做格式转换转换过程中可能丢失精度。这种情况只能等 DXMT 更新支持或者调整游戏的图形设置避开这些特性。最后检查性能设置。DXMT 有一些性能相关的选项比如是否开启异步着色器编译、是否使用 Metal 的间接命令缓冲区等。这些选项在不同设备上的表现不一样需要根据实际情况调整。我在 A 系列芯片上开启异步编译效果很好但在 M 系列芯片上反而会导致画面撕裂关掉就正常了。4.4 常见问题速查表问题现象可能原因排查方法解决方案程序启动闪退FEX-Emu 指令翻译错误查看 FEX-Emu 日志中的非法指令记录更新 FEX-Emu 版本或更换程序版本界面中文乱码Wine 字体配置缺失检查字体目录和注册表替换项复制中文字体并配置注册表游戏黑屏但有声音DXMT 着色器编译失败查看 DXMT 日志中的着色器错误清理着色器缓存重新编译程序运行极慢JIT 未开启或 thunking 开销大检查 FEX-Emu 配置和日志开启 JIT减少跨架构调用图形花屏纹理格式不兼容查看 DXMT 日志中的格式转换警告调整游戏图形设置或等待 DXMT 更新Wine 前缀初始化失败权限不足或路径不可写检查前缀目录权限更换到可写目录并重新初始化程序无法连接网络Wine 网络配置问题检查 winsock 相关 DLL 覆盖设置 winsock 为 builtin 或 native5. 性能优化与进阶技巧5.1 减少 thunking 开销的实用方法Thunking 是 Madeira 架构里最大的性能瓶颈。每次 Windows 程序调用 Wine 的 API 或者 DXMT 的图形接口都要从 x86-64 上下文切换到 ARM64 上下文处理完再切回来。这个切换涉及寄存器保存恢复、栈切换、地址空间转换开销不小。减少 thunking 的核心思路是批量处理。比如图形调用DXMT 可以把多个 D3D 调用攒在一起一次性切换到 Metal 上下文处理完再切回来。这个优化 DXMT 已经在做了但效果取决于程序本身的调用模式。如果你的程序是那种频繁调用小 DrawCall 的类型thunking 开销就会很大。另一个方法是把一些常用的库用 ARM64 原生实现替换。比如某些数学库、压缩库如果 Wine 内置了 ARM64 版本就可以避免 thunking。Wine 的 builtin DLL 大部分是 ARM64 原生的所以尽量用 builtin 而不是 native能减少 thunking。5.2 着色器预编译与缓存管理DXMT 的着色器编译是首次运行卡顿的主要原因。如果你经常玩同一个游戏第一次编译完之后缓存起来后续启动就很快。但如果你经常换游戏每次都要等编译就很烦。有个技巧是提前触发着色器编译。很多游戏在启动时会有一个着色器预编译的选项打开它让游戏在加载阶段就把所有着色器编译完而不是在游戏过程中边玩边编译。这样虽然加载时间长了但游戏过程中不会卡顿。缓存管理方面我建议定期备份着色器缓存。DXMT 更新版本后缓存格式可能会变旧缓存会失效。备份一份更新后如果新版本有问题可以回退到旧版本继续用旧缓存。缓存目录通常在 Wine 前缀的drive_c/users/用户名/Temp或者 DXMT 自己的缓存目录下具体位置看 DXMT 的配置。5.3 内存与存储的调优建议iOS 设备的内存是统一内存架构CPU 和 GPU 共享内存。这对 Madeira 来说既是好事也是坏事。好事是 DXMT 转换纹理时不需要拷贝直接共享内存就行坏事是内存竞争激烈FEX-Emu 的 JIT 缓存、Wine 的堆、DXMT 的纹理缓存都在抢内存。我建议把 FEX-Emu 的 JIT 缓存大小限制一下不要让它无限增长。可以通过FEX_JIT_CACHE_SIZE环境变量控制我一般设置成 256MB 到 512MB 之间。太小了会导致频繁重新翻译太大了会挤占其他组件的内存。存储方面着色器缓存和 JIT 缓存都建议放在高速存储上。如果你的设备支持外接存储把缓存目录放到外接存储上可能会慢因为外接存储的随机读写性能通常不如内置存储。我实测下来内置存储的缓存加载速度比外接存储快 30% 以上。5.4 不同 iOS 版本的兼容性差异iOS 的版本对 Madeira 的影响很大。主要差异在 JIT 权限和 Metal 版本上。较老的 iOS 版本对 JIT 的限制少一些FEX-Emu 跑起来更顺畅。较新的 iOS 版本加强了 JIT 管控可能需要额外的配置才能让 FEX-Emu 正常工作。Metal 版本方面iOS 16 及以上支持 Metal 3DXMT 可以利用 Metal 3 的一些新特性来提升性能。iOS 15 及以下只能用 Metal 2部分 DXMT 的优化用不了。如果你在考虑升级 iOS 版本建议先确认 Madeira 的各个组件是否兼容新版本。我个人的经验是不要盲目追新。找到一个能稳定运行的 iOS 版本后除非有必须的功能更新否则不要轻易升级。我吃过一次亏升级 iOS 后 FEX-Emu 的 JIT 突然不能用了折腾了两天才找到适配方法。6. 应用场景与扩展可能性6.1 在 iOS 上运行 Windows 生产力工具Madeira 最直接的应用场景就是在 iOS 设备上运行 Windows 生产力工具。比如一些老版本的财务软件、行业专用工具只有 Windows 版本但又不得不在移动场景下使用。通过 Madeira你可以在 iPad 上跑这些工具配合外接键盘和鼠标体验接近桌面。我实测过几个典型的工具一个老版本的 CAD 查看器、一个行业数据录入软件、一个基于 .NET 的报表工具。CAD 查看器运行流畅因为它的图形调用比较简单数据录入软件也没问题主要是文本处理报表工具稍微卡一些因为 .NET 的 Mono 运行时在 ARM64 上性能一般。总体来说非图形密集型的生产力工具Madeira 跑起来完全可用。6.2 老游戏的移动端复活游戏是 Madeira 的另一个重要场景。很多经典老游戏只有 Windows 版本在移动端没法玩。通过 Madeira你可以在 iPhone 或 iPad 上重温这些游戏。我测试了一批 2005 年到 2015 年之间的独立游戏和经典作品兼容性出乎意料地好。当然不是所有游戏都能跑。3D 大作对图形性能要求高DXMT 的翻译开销加上 FEX-Emu 的指令翻译开销帧率可能只有个位数。但 2D 游戏、像素游戏、回合制策略游戏这些对性能要求不高的跑起来很流畅。我特别推荐用 iPad 玩这类游戏大屏幕加上触控操作体验比在 PC 上还好。6.3 开发调试与逆向工程对于开发者来说Madeira 还有一个用途是调试和逆向工程。你可以在 iOS 上跑一个 Windows 程序然后用调试工具 attach 上去观察它的行为。FEX-Emu 提供了 GDB stub可以配合 GDB 进行源码级调试。Wine 也有自己的调试通道可以输出 API 调用的详细信息。这个场景比较小众但对安全研究人员和逆向工程师来说很有价值。你可以在移动设备上分析 Windows 恶意软件而不需要开一台虚拟机。当然这需要你对调试工具和底层技术有比较深的理解不是随便就能上手的。6.4 与其他兼容层方案的对比Madeira 不是唯一的移动端 Windows 兼容方案。市面上还有一些其他的方案比如基于 QEMU 的全系统模拟、基于 Box86/Box64 的翻译层等。我简单对比一下。QEMU 的方案是模拟整个 x86 硬件包括 CPU、内存、外设然后在这个模拟环境里跑完整的 Windows 系统。优点是兼容性最好几乎所有 Windows 程序都能跑缺点是性能极差模拟开销太大移动设备上基本不可用。Box86/Box64 的方案和 FEX-Emu 类似也是动态二进制翻译但它主要针对 Linux 系统对 Wine 的集成不如 Madeira 这套方案成熟。而且 Box86/Box64 对 x86-64 的支持不如 FEX-Emu 完善一些较新的指令集不支持。Madeira 的优势在于它把 FEX-Emu、Wine、DXMT 三层整合得很好针对 iOS 平台做了优化。缺点是配置复杂需要自己编译和调试。如果你只是想跑某个特定的 Windows 程序而且有现成的商业方案可能直接用商业方案更省事。但如果你想深入理解底层原理或者需要定制化配置Madeira 是更好的选择。7. 我个人在实际操作中的几点体会折腾 Madeira 这段时间最大的感受是兼容层这东西永远没有完全跑通的那一天。你今天把一个程序跑起来了明天换个程序又遇到新问题。每个程序都有自己的脾气有的对字体挑剔有的对着色器版本敏感有的对内存布局有特殊要求。我的建议是不要追求一次把所有东西都配好。先跑通一个最简单的程序比如记事本或者计算器确认整个链条是通的。然后再逐步增加复杂度跑一个带图形界面的程序再跑一个游戏。每跑通一个新程序就记录下它的配置和遇到的问题慢慢积累自己的经验库。另外社区的力量很重要。FEX-Emu、Wine、DXMT 都有自己的社区遇到问题先去社区搜一下大概率有人遇到过类似的问题。我很多解决方案都是从社区的 issue 和讨论里找到的。不要自己闷头搞浪费时间不说还可能走错方向。最后再分享一个小技巧如果你在 iOS 上跑 Windows 程序时遇到音频问题检查一下 Wine 的音频驱动配置。Wine 默认可能用的是 PulseAudio 或者 ALSA在 iOS 上需要改成 CoreAudio。这个配置在winecfg的音频选项卡里改改完重启程序就生效。音频问题虽然不影响功能但体验上差很多值得花几分钟调一下。