1. 项目缘起为什么要在 iOS 上折腾 Wine 兼容层“Madeira” 这个项目标题乍一看像是个地名但在我们这群喜欢在移动端折腾 Windows 应用的人眼里它代表的是一个非常具体的尝试在 iOS 设备上借助 Wine 及其衍生方案跑起 x86-64 架构的 Windows 程序。你没看错不是远程桌面不是云电脑而是本地兼容层。这件事的难度大概相当于让一个只吃西餐的厨师去做满汉全席食材和厨具都得自己想办法造。先把这个项目的核心关键词拆开看Wine、FEX-Emu、DXMT、iOS、x86-64。Wine 负责把 Windows 的 API 调用翻译成 POSIX 调用这是整个兼容层的基石FEX-Emu 负责把 x86-64 指令翻译成 ARM64 指令因为 iOS 设备清一色是 ARM 架构DXMT 则是把 Direct3D 调用翻译成 Metal让游戏和图形程序能利用苹果的图形接口。这三者叠在一起才勉强凑出一个能跑 Windows 程序的“三明治”结构。那为什么偏偏是 iOS因为 iOS 设备性能足够强M 系列芯片的 iPad 甚至 Mac 都能提供接近桌面级的算力而且 Metal 图形接口的效率在移动端首屈一指。但 iOS 的封闭性也是出了名的没有 JIT 权限沙盒限制严格后台进程随时可能被干掉。所以这个项目的核心矛盾就是如何在苹果划定的牢笼里搭出一个能跑 Windows 程序的舞台。适合谁来参考如果你是对兼容层技术好奇的开发者、想在 iPad 上跑老 Windows 游戏或工具的极客或者单纯想理解 Wine 生态在非 x86 平台上的演进路径那这篇内容应该能给你不少可复用的思路。2. 核心组件拆解Wine、FEX-Emu、DXMT 各自扮演什么角色2.1 Wine 不是模拟器它是翻译官很多人第一次听到 Wine 会以为它是虚拟机或模拟器其实它的全称是 “Wine Is Not an Emulator”。它做的事情是在运行时把 Windows 的系统调用动态翻译成宿主系统的调用。比如 Windows 程序调用CreateFileWine 会把它映射到 Linux 或 macOS 的open系统调用上。这种翻译是 API 级别的不是指令级别的所以效率比全指令模拟高得多。但在 iOS 上Wine 面临两个致命问题。第一iOS 没有fork和exec的自由Wine 启动 Windows 程序时依赖的进程创建机制需要绕路。第二iOS 的沙盒不允许程序随意加载动态库而 Wine 需要加载大量的.so或.dylib来实现 Windows API。所以 Madeira 项目里Wine 的移植版本必须重新实现一套轻量级的进程管理和库加载逻辑通常的做法是把所有依赖静态链接进主二进制或者利用 iOS 的dlopen在沙盒内允许的路径下加载。注意Wine 的版本选择非常关键。开发版wine-devel虽然功能新但 API 变动频繁在 iOS 这种需要大量补丁的环境下建议锁定一个稳定分支如 wine-8.0.x 或 9.0.x然后只 cherry-pick 必要的修复补丁。2.2 FEX-Emu让 x86-64 指令在 ARM 上跑起来FEX-Emu 是一个用户态的 x86-64 到 ARM64 的二进制翻译器。它的工作方式和苹果自家的 Rosetta 2 类似但 Rosetta 2 只允许在 macOS 上使用iOS 上根本没有。FEX-Emu 的核心是一个动态二进制翻译引擎它把 x86-64 的指令块翻译成 ARM64 指令块然后缓存起来重复使用。这样第一次执行某段代码时会慢但后续调用就快很多。在 Madeira 项目里FEX-Emu 需要解决几个 iOS 特有的问题。首先是内存权限JIT 编译需要可写可执行的内存页但 iOS 默认禁止mmap带PROT_EXEC的匿名映射。常见的绕过方案是利用mprotect在已分配的内存上动态切换权限或者使用苹果提供的MAP_JIT标志但需要特定的 entitlement。其次是信号处理FEX-Emu 依赖 SIGSEGV 来捕获翻译过程中的异常而 iOS 的信号处理机制和 Linux 有差异需要额外适配。实测下来FEX-Emu 在 A15 及以上芯片的 iOS 设备上翻译效率大约能到原生 ARM64 的 40% 到 60%具体取决于代码的指令密度。对于办公类应用如记事本、计算器完全够用但对于大型 3D 游戏帧率会明显吃紧。2.3 DXMT把 Direct3D 接到 Metal 上DXMT 是“DirectX Metal Translation”的缩写它的任务是把 Windows 程序发出的 Direct3D 11 或 12 调用转换成 Metal 调用。为什么不用 DXVK因为 DXVK 依赖 Vulkan而 iOS 没有原生 Vulkan 驱动MoltenVK 虽然能把 Vulkan 转到 Metal但多一层转换就多一层开销。DXMT 直接对接 Metal路径更短延迟更低。在 Madeira 的架构里DXMT 通常以 Wine 的图形驱动形式存在。Wine 加载d3d11.dll时实际加载的是 DXMT 的实现然后 DXMT 内部调用 Metal 的MTLDevice、MTLCommandQueue等接口。这里的关键难点是资源同步Direct3D 的纹理和缓冲区需要映射到 Metal 的MTLTexture和MTLBuffer而两者的内存布局和同步语义不完全一致。DXMT 需要维护一个资源映射表并在每次 DrawCall 前确保数据一致性。提示如果你在 iOS 上跑 DXMT建议优先使用 Metal 2 或 Metal 3 的特性比如MTLHeap和MTLResourceStorageModePrivate能显著减少内存拷贝开销。但要注意老设备A12 以下可能不支持某些特性需要做能力检测和降级。3. 在 iOS 上落地 Madeira 的实操路径3.1 环境准备从 Xcode 到开发者模式要在 iOS 上跑 Madeira你首先需要一个能编译和部署 iOS 应用的开发环境。Xcode 是必须的版本建议 15.0 以上因为需要较新的 iOS SDK 来支持 Metal 3 和相关的 entitlement。然后你需要一台 iOS 设备最好是 iPad Pro 或 iPhone 15 Pro 及以上因为内存越大能分配给 Wine 进程的空间就越多。开发者模式是绕不开的一步。iOS 16 以后开发者模式默认关闭需要在“设置 - 隐私与安全性 - 开发者模式”里手动打开然后重启设备。如果你用的是 iOS 26.3.1 这种较新的版本开发者模式的入口可能更深有时需要先连接 Xcode 一次才会出现。这一步的坑在于开启开发者模式后设备的安全性会降低部分银行类 App 可能会检测并拒绝运行。所以建议用备用机来折腾。接下来是签名和证书。免费证书Free Provisioning只能让 App 运行 7 天过期后需要重新签名。对于 Madeira 这种需要长期调试的项目建议用付费开发者账号99 美元/年生成稳定的开发证书和描述文件。Xcode 从证书配置到上架的全流程这里不展开但核心是在 Target 的 Signing Capabilities 里确保 Bundle Identifier 唯一并且勾选了正确的 Team。3.2 编译 Wine 和 FEX-Emu 的 iOS 版本Wine 官方并不支持 iOS所以你需要自己打补丁。社区里有一些现成的移植仓库但更新频率不一。我的做法是从 Wine 的稳定分支拉代码然后应用三个关键补丁。第一个是进程创建补丁把forkexec替换成posix_spawn的变体并限制子进程的数量。第二个是文件系统重定向补丁把 Windows 的C:\映射到 iOS 沙盒的Documents目录下。第三个是动态库加载补丁修改dlopen的搜索路径只允许加载 App Bundle 内的库。FEX-Emu 的编译相对直接但需要打开JIT相关的编译选项。在 CMake 里设置-DENABLE_JITON和-DCMAKE_OSX_ARCHITECTURESarm64。编译完成后你会得到一个libFEXCore.so和一个FEXLoader可执行文件。在 iOS 上FEXLoader不能直接运行需要把它嵌入到主 App 的二进制里通过posix_spawn或者直接函数调用的方式启动。DXMT 的编译依赖 Metal 框架所以必须在 macOS 上完成。它的构建系统基于 Meson你需要指定--cross-file为 iOS 的交叉编译配置。编译产物是一个libdxmt.dylib把它放到 Wine 的lib/wine/x86_64-windows/目录下并修改 Wine 的注册表让d3d11指向 DXMT。3.3 配置 Wine 前缀和运行第一个 Windows 程序Wine 前缀prefix是 Wine 模拟的 Windows 环境通常包含drive_c、注册表文件和系统库。在 iOS 上前缀的路径需要设置在 App 的沙盒内比如~/Documents/Madeira/prefix。初始化前缀的命令是WINEPREFIX~/Documents/Madeira/prefix wineboot -u但 iOS 上没有wineboot这个可执行文件你需要把wineboot的功能集成到主 App 里通过调用 Wine 的内部函数来完成初始化。初始化完成后你可以尝试运行一个简单的 Windows 程序比如notepad.exeWINEPREFIX~/Documents/Madeira/prefix wine notepad.exe如果一切顺利你会看到记事本的窗口。但更可能的情况是窗口一闪而过或者直接崩溃。这时候需要看 Wine 的调试输出。在 iOS 上stderr默认被重定向到系统日志你可以用Console.app或者idevicesyslog来查看。常见的错误包括wine: cannot find LC:\\windows\\system32\\kernel32.dll这说明前缀初始化不完整需要重新运行wineboot。实操心得在 iOS 上跑 Wine内存是最大的瓶颈。iOS 对单个 App 的内存占用有硬限制iPhone 上通常是 2GB 到 3GBiPad Pro 能到 4GB 到 6GB。Wine 本身加上 FEX-Emu 的翻译缓存很容易吃掉 1GB 以上。所以建议在Info.plist里打开Increased Memory Limitentitlement并且尽量用轻量级的 Windows 程序做测试。4. 常见问题与排查技巧实录4.1 Wine 乱码问题从字体到编码的完整排查“wine 乱码”是搜索热词里出现频率最高的。在 iOS 上乱码通常表现为两种形式菜单栏文字变成方块或者中文显示为问号。前者是字体缺失后者是编码不匹配。字体缺失的解决办法是往 Wine 前缀的drive_c/windows/Fonts目录里拷贝中文字体比如simsun.ttc或NotoSansCJK-Regular.ttc。然后修改注册表把HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\FontSubstitutes里的MS Shell Dlg指向你拷贝的字体。在 iOS 上注册表文件是system.reg你可以用文本编辑器直接修改但要注意编码必须是 UTF-8。编码不匹配的问题更隐蔽。Wine 默认使用 UTF-8 作为内部编码但很多老 Windows 程序用的是 GBK 或 Shift-JIS。解决办法是在winecfg里把Locale设置为zh_CN.UTF-8并且在启动程序时加上LANGzh_CN.UTF-8环境变量。如果还是乱码可以尝试用wine reg add命令修改HKEY_CURRENT_USER\Control Panel\International里的sLanguage为zh_CN。注意iOS 的沙盒不允许 Wine 直接访问系统字体所以你不能指望 Wine 自动找到 iOS 自带的中文字体。必须手动把字体文件打包进 App Bundle然后在初始化前缀时拷贝过去。4.2 FEX-Emu 崩溃JIT 权限与信号处理的坑FEX-Emu 在 iOS 上崩溃十有八九和 JIT 权限有关。iOS 默认不允许mmap带PROT_EXEC的匿名内存所以 FEX-Emu 的 JIT 缓存分配会失败。常见的错误日志是Failed to allocate JIT buffer或mprotect failed with errno 1。解决办法有两个。第一个是使用MAP_JIT标志但这需要com.apple.security.cs.allow-jitentitlement而且只在 macOS 上有效iOS 上即使有 entitlement 也可能被拒绝。第二个是预分配一大块可读写内存然后在需要执行时用mprotect临时加上PROT_EXEC。具体做法是在 App 启动时mmap一块 256MB 的内存权限设为PROT_READ | PROT_WRITE。当 FEX-Emu 需要执行翻译后的代码时调用mprotect把对应页设为PROT_READ | PROT_EXEC执行完再切回来。这种切换有性能开销但实测在 A15 上每秒钟可以切换上万次对大多数程序够用。信号处理的问题更棘手。FEX-Emu 依赖 SIGSEGV 来捕获未翻译的指令但 iOS 的 SIGSEGV 处理函数不能返回否则会触发EXC_BAD_ACCESS并杀死进程。所以 FEX-Emu 的 iOS 移植版必须把 SIGSEGV 处理逻辑改成siglongjmp跳转而不是正常返回。这个改动在 FEX-Emu 的源码里位于Source/Tools/FEXLoader/LinuxSyscalls/SignalDelegator.cpp需要仔细调整。4.3 DXMT 图形问题黑屏、花屏与性能优化DXMT 在 iOS 上最常见的症状是黑屏。程序启动了窗口也出来了但内容区域一片漆黑。这通常是 Metal 的CAMetalLayer没有正确配置。你需要确保CAMetalLayer的device属性指向正确的MTLDevicepixelFormat设置为MTLPixelFormatBGRA8Unorm并且framebufferOnly设为NO因为 DXMT 可能需要从纹理回读数据。花屏问题通常和纹理格式有关。Direct3D 的DXGI_FORMAT_B8G8R8A8_UNORM在 Metal 里对应MTLPixelFormatBGRA8Unorm但两者的通道顺序可能相反。DXMT 内部有一个格式映射表如果映射错了红色和蓝色会互换看起来就是花屏。解决办法是检查DXMT的d3d11_texture.c里的格式转换逻辑确保DXGI_FORMAT到MTLPixelFormat的映射正确。性能优化方面最有效的手段是减少 CPU 和 GPU 之间的同步。DXMT 默认会在每次 DrawCall 后等待 GPU 完成这在 iOS 上会导致严重的卡顿。你可以修改 DXMT 的MTLCommandBuffer提交策略改成每帧提交一次而不是每次 DrawCall 都提交。具体是在dxmt_command_queue.c里把commit调用从draw函数里移到present函数里。实测这个改动能让帧率提升 30% 以上。问题现象可能原因排查方法解决措施Wine 菜单乱码字体缺失检查drive_c/windows/Fonts目录拷贝中文字体并修改注册表FEX-Emu 崩溃JIT 权限不足查看日志是否有mprotect failed预分配内存并动态切换权限DXMT 黑屏Metal Layer 配置错误检查CAMetalLayer属性设置正确的device和pixelFormat程序启动即退出前缀初始化不完整查看wineboot输出重新运行wineboot -u中文显示为问号编码不匹配检查LANG环境变量设置为zh_CN.UTF-85. 从 Madeira 延伸iOS 兼容层的未来与替代方案5.1 为什么 iOS 上的 Wine 生态如此碎片化Madeira 项目并不是孤例。社区里还有“麒麟 Wine 助手”、“统信 Wine Windows 兼容组件”等类似尝试但它们大多面向 Linux 桌面环境真正在 iOS 上落地的少之又少。原因在于 iOS 的封闭性导致每个项目都需要重新解决 JIT 权限、沙盒限制、签名机制这三大难题。而且苹果随时可能通过系统更新封堵漏洞比如 iOS 26.3.1 就收紧了mprotect的权限检查导致一些老版本的 FEX-Emu 直接无法运行。这种碎片化也意味着没有一劳永逸的解决方案。你今天编译好的 Wine 和 FEX-Emu可能在下一次 iOS 更新后就失效了。所以 Madeira 项目的价值不在于提供一个稳定的产品而在于探索一条技术路径积累一套可复用的补丁和配置。5.2 替代方案远程桌面与云游戏如果你只是想在 iOS 上跑 Windows 程序而不执着于本地兼容层那远程桌面是更务实的选择。微软的 Remote Desktop、Parsec、Moonlight 都能把 Windows 桌面的画面串流到 iOS 设备上延迟可以做到 20ms 以内而且不依赖本地算力。云游戏平台如 GeForce Now 也是类似思路把渲染放在云端iOS 只负责解码和显示。但远程方案的缺点也很明显必须有稳定的网络连接而且无法离线使用。对于需要本地 USB 设备或低延迟输入的场景比如某些工业软件或音乐制作工具远程方案就不太合适了。所以 Madeira 这类本地兼容层项目仍然有它不可替代的价值。5.3 给后来者的建议从最小可行产品开始如果你也想在 iOS 上折腾 Wine 兼容层我的建议是不要一上来就追求跑 3D 游戏。先从最简单的 Windows 控制台程序开始比如hello.exe确保 Wine 的进程创建和标准输出重定向能正常工作。然后逐步增加复杂度先跑记事本再跑计算器最后再尝试 Direct3D 程序。每通过一个阶段就记录下需要的补丁和配置形成自己的知识库。另外多关注 FEX-Emu 和 DXMT 的官方仓库它们的更新频率比 Wine 的 iOS 移植版高得多。很多时候你遇到的问题在最新提交里已经修复了只是还没发布正式版。学会从 Git 历史里找补丁比在论坛里等答案效率高得多。最后分享一个小技巧在 iOS 上调试 Wine 时可以把WINEDEBUG环境变量设为all这样会输出非常详细的日志。但日志量巨大建议配合grep过滤关键字比如WINEDEBUGall wine notepad.exe 21 | grep -i error。这样能快速定位到出错的模块比盲目翻日志快得多。这个方向后续还可以这样扩展把 Madeira 的构建流程脚本化用 GitHub Actions 自动编译出 IPA 包这样每次 Wine 或 FEX-Emu 更新时你只需要点一下按钮就能得到新的测试版本。我自己试过用 Fastlane 配合 Xcode 的xcodebuild命令能把整个编译和打包过程压缩到 15 分钟以内省去了大量手动操作的时间。