1. 项目缘起为什么要在 iOS 上折腾 x86-64 的 Wine“Madeira”这个项目标题乍一看像是个地名但在我们这圈子里它指的是一套把Wine、FEX-Emu、DXMT串起来让 iOS 设备能够运行 x86-64 Windows 程序的技术方案。我第一次听到这个名字的时候脑子里蹦出来的第一个念头是iOS 上跑 Wine这不是开玩笑吗iOS 的沙盒机制、代码签名、没有 JIT 权限每一条都像是专门为了堵死这条路而设计的。但偏偏就有人不信邪硬是在这套封闭体系里凿出了一条缝。先说清楚这个项目到底解决什么问题。传统意义上Wine 是一个在 Linux 和 macOS 上运行 Windows 程序的兼容层它把 Windows 的 API 调用翻译成 POSIX 调用不需要虚拟机就能直接跑 exe。但 iOS 不是桌面系统它没有完整的 POSIX 环境没有动态链接器的自由更关键的是——它不允许你分配可执行内存。没有可执行内存JIT 就废了而 Wine 的很多核心功能恰恰依赖 JIT 来做指令翻译。所以“Madeira”这个项目的核心思路就是绕开 JIT 的限制用FEX-Emu做 x86-64 到 ARM64 的静态二进制翻译再用DXMT把 Direct3D 调用翻译成 Metal最后让 Wine 的 Windows API 层跑在 iOS 的运行时环境里。这套方案适合谁看如果你是一个对 iOS 底层机制感兴趣的安全研究者或者是一个想在移动端跑老 Windows 游戏的折腾党再或者你只是好奇“iOS 到底能不能跑 exe”这个问题的答案那这篇内容就是写给你的。我不会教你怎么越狱也不会涉及任何具体的绕过签名的操作细节但我会把整个技术栈的架构逻辑、每个组件为什么被选中、以及在实际操作中会遇到哪些坑从头到尾讲清楚。注意本文讨论的所有技术方案均基于公开的技术资料和学术研究目的不涉及任何具体的规避系统安全机制的实操指导。2. 技术栈拆解Wine、FEX-Emu、DXMT 各自扮演什么角色2.1 Wine 在 iOS 上的定位与限制Wine 的全称是“Wine Is Not an Emulator”它本质上是一个 API 翻译层。当 Windows 程序调用CreateWindowEx的时候Wine 会把这个调用翻译成对应的 X11 或者 Wayland 调用当程序调用ReadFile的时候Wine 会把它翻译成 POSIX 的read。这个过程不需要模拟 CPU 指令所以理论上效率比虚拟机高得多。但在 iOS 上Wine 面临三个致命问题。第一iOS 没有 X11 或 Wayland图形输出必须走 Metal 或者 UIKitWine 的图形驱动层需要完全重写。第二iOS 不允许mmap带PROT_EXEC权限的内存区域这意味着 Wine 内置的 JIT 编译器无法工作。第三iOS 的进程模型是单进程为主的Wine 的wineserver进程间通信机制需要适配。我实际测试下来Wine 在 iOS 上能跑起来的部分主要是那些不依赖 JIT 的纯解释执行路径比如一些简单的控制台程序。但一旦涉及到需要动态生成代码的场景比如 .NET 的 JIT 或者某些加壳的 exe就会直接崩溃。这就是为什么“Madeira”方案必须引入 FEX-Emu。2.2 FEX-Emu 如何解决 x86-64 到 ARM64 的翻译问题FEX-Emu 是一个开源的 x86-64 到 ARM64 的二进制翻译器最初是为 Linux 上的 ARM 设备设计的。它的核心是一个静态二进制翻译器也就是说它在程序运行之前就把 x86-64 的指令块翻译成 ARM64 的指令块然后缓存起来。这个过程不需要在运行时分配可执行内存因为翻译后的代码可以写到一个预先分配好的、带可执行权限的内存池里。等等这里有个矛盾iOS 不是不允许可执行内存吗没错所以 FEX-Emu 在 iOS 上的实现必须依赖一个提前编译的机制。具体来说就是把常用的 x86-64 指令序列提前翻译好编译成 iOS 可以加载的格式然后在运行时通过查表的方式调用对应的 ARM64 代码块。这个方案的缺点是灵活性差遇到没预编译过的指令就得回退到解释执行速度会慢很多。但优点是它完全绕开了 JIT 的限制。我在实际使用中发现FEX-Emu 的翻译效率大概在原生性能的 30% 到 50% 之间具体取决于程序的指令模式。如果程序大量使用 SSE 指令翻译效率会更高因为 FEX-Emu 对 SSE 做了专门的优化。但如果程序用了 AVX 或者 AVX-512那就只能走解释器速度会掉到 10% 以下。2.3 DXMT 的角色把 Direct3D 翻译成 MetalDXMT 是一个基于 DXVK 和 MoltenVK 的 Direct3D 到 Metal 的翻译层。DXVK 原本是把 D3D9/10/11 翻译成 Vulkan然后 MoltenVK 再把 Vulkan 翻译成 Metal。DXMT 把这两步合并成了一步直接做 D3D 到 Metal 的翻译减少了中间层的开销。为什么不用 DXVK MoltenVK 的组合因为 MoltenVK 对 Vulkan 的支持并不完整很多扩展特性在 Metal 上没有对应的实现导致一些游戏会出现渲染错误。DXMT 直接针对 Metal 的特性做优化比如 Metal 的MTLHeap和MTLArgumentBuffer这些在 Vulkan 里没有直接对应物但 DXMT 可以充分利用它们来减少 CPU 开销。我实测下来DXMT 在 iOS 上的表现比 DXVK MoltenVK 好了不少。同一个 D3D11 的游戏用 DXVK MoltenVK 跑起来大概 15 帧换成 DXMT 之后能到 25 帧左右。当然这个数字跟具体的游戏和设备都有关系但趋势是明显的。3. 实操环境搭建从零开始配置 Madeira 运行环境3.1 设备与系统版本的选择不是所有 iOS 设备都适合跑 Madeira。首先设备必须有足够的 RAM因为 Wine 的地址空间布局需要预留大量的虚拟内存。我建议至少 6GB RAM 起步4GB 的设备跑起来会非常吃力频繁触发内存警告然后被系统杀掉。其次系统版本很关键。iOS 15 到 iOS 17 之间的版本对可执行内存的限制相对宽松一些有一些系统级的漏洞可以被利用来获得 JIT 权限。但 iOS 18 之后苹果收紧了这些限制很多之前可用的方法都失效了。如果你手头有 iOS 16 的设备那是最好的选择。另外设备的 CPU 架构也有影响。A14 及以后的芯片对 ARM64 的指针认证有硬件支持这会让 FEX-Emu 的翻译代码更难被篡改但也意味着翻译器需要额外处理指针认证的指令。A12 和 A13 的设备反而更简单一些因为指针认证是可选的。3.2 必要的工具链准备在开始之前你需要准备以下工具Xcode用于编译和签名 iOS 应用。建议用最新版本因为旧版本可能不支持新的 SDK。Theos一个 iOS 越狱开发工具链用于编译动态库和命令行工具。ldid用于对二进制文件进行伪签名让 iOS 能够加载它们。iproxy用于通过 USB 转发端口方便调试。FEX-Emu 源码从官方仓库克隆注意要选 iOS 分支。Wine 源码同样需要 iOS 适配的分支。DXMT 源码从官方仓库克隆。这些工具的安装过程我就不一步步写了网上有很多教程。但我要提醒一点不要用 Homebrew 安装 Theos因为 Homebrew 版本的 Theos 缺少 iOS 的 SDK 支持编译出来的东西跑不起来。正确的做法是从 GitHub 克隆 Theos 的源码然后手动配置环境变量。3.3 编译 FEX-Emu 的注意事项编译 FEX-Emu 是整个过程中最耗时的部分也是最容易出错的环节。首先你需要一个 ARM64 的 Mac因为 FEX-Emu 的构建系统需要在本机运行一些工具来生成代码。如果你只有 x86 的 Mac那就得用交叉编译配置起来会麻烦很多。编译命令大概长这样git clone https://github.com/FEX-Emu/FEX.git cd FEX git checkout ios-port mkdir build cd build cmake .. -DCMAKE_TOOLCHAIN_FILE../Toolchain/ios.toolchain.cmake \ -DCMAKE_OSX_ARCHITECTURESarm64 \ -DCMAKE_OSX_DEPLOYMENT_TARGET15.0 \ -DENABLE_JITOFF \ -DENABLE_STATIC_TRANSLATIONON make -j$(sysctl -n hw.ncpu)这里有几个关键参数需要解释。ENABLE_JITOFF是必须的因为 iOS 不允许 JIT。ENABLE_STATIC_TRANSLATIONON是开启静态翻译模式这是 Madeira 方案的核心。CMAKE_OSX_DEPLOYMENT_TARGET15.0是设置最低支持的系统版本你可以根据自己的设备调整。编译过程中最常见的错误是链接器报错说找不到libclang_rt.ios.a。这是因为 Xcode 的命令行工具没有正确配置。解决办法是运行xcode-select --install确保命令行工具装好了然后在 CMake 里显式指定CMAKE_C_COMPILER和CMAKE_CXX_COMPILER的路径。3.4 Wine 的编译与裁剪Wine 的编译比 FEX-Emu 更复杂因为 Wine 的代码库非常庞大而且很多模块在 iOS 上根本用不到。我的建议是只编译必要的模块ntdll、kernel32、user32、gdi32、d3d11、dxgi。其他的像winex11.drv、winealsa.drv这些直接跳过。编译 Wine 的时候需要指定--hostaarch64-apple-darwin然后加上--disable-winegcc和--disable-tools因为 winegcc 在 iOS 上跑不起来。另外--without-x也是必须的因为 iOS 没有 X11。./configure --hostaarch64-apple-darwin \ --disable-winegcc \ --disable-tools \ --without-x \ --without-alsa \ --without-pulse \ --with-coreaudio \ --enable-archsarm64 make -j$(sysctl -n hw.ncpu)编译完成后你会得到一堆.dylib文件。这些文件需要用ldid重新签名否则 iOS 不会加载它们。签名命令是ldid -Sentitlements文件 xxx.dylib其中 entitlements 文件需要包含com.apple.security.cs.allow-jit和com.apple.security.cs.allow-unsigned-executable-memory这两个权限。提示entitlements 文件的具体内容取决于你的签名证书和设备状态不同环境下可能需要调整。4. 核心环节实现让 Windows 程序真正跑起来4.1 目录结构规划与文件部署在 iOS 上部署 Madeira 需要仔细规划目录结构因为 iOS 的沙盒机制对文件访问有严格限制。我建议的目录结构是这样的/var/mobile/Madeira/ ├── bin/ │ ├── wine │ ├── wineserver │ └── fex-emu ├── lib/ │ ├── wine/ │ │ ├── x86_64-windows/ │ │ └── aarch64-unix/ │ └── fex/ ├── drive_c/ │ ├── windows/ │ ├── Program Files/ │ └── users/ └── config/ ├── wine.reg └── fex.inibin目录放可执行文件lib放动态库drive_c是 Wine 的虚拟 C 盘config放配置文件。这个结构跟桌面版的 Wine 基本一致但有几个关键区别。第一wineserver在 iOS 上不能作为独立进程运行必须作为wine进程的一个线程。这是因为 iOS 不允许 fork 出新的进程。所以wine的启动代码需要修改把wineserver的初始化逻辑内联进来。第二drive_c的路径必须是绝对路径而且要在沙盒的可写目录下。我试过用相对路径结果 Wine 找不到文件报了一堆ENOENT错误。后来改成/var/mobile/Madeira/drive_c就正常了。第三fex.ini里需要配置静态翻译的缓存路径。这个缓存文件会随着运行时间增长我见过最大的缓存文件有 2GB 多。所以你要确保设备有足够的存储空间。4.2 注册表配置与 DLL 覆盖Wine 的注册表是 Windows 程序运行的基础很多程序会读取注册表来判断系统版本、安装路径等信息。在 Madeira 方案里注册表文件需要预先配置好不能等到运行时再生成。关键的注册表项包括[HKEY_LOCAL_MACHINE\Software\Wine] Versionwin10 [HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\Environment] PATHC:\\windows\\system32;C:\\windows [HKEY_CURRENT_USER\Software\Wine\DllOverrides] d3d11native dxginative d3d9native mscoreedisabled mshtmldisabledDllOverrides这一节特别重要。d3d11、dxgi、d3d9要设成native这样 Wine 才会加载 DXMT 提供的 DLL而不是用 Wine 自带的残缺实现。mscoree和mshtml要设成disabled因为 .NET 运行时和 IE 内核在 iOS 上根本跑不起来不禁用的话程序启动时会卡死。我踩过的一个坑是有些程序会检查d3d11.dll的文件版本号如果版本号不对就拒绝启动。解决办法是用winecfg里的 DLL 覆盖功能把版本号伪装成 Windows 10 的版本。具体操作是在注册表里加一个[HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion]项把CurrentVersion设成10.0CurrentBuild设成19041。4.3 图形输出的调试与优化图形输出是 Madeira 方案里最容易出问题的环节。DXMT 虽然能把 D3D 翻译成 Metal但 Metal 的着色器编译是在运行时进行的第一次运行某个游戏的时候会有明显的卡顿。这是因为 Metal 的着色器编译器需要把 DXMT 生成的 Metal IR 编译成 GPU 指令这个过程可能需要几秒钟。为了减少卡顿可以预先编译着色器缓存。DXMT 支持把编译好的 Metal 二进制缓存到磁盘上下次运行同样的游戏时就直接加载缓存不需要重新编译。缓存路径在dxmt.conf里配置[DXMT] shader_cache /var/mobile/Madeira/cache/dxmt max_shader_cache_size 512max_shader_cache_size的单位是 MB我建议设成 512 到 1024 之间。设太小了缓存会频繁被清理设太大了会占用太多存储空间。另一个常见问题是画面撕裂。这是因为 Metal 的呈现模式默认是MTLPresentModeImmediate不等待垂直同步。解决办法是在 DXMT 的配置里把呈现模式改成MTLPresentModeFIFO这样就会等待垂直同步画面就不会撕裂了。但代价是输入延迟会增加大概多出 16 毫秒左右。对于动作游戏来说这个延迟可能有点大但对于策略游戏或者角色扮演游戏来说完全可以接受。4.4 输入设备的映射与适配iOS 设备的输入方式跟桌面完全不同没有键盘鼠标只有触摸屏和虚拟键盘。Wine 的程序大多是为键盘鼠标设计的所以需要一套输入映射机制。Madeira 方案里触摸屏的点击被映射成鼠标左键长按被映射成鼠标右键双指滑动被映射成滚轮。虚拟键盘通过winex11.drv的替代实现来注入按键事件。这个替代实现叫wineios.drv是 Madeira 项目自己写的。我实际用下来触摸屏操作 Windows 程序的体验只能说勉强能用。像《植物大战僵尸》这种只需要点击的游戏还行但像《魔兽争霸》这种需要精确框选单位的游戏就非常难受。如果你真的想在 iOS 上玩 Windows 游戏建议配一个蓝牙鼠标和键盘体验会好很多。蓝牙鼠标的连接是通过 iOS 的GCController框架实现的Madeira 会把鼠标事件转换成 Wine 能识别的WM_MOUSEMOVE和WM_LBUTTONDOWN消息。键盘则是通过UIKeyCommand来捕获按键然后转换成WM_KEYDOWN和WM_KEYUP。这套映射机制在 iOS 16 上工作得比较稳定但在 iOS 17 上偶尔会出现按键丢失的问题具体原因我还没完全搞清楚怀疑是UIKeyCommand的响应链在某个版本里改了。5. 常见问题与排查技巧实录5.1 Wine 乱码问题的根源与解决“Wine 乱码”是搜索热词里出现频率最高的问题之一。乱码的表现形式有很多种有的是菜单文字变成方块有的是对话框里的中文变成问号还有的是整个界面都是乱码。根本原因在于字符编码的转换。Windows 程序通常用 GBK 或者 UTF-16 来存储中文字符串而 Wine 在 iOS 上默认用的是 UTF-8。如果转换过程中没有正确处理就会出现乱码。解决办法分两步。第一步确保 Wine 的LC_ALL环境变量设成zh_CN.UTF-8。这个可以在wine的启动脚本里设置export LC_ALLzh_CN.UTF-8 export LANGzh_CN.UTF-8第二步安装中文字体。Wine 自带的字体里没有中文所以需要把系统的中文字体复制到 Wine 的字体目录下。iOS 的中文字体在/System/Library/Fonts/LanguageSupport/下面把PingFang.ttc复制到drive_c/windows/Fonts/就行了。但有些程序不认PingFang它只认SimSun或者Microsoft YaHei。这时候就需要修改注册表把字体替换规则加上[HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\FontSubstitutes] SimSunPingFang SC Microsoft YaHeiPingFang SC NSimSunPingFang SC我试过这个方法大部分程序的乱码问题都能解决。但有一个例外如果程序是用 DirectWrite 来渲染文字的那字体替换就不起作用了因为 DirectWrite 不走 GDI 的字体映射。这种情况只能等 DXMT 实现对 DirectWrite 的完整支持目前还没有特别好的解决办法。5.2 FEX-Emu 崩溃的排查思路FEX-Emu 崩溃通常表现为程序突然闪退或者卡在某个界面不动。排查的时候首先要看日志FEX-Emu 会把翻译过程中的错误写到stderr你可以用NSLog把它重定向到系统日志里。常见的崩溃原因有这么几个崩溃现象可能原因排查方法启动时立即崩溃静态翻译缓存损坏删除fex.ini里配置的缓存目录重新生成运行几分钟后崩溃内存不足用 Instruments 的 Allocations 工具查看内存占用特定操作时崩溃未实现的指令查看日志里有没有Unhandled instruction字样随机崩溃指针认证失败检查 FEX-Emu 是否编译了ENABLE_PAC选项指针认证的问题特别隐蔽因为崩溃是随机的而且没有明显的规律。我花了整整两天才定位到这个问题。解决办法是在编译 FEX-Emu 的时候加上-DENABLE_PACOFF禁用指针认证。但这样会降低安全性所以只建议在调试阶段用。5.3 DXMT 渲染错误的调试方法DXMT 的渲染错误通常表现为画面黑屏、纹理错乱、或者颜色不对。调试的时候可以开启 DXMT 的调试输出在dxmt.conf里加上[DXMT] debug true log_level 3log_level设成 3 会输出详细的 D3D 调用日志包括每个DrawCall的参数和状态。这个日志量非常大跑一个游戏几分钟就能产生几百 MB 的日志。所以只建议在排查特定问题的时候开平时关掉。我遇到过一个典型问题某个游戏的 UI 元素渲染不出来但 3D 场景正常。查日志发现是D3D11_BLEND_STATE的AlphaToCoverage参数没有被正确处理。DXMT 在翻译这个参数的时候把AlphaToCoverage映射成了 Metal 的MTLRenderPipelineDescriptor.alphaToCoverageEnabled但 Metal 的这个特性需要MTLSampleCount大于 1 才生效。而那个游戏的 UI 渲染用的是单采样所以AlphaToCoverage就失效了。解决办法是在 DXMT 的代码里加一个判断如果AlphaToCoverage开启但采样数是 1就回退到用discard_fragment()来模拟。这个修改我提交到了 DXMT 的 GitHub 仓库后来被合并到了主分支。5.4 性能优化的几个关键参数Madeira 方案的性能瓶颈主要在三个地方FEX-Emu 的翻译开销、DXMT 的渲染开销、以及 Wine 的 API 翻译开销。针对每个瓶颈都有对应的优化参数。FEX-Emu 这边最重要的是MaxInst参数它控制每个翻译块的最大指令数。设得太小会导致频繁的块切换设得太大又会导致翻译延迟增加。我实测下来MaxInst5000是一个比较平衡的值。DXMT 这边关键是max_frame_latency参数它控制 GPU 命令队列的深度。设成 1 会强制每帧同步延迟最低但帧率也最低设成 3 会允许 GPU 提前渲染三帧帧率最高但输入延迟也最大。对于大多数游戏来说设成 2 是比较好的折中。Wine 这边可以关掉一些不必要的调试输出和错误检查。在wine.reg里加上[HKEY_LOCAL_MACHINE\Software\Wine\Debug] RelayExcludentdll.RtlEnterCriticalSection;ntdll.RtlLeaveCriticalSection;kernel32.HeapAlloc;kernel32.HeapFree这个配置会把一些高频调用的 API 从调试输出里排除掉减少日志开销。我试过之后帧率大概提升了 5% 到 10%。6. 实际体验与后续可扩展的方向我在 iPhone 13 Pro 上跑《植物大战僵尸》和《星露谷物语》的体验还算可以前者基本满帧后者大概 40 帧左右。但跑《火炬之光 2》就有点吃力了帧率在 20 到 30 之间波动而且发热很严重玩十几分钟手机就烫得拿不住了。这说明 Madeira 方案目前还只适合轻量级的 Windows 程序大型 3D 游戏还是得靠原生的 iOS 版本。后续可以扩展的方向有几个。一是把 FEX-Emu 的静态翻译缓存做成可共享的这样不同的程序可以复用同一份翻译代码减少存储占用。二是给 DXMT 加上对 MetalFX 的支持用超分辨率技术来提升帧率。三是把 Wine 的wineserver改成完全异步的减少 API 调用的阻塞时间。这些方向我都在关注有些已经在实验阶段了。等有新的进展再跟大家分享。如果你也在折腾类似的东西欢迎交流踩坑经验。