1. 项目缘起为什么要在 iOS 上折腾 Wine第一次看到 “Madeira” 这个代号很多人会以为是某个度假海岛或者一款小众红酒品牌。但在我们这群喜欢在移动设备上折腾桌面应用的人眼里Madeira 代表的是一个相当硬核的方向把 Wine 的 Windows 兼容层能力通过 FEX-Emu 和 DXMT 这套组合拳搬到 iOS 设备上运行 x86-64 的 Windows 程序。这件事听起来像是天方夜谭毕竟 iOS 的沙盒机制、签名限制、图形接口封闭程度每一条都足以让传统模拟器方案胎死腹中。但 Madeira 这个项目偏偏就在这些夹缝里找到了出路而且实测下来部分老游戏和工具软件已经能跑到可用的程度。我接触这个项目大概是在它刚放出早期构建版本的时候。当时社区里讨论最多的就是“iOS 上到底能不能跑 exe”这个问题有人说用远程串流不香吗有人说直接买台 Windows 掌机不就完了。但折腾过的人都知道串流依赖网络质量掌机又是另一笔开销而 Madeira 的思路是让 iPhone 或者 iPad 本身变成一台能直接执行 x86-64 Windows 二进制文件的设备。它解决的核心痛点很明确你手里已经有一台性能过剩的 iOS 设备你想让它干点“份外之事”比如跑一个只有 Windows 版的老式财务软件、一个十几年前的经典游戏、或者某个特定行业的单机工具。适合看这篇内容的人我大致分成三类。第一类是喜欢在移动端折腾模拟器和兼容层的玩家对 Wine、Box86、FEX-Emu 这些名字不陌生想了解它们在 iOS 上怎么协同工作。第二类是开发者或者运维人员手头有 iOS 设备想测试一些跨平台的兼容性方案或者单纯对 ARM 转译 x86 的技术路径感兴趣。第三类就是普通用户可能被“iOS 跑 Windows 程序”这个噱头吸引过来想看看现在到底能做到什么程度值不值得花时间尝试。不管你是哪一类下面我会把 Madeira 的整体设计、核心组件、实操步骤和踩坑经验都摊开来讲尽量让不同基础的人都能找到自己能用的部分。2. 整体架构拆解Wine、FEX-Emu、DXMT 各自扮演什么角色2.1 三层协作模型从 Windows 系统调用到 iOS 图形接口Madeira 不是一个单一的软件它更像是一套精心编排的流水线。要理解它为什么能在 iOS 上跑起来得先搞清楚这三个核心组件各自负责什么。Wine 大家相对熟悉它的作用是把 Windows 的 API 调用翻译成 POSIX 兼容的系统调用让 exe 文件以为自己运行在 Windows 上。但 Wine 本身不处理 CPU 指令集的差异它假设你的 CPU 能直接执行 x86 指令。问题来了iOS 设备用的是 ARM 架构根本听不懂 x86-64 的机器码。这时候 FEX-Emu 就登场了它是一个用户态的 x86-64 到 ARM64 的动态二进制翻译器专门负责把 x86-64 指令实时转换成 ARM64 指令。你可以把它想象成一个同声传译Windows 程序说一句 x86 方言FEX-Emu 立刻翻译成 ARM 方言给 CPU 听。那 DXMT 又是干什么的Wine 把 Windows 的图形调用翻译成了类 Unix 的图形接口但在 iOS 上苹果只给你 Metal 和 OpenGL ES而且 OpenGL ES 已经标记为废弃。DXMT 是一个基于 Metal 的 Direct3D 翻译层它把 Windows 程序发出的 D3D9、D3D10、D3D11 甚至部分 D3D12 调用直接转换成 Metal 命令。这样一来图形渲染就不用再经过 OpenGL 中转效率提升非常明显。这三者的关系可以这样理解Wine 负责“系统调用翻译”FEX-Emu 负责“指令集翻译”DXMT 负责“图形接口翻译”。三者缺一不可而且它们之间的衔接顺序和内存共享机制直接决定了最终能不能跑起来、跑得顺不顺。2.2 为什么选择 FEX-Emu 而不是其他转译方案在 x86 转 ARM 这个领域其实有好几个可选方案比如 QEMU 的用户态模拟、Box86/Box64 的混合方案还有苹果自家的 Rosetta 2但那是 macOS 上的iOS 根本不让用。Madeira 选择 FEX-Emu 是有充分理由的。QEMU 的用户态模拟虽然兼容性好但性能损耗太大尤其是在 iOS 这种功耗敏感的设备上跑起来发热降频非常严重。Box86/Box64 在 Linux ARM 设备上表现不错但它的设计更偏向于 Linux 系统调用移植到 iOS 的沙盒环境里需要大量改造而且对 64 位 Windows 程序的支持不如 FEX-Emu 成熟。FEX-Emu 的优势在于它专门针对 ARM64 做了大量优化支持 SVE 指令集部分苹果芯片支持并且有一个相当活跃的社区在持续改进翻译效率。更重要的是FEX-Emu 的代码结构比较清晰方便 Madeira 团队把它嵌入到 iOS 的 App 沙盒里。我实测下来同样的一个老游戏用 FEX-Emu 跑起来比用 QEMU 用户态模拟大概快 30% 到 50%而且帧率稳定性好很多。当然FEX-Emu 也不是没有缺点它对某些特定指令集的翻译还不够完美比如一些老程序里用到的 x87 浮点指令偶尔会出现精度问题或者直接崩溃。但总体来说在 iOS 这个受限环境里FEX-Emu 是目前最务实的选择。2.3 DXMT 的图形翻译路径与性能取舍DXMT 这个名字听起来像是 DirectX 和 Metal 的缩写组合实际上它的工作方式比名字复杂得多。Windows 程序调用 D3D 接口创建纹理、着色器、渲染目标DXMT 需要把这些概念一一映射到 Metal 的对应对象上。比如 D3D11 的 Texture2D 要转换成 Metal 的 TextureD3D 的 Shader Model 要转换成 Metal Shading Language。这个转换过程不是简单的 API 映射因为两者的资源管理模型、同步机制、内存布局都有差异。DXMT 的做法是在中间维护一层抽象把 D3D 的状态机模拟出来然后在合适的时机批量提交 Metal 命令。这样做的好处是兼容性比较好很多老游戏不需要修改就能跑起来。代价是性能上会有一定损耗尤其是那些频繁切换渲染状态、大量使用动态缓冲区的程序。我试过用 Madeira 跑一个 D3D9 时代的老 RPG在 iPhone 13 上能稳定在 30 帧左右但遇到大规模粒子特效的场景会掉到 20 帧以下。如果你追求极致性能可以在 DXMT 的配置里调整一些参数比如关闭垂直同步、降低内部渲染分辨率、启用异步着色器编译。这些选项在默认配置里是保守的需要手动改配置文件才能生效。3. 实操环境准备从零开始搭建 Madeira 运行环境3.1 iOS 设备端的前置条件与签名方案在 iOS 上跑 Madeira第一道坎就是签名。苹果不允许未经签名的可执行代码在设备上运行而 Madeira 本身是一个包含 JIT 编译器的应用JIT 在 iOS 上又受到严格限制。目前社区里主要有两种方案一种是使用 TrollStore 这类永久签名工具它利用系统漏洞让应用获得不受限制的签名权限从而允许 JIT 和动态库加载。另一种是使用开发者证书自签但这种方式每 7 天需要重新签名而且 JIT 权限需要额外配置。我建议如果你的设备系统版本支持 TrollStore优先走这条路省心很多。设备方面建议至少是 A12 芯片以上的机型也就是 iPhone XS 及之后的设备。A11 及更早的芯片虽然也能跑但 FEX-Emu 的翻译效率会明显下降而且内存带宽不足会导致频繁卡顿。内存方面3GB 是起步线4GB 以上体验会好很多。存储空间建议预留至少 10GB因为一个完整的 Wine 前缀加上几个程序很容易就吃掉好几个 G。系统版本方面iOS 15 到 iOS 16 的兼容性最好iOS 17 之后由于系统安全策略收紧部分 JIT 相关的接口发生了变化需要等待 Madeira 团队适配。3.2 获取 Madeira 安装包与依赖组件Madeira 的安装包通常以 IPA 格式分发你可以从项目的官方发布渠道获取。注意不要从不明来源下载所谓的“破解版”或者“增强版”那些往往捆绑了恶意代码或者广告 SDK。下载完成后用 TrollStore 或者 AltStore 安装到设备上。安装完成后第一次启动Madeira 会提示你下载额外的依赖组件主要包括 Wine 的运行时库、FEX-Emu 的翻译缓存、以及 DXMT 的 Metal 着色器库。这些组件加起来大概 500MB 到 1GB建议在 Wi-Fi 环境下完成下载。这里有一个容易踩的坑有些朋友安装完 Madeira 后直接去点桌面上的 exe 文件发现毫无反应。这是因为 Wine 前缀还没有初始化。你需要先在 Madeira 的设置里找到“初始化 Wine 前缀”的选项让它创建一个虚拟的 C 盘目录结构。这个过程大概需要一两分钟期间不要切到后台否则可能中断。初始化完成后你会看到类似drive_c的目录这时候再把 exe 文件放进去或者通过 Madeira 的文件导入功能添加。3.3 配置 FEX-Emu 与 DXMT 的关键参数Madeira 默认的配置是偏向兼容性的性能上比较保守。如果你想让游戏或者程序跑得更流畅需要手动调整几个关键参数。在 FEX-Emu 的配置里最重要的是CoreCount和TSOEnabled这两个选项。CoreCount决定了 FEX-Emu 使用多少个线程来做指令翻译默认是 2可以调到 4 或者 6但不要超过设备 CPU 的物理核心数。TSOEnabled是控制内存序模型的开启后兼容性更好但性能略低关闭后性能提升但某些多线程程序可能崩溃。我的建议是先用默认配置跑一遍如果程序能正常运行但帧率不理想再尝试关闭 TSO。DXMT 这边关键参数是MaxFrameLatency和ShaderCacheEnabled。MaxFrameLatency控制 CPU 提前准备多少帧的数据默认是 1调到 2 或者 3 可以缓解卡顿但会增加输入延迟。ShaderCacheEnabled建议保持开启它会把编译过的 Metal 着色器缓存到磁盘上第二次启动同一个程序时加载速度会快很多。另外还有一个ResolutionScale参数默认是 1.0如果你觉得帧率不够可以降到 0.75 或者 0.5画面会模糊一些但流畅度提升明显。这些参数都在 Madeira 的config目录下的fex.ini和dxmt.ini文件里用文本编辑器直接改就行。4. 核心实操流程从安装到跑通第一个 Windows 程序4.1 初始化 Wine 前缀与目录结构说明Wine 前缀是 Wine 用来模拟 Windows 文件系统的目录里面包含了drive_c、windows、Program Files等熟悉的路径。Madeira 在初始化前缀时会创建一套最小化的 Windows 目录结构并且注册一些必要的 DLL 和注册表项。初始化完成后你可以通过 Madeira 内置的文件管理器浏览这个前缀路径通常在应用沙盒的Documents/prefix下面。如果你想手动往里面放文件可以直接把 exe 或者安装包复制到drive_c下的任意目录然后在 Madeira 里用“运行”功能选择该文件。这里有一个细节值得注意Wine 前缀的架构版本要和 FEX-Emu 匹配。Madeira 默认创建的是 64 位前缀也就是支持 x86-64 的 Windows 程序。如果你要跑的是 32 位的老程序需要额外创建一个 32 位前缀或者在 64 位前缀里启用 WoW64 支持。WoW64 是 Windows 的 32 位兼容层Wine 也实现了类似的功能但在 iOS 上由于 FEX-Emu 的翻译机制WoW64 的稳定性不如纯 64 位前缀。我实测下来大部分 32 位程序在 64 位前缀里也能跑但偶尔会遇到 DLL 加载失败的问题这时候就需要单独建一个 32 位前缀来隔离。4.2 安装 Windows 程序直接运行与静默安装两种方式安装 Windows 程序到 Madeira 里有两种常见方式。第一种是直接运行安装包 exe就像在 Windows 上一样一路点“下一步”。这种方式适合大多数标准安装程序比如老游戏的安装向导、办公软件的安装包。但要注意有些安装程序会调用一些 Madeira 尚未完全实现的系统接口比如 Windows Installer 服务、.NET Framework 安装程序等这些可能会卡住或者报错。遇到这种情况可以尝试用第二种方式静默安装。静默安装是指通过命令行参数让安装程序不显示界面直接把文件释放到指定目录。常见的参数有/S、/silent、/quiet等具体取决于安装程序使用的打包工具。比如 NSIS 打包的程序用/SInstallShield 用/s /v/qnInno Setup 用/VERYSILENT。你可以在 Madeira 的“运行”对话框里输入exe路径 /S来执行静默安装。这种方式的好处是绕过了图形界面的兼容性问题而且安装速度通常更快。安装完成后你可以在drive_c的对应目录里找到程序的可执行文件直接运行即可。4.3 图形与音频配置让程序正常显示和发声图形方面Madeira 默认使用 DXMT 作为 D3D 翻译层但有些程序可能更依赖 OpenGL 或者 Vulkan。如果你的程序跑起来黑屏或者花屏可以尝试在 Wine 的注册表里修改渲染后端。具体操作是在 Madeira 的设置里找到“Wine 配置”然后添加一个注册表项HKEY_CURRENT_USER\Software\Wine\Direct3D新建字符串值renderer设置为metal或者gl。metal就是走 DXMTgl是走 OpenGL ES 的兼容路径。我试过几个老游戏用metal渲染帧率更高但有些 2D 游戏用gl反而更稳定。音频方面Wine 默认使用 PulseAudio 或者 ALSA但在 iOS 上这些都不存在。Madeira 内置了一个音频桥接层把 Wine 的音频输出转换成 iOS 的 CoreAudio 接口。大部分情况下音频能正常播放但如果你遇到爆音、延迟或者完全没声音可以检查一下 Madeira 的音频设置里SampleRate和BufferSize这两个参数。SampleRate建议设为 44100 或者 48000和程序内部的音频采样率保持一致。BufferSize默认是 1024如果延迟明显可以降到 512 或者 256但太低会导致爆音。这个需要根据具体程序来调没有万能值。5. 常见问题与排查技巧实录5.1 程序启动崩溃或闪退的排查思路程序启动就崩溃是最让人头疼的问题。根据我的经验原因通常集中在几个方面。第一是缺少 DLL 依赖很多 Windows 程序依赖 VC 运行库、.NET Framework、DirectX 运行时等。你可以在 Madeira 里用winetricks工具来安装这些依赖虽然 Madeira 没有图形化的 winetricks但可以通过命令行调用。第二是 FEX-Emu 的翻译错误某些特定指令序列会导致翻译器崩溃。这时候可以尝试在 FEX 配置里开启HalfBarrierTSOEnabled或者调整SMCChecks参数这些选项能改变翻译器对内存和指令缓存的检查策略有时候能绕过崩溃点。第三是权限问题iOS 的沙盒限制导致某些程序无法访问特定目录或者系统接口。比如程序试图写入C:\Windows\System32下的文件或者调用CreateFile打开一个不存在的设备。这种情况下可以在 Wine 配置里把这些路径重定向到用户目录或者用winecfg的驱动器映射功能把某个目录映射成程序期望的路径。我遇到过一个财务软件它启动时要读取C:\ProgramData下的配置文件但 Madeira 的前缀里没有这个目录手动创建后就能正常启动了。5.2 图形渲染异常黑屏、花屏、帧率低的处理图形问题在 Madeira 里非常常见因为 DXMT 的翻译层还在不断完善中。黑屏通常意味着 D3D 设备创建失败或者着色器编译出错。你可以先检查 Madeira 的日志文件里面会记录 DXMT 的初始化过程和错误信息。如果看到Failed to create Metal device或者Shader compilation error说明问题出在 Metal 层。这时候可以尝试降低ResolutionScale或者关闭ShaderCacheEnabled让着色器重新编译。有时候是某个特定的着色器指令 DXMT 还不支持只能等后续版本更新。花屏问题往往和纹理格式有关。Windows 程序可能使用了 DXMT 尚未完全支持的压缩纹理格式比如 BC6H 或者 BC7。你可以在 DXMT 配置里开启TextureFallback选项让它把不支持的纹理格式转换成 RGBA 格式再上传。这样做会占用更多显存但能解决大部分花屏问题。帧率低的话除了前面提到的 FEX 和 DXMT 参数调整还可以检查一下设备是否在省电模式。iOS 在低电量模式下会限制 CPU 和 GPU 频率导致性能大幅下降。跑 Madeira 的时候最好插着电并且关闭低电量模式。5.3 输入设备与窗口管理的适配问题Madeira 运行 Windows 程序时输入事件需要从 iOS 的触摸屏或者外接键盘鼠标转换成 Windows 的鼠标键盘消息。触摸屏方面Madeira 默认把单指触摸映射为鼠标左键双指触摸映射为右键长按映射为拖拽。这个映射逻辑对大部分程序够用但有些游戏需要更精细的控制比如同时按下多个按键、或者使用滚轮。你可以在 Madeira 的输入设置里调整映射方案或者外接一个蓝牙鼠标键盘体验会好很多。窗口管理方面Windows 程序可能创建多个窗口、弹出对话框、或者使用全屏模式。Madeira 默认把这些窗口都渲染在一个画布上但有时候窗口位置会错乱或者对话框被主窗口遮挡。你可以在 Wine 配置里开启VirtualDesktop模式让所有窗口都在一个虚拟桌面里显示这样窗口位置就由 Wine 统一管理不会出现错位。代价是失去了一些原生窗口管理的便利性比如不能单独调整某个窗口的大小。我一般是在遇到窗口问题时才开启这个模式平时还是用默认的窗口管理方式。5.4 常见问题速查表问题现象可能原因排查方法解决建议程序启动无反应Wine 前缀未初始化检查drive_c目录是否存在重新初始化前缀启动后闪退缺少 DLL 依赖查看 Madeira 日志中的 DLL 加载错误用 winetricks 安装对应运行库黑屏但程序未崩溃D3D 设备创建失败检查 DXMT 日志中的 Metal 错误切换渲染后端为gl或降低分辨率花屏或纹理错乱纹理格式不支持查看日志中的纹理格式警告开启TextureFallback帧率极低FEX 翻译效率不足检查 CPU 占用率和设备温度调整CoreCount关闭低电量模式音频爆音或延迟缓冲区设置不当检查音频采样率和缓冲区大小调整BufferSize为 512 或 1024输入无响应触摸映射未生效检查输入设置中的映射方案外接蓝牙键鼠或调整映射窗口位置错乱多窗口管理冲突观察窗口创建顺序开启VirtualDesktop模式6. 性能调优与进阶玩法6.1 针对不同程序类型的配置策略不同类型的 Windows 程序对资源的需求差异很大配置策略也应该有所区别。老式 2D 游戏和办公软件通常对 CPU 和 GPU 要求不高重点是把兼容性调好。这类程序建议开启TSOEnabled保证内存序正确DXMT 那边用默认配置就行分辨率缩放保持 1.0。3D 游戏和图形密集型程序则需要把性能放在第一位。可以关闭TSOEnabled把CoreCount调到最大DXMT 的ResolutionScale降到 0.75 甚至 0.5并且开启ShaderCacheEnabled减少重复编译。对于需要大量文件读写的程序比如数据库工具或者老式安装程序建议把 Wine 前缀放在设备的高速存储区域。Madeira 默认把前缀放在应用沙盒的Documents目录下这个位置在 iOS 上通常是闪存速度还可以。但如果你发现文件操作特别慢可以尝试把前缀移到tmp目录或者应用缓存目录这些位置可能使用更快的存储介质。不过要注意tmp目录可能在系统清理时被删除重要数据还是要放在Documents下。6.2 利用 FEX-Emu 的缓存机制加速二次启动FEX-Emu 有一个非常有用的特性就是指令翻译缓存。第一次运行某个程序时FEX-Emu 会把翻译过的 ARM64 指令块缓存到磁盘上下次再运行同一个程序时直接加载缓存省去重新翻译的时间。这个缓存默认是开启的但缓存文件可能会变得很大尤其是运行大型程序时。你可以在 FEX 配置里设置CacheSize来限制缓存占用的空间或者定期清理缓存目录。我一般会保留缓存因为二次启动的速度提升非常明显一个原本需要 30 秒才能进入主菜单的游戏有了缓存后可能 10 秒就进去了。不过缓存也有一个坑如果你更新了 Madeira 或者 FEX-Emu 的版本旧的缓存可能不兼容导致程序启动时崩溃。这时候需要手动删除缓存目录让 FEX-Emu 重新生成。缓存目录通常在 Madeira 的Library/Caches/fex下面删除里面的所有文件即可。另外如果你修改了 FEX 的配置参数比如TSOEnabled缓存也会失效需要重新生成。所以建议在调整配置之前先想清楚要改什么避免反复生成缓存浪费时间。6.3 外接显示器与手柄的玩法扩展iOS 设备支持外接显示器通过 USB-C 或者 Lightning 转 HDMI 接口可以把画面输出到大屏幕上。Madeira 也支持这个特性你可以在设置里选择“外接显示器模式”让 Windows 程序全屏显示在外部显示器上而 iOS 设备本身变成触摸板或者控制器。这个玩法适合那些原本就为大屏幕设计的游戏或者工具软件。我试过用 iPad 外接显示器跑一个老式策略游戏体验比在 iPad 屏幕上好很多字更大操作也更方便。手柄方面Madeira 支持 MFi 认证的蓝牙手柄也支持 Xbox 和 PlayStation 的无线手柄。手柄的按键可以映射到 Windows 的键盘和鼠标事件你可以在 Madeira 的输入设置里自定义映射方案。对于动作游戏和模拟器类程序手柄的体验比触摸屏好太多。不过要注意有些老游戏只支持 DirectInput 手柄接口而 Madeira 的手柄映射是基于 XInput 的可能需要额外的转换层。我目前测试下来大部分现代手柄都能正常工作少数老游戏需要手动配置。7. 我个人在实际操作中的几点体会折腾 Madeira 这段时间我最大的感受是它不是一个开箱即用的产品而是一个需要耐心调试的工具。同样的一个程序在不同的设备上、不同的配置下表现可能完全不同。我建议新手先从最简单的程序开始比如一个记事本或者计算器确认整个流程能跑通再逐步尝试更复杂的程序。不要一上来就挑战大型 3D 游戏那样很容易被各种报错劝退。另外社区的力量非常重要。Madeira 的更新频率不算低很多问题在最新版本里已经修复了但你可能还在用旧版本。遇到问题时先去项目的讨论区或者社区频道搜一下大概率已经有人遇到过类似的情况。我自己的经验是把每次调试的过程和配置都记录下来形成一个自己的“配置库”下次遇到同类程序时可以直接参考省去很多重复劳动。最后再分享一个小技巧如果你发现某个程序在 Madeira 里跑起来特别卡但你又不想降低分辨率可以尝试在 Wine 配置里开启CSMT选项。CSMT 是 Wine 的命令流技术它把图形命令的提交放到单独的线程里减少主线程的等待时间。这个选项在桌面版 Wine 上默认是开启的但在 Madeira 里可能需要手动打开。开启后某些游戏的帧率能提升 10% 到 20%尤其是那些 CPU 瓶颈明显的场景。当然CSMT 也不是万能的有些程序开启后反而会出现画面撕裂或者输入延迟需要根据实际情况取舍。