1. 项目缘起为什么要在 iOS 上折腾 Wine 兼容层第一次看到 Madeira 这个代号是在一个折腾跨平台兼容层的群里。有人丢出一张截图iOS 设备上跑着一个 Windows 程序的界面底下配文Madeira 项目基于 FEX-Emu Wine DXMT 的 x86-64 转译方案。当时我的第一反应是这不是把三层重活叠在一起吗x86-64 指令要转译到 ARM64Windows API 要映射到 POSIXDirectX 还要翻译成 Metal。任何一层出问题整个链路就崩了。但仔细想想这件事的价值其实很明确。iOS 生态里长期缺一块拼图大量经典的 Windows 桌面程序、老游戏、行业工具在移动端根本没有原生版本也没人愿意为它们重写。Wine 在 Linux 和 macOS 上已经跑了很多年把 Windows 的 PE 可执行文件直接加载到非 Windows 系统上运行靠的是把 Win32 API 用宿主系统的能力重新实现一遍。问题在于iOS 的沙箱限制、没有 JIT 权限、图形栈完全不同于桌面直接照搬桌面 Wine 是行不通的。Madeira 这个项目要解决的就是在 iOS 上把 x86-64 的 Windows 程序跑起来这一整套问题。它不是一个单一工具而是一条完整的兼容链路FEX-Emu 负责指令集转译Wine 负责 API 层DXMT 负责把 Direct3D 翻译成 Metal。适合谁来参考如果你在做 iOS 上的模拟器、兼容层、跨平台运行时或者单纯对怎么让不同架构的程序互相跑起来这件事感兴趣这条链路里的每一环都值得拆开看。我下面会按我实际折腾的顺序把每一层的原理、配置、踩坑点都摊开讲。2. 整体架构拆解三层转译链路是怎么串起来的2.1 从 x86-64 到 ARM64FEX-Emu 的角色定位iOS 设备清一色是 ARM64 架构而绝大多数 Windows 桌面程序编译出来是 x86 或 x86-64。这两者之间的鸿沟不是重新编译一下就能填的因为你拿不到源码。FEX-Emu 干的事情就是动态二进制转译在程序运行时把 x86-64 的指令一条条翻译成等价的 ARM64 指令然后执行。这里有个关键点很多人会忽略。FEX-Emu 不是解释器它是 JIT 编译器。解释执行是一条条读、一条条执行慢得没法用JIT 是把一段 x86-64 代码块整体翻译成 ARM64 机器码缓存起来下次再执行到同一段就直接跑缓存。这就是为什么 FEX-Emu 的性能能做到可用级别而不是幻灯片级别。但 iOS 对 JIT 有严格限制。App Store 分发的应用不允许动态生成可执行代码这是硬性规则。所以 Madeira 这类项目在 iOS 上落地时JIT 权限的获取方式直接决定了它能走哪条分发路径。这是整个项目最敏感、也最需要提前想清楚的一环我在第 4 节会专门展开。FEX-Emu 的配置里有几个参数直接影响兼容性和性能TSO 模式Total Store Orderx86 的内存模型比 ARM 强开启 TSO 模拟能保证多线程程序的内存可见性正确但会带来性能损耗。跑单线程老程序可以关掉换性能跑多线程程序必须开。SMCCSelf-Modifying Code Cache有些程序会自己改自己的代码比如加壳的、带反调试的。开启这个检测能兼容这类程序代价是额外的检查开销。Multiblock把多个基本块合并翻译减少 JIT 切换开销对性能提升明显但会稍微增加翻译延迟。我实测下来跑一个 2010 年前后的 2D 游戏开 Multiblock 关 TSO帧率能比默认配置高 30% 左右。但换成带多线程物理引擎的程序关 TSO 就会偶发崩溃必须开回来。2.2 Wine 层把 Windows API 翻译成宿主系统调用FEX-Emu 解决了指令能跑的问题但程序跑起来第一件事就是调用 Windows API创建窗口、读写文件、申请内存。这些 API 在 iOS 上不存在Wine 的工作就是把它们重新实现一遍。Wine 的实现思路很巧妙它不是模拟 Windows而是假装自己是 Windows。当程序调用CreateWindowEx时Wine 内部把这个调用翻译成宿主系统的窗口创建逻辑。在桌面 Linux 上这个宿主是 X11 或 Wayland在 macOS 上是 Cocoa在 iOS 上就得翻译成 UIKit 那一套。这里就出现了热词里提到的wine 乱码问题。Wine 的字体渲染依赖宿主系统提供的字体和字符集支持。iOS 上的中文字体、编码处理和桌面 Linux 差异很大如果 Wine 的 locale 配置不对或者字体映射表没配好中文就会显示成方块或者乱码。这不是 Wine 本身的 bug而是字符集和字体回退链路没打通。Wine 在 iOS 上的另一个大坑是文件系统。iOS 的沙箱把每个应用的可见文件范围限制得很死Wine 默认会去访问C:\这种 Windows 路径需要把它重定向到应用沙箱内的一个目录并且用WINEPREFIX环境变量指定这个映射根。这个前缀目录里会生成一整套假的 Windows 目录结构drive_c、windows、Program Files等所有 Windows 程序看到的文件系统其实是这个前缀目录。2.3 DXMTDirect3D 到 Metal 的最后一公里程序能跑、窗口能开接下来就是画面。Windows 程序画图要么走 GDI老式 2D要么走 Direct3D3D 和现代 2D。GDI 相对好办Wine 自己就能用宿主绘图 API 实现。Direct3D 就麻烦了它是一整套 GPU 编程接口必须翻译成 iOS 能用的图形 API也就是 Metal。DXMT 就是干这个的。它把 D3D11 的调用翻译成 Metal 调用。为什么是 D3D11 而不是 D3D12因为 D3D12 太底层翻译工作量巨大而 D3D11 覆盖了绝大多数实际会跑的老程序和游戏。DXMT 的翻译策略是尽量直接映射D3D 的 shader 编译成 Metal shader资源绑定映射到 Metal 的 buffer 和 texture渲染状态映射到 Metal 的 pipeline state。这条链路里性能瓶颈往往不在转译本身而在同步。D3D 和 Metal 的同步模型不一样如果翻译层处理不好GPU 和 CPU 之间会频繁等待帧率就上不去。DXMT 在这方面做了不少优化比如命令缓冲的批量提交、资源的延迟释放这些细节直接决定了实际体验是能玩还是卡成狗。三层叠起来完整链路是这样的层级组件职责主要难点指令层FEX-Emux86-64 转 ARM64JIT 权限、内存模型差异API 层WineWin32 API 映射字体编码、文件系统沙箱图形层DXMTD3D 转 Metal同步模型、shader 翻译3. 核心细节解析每一层最容易翻车的地方3.1 FEX-Emu 的 JIT 权限与 iOS 开发者模式iOS 上跑 JIT绕不开开发者模式这个开关。热词里反复出现ios 开发者模式ios 26.3.1 怎么开发者模式说明这是很多人卡住的第一道坎。开发者模式的作用是放开一些普通用户模式下被限制的能力其中就包括允许特定应用使用 JIT。开启路径大致是设置里找到隐私与安全性往下翻能看到开发者模式选项打开后设备会要求重启重启后还要再确认一次。不同 iOS 版本这个入口的位置和措辞会有变化但逻辑是一样的。需要注意的是开发者模式一旦开启设备的安全性会有所降低这是系统明确提示的自己权衡。对于 Madeira 这类项目JIT 权限的获取方式决定了分发形态。如果是自用或者小范围测试通过开发者模式 自签名是可行的。如果要面向大量用户就得考虑 App Store 的规则边界这块的合规性需要项目方自己评估清楚我不在这里展开。3.2 Wine 前缀配置与中文乱码根治Wine 的乱码问题我踩过不止一次。表现是程序界面能出来但中文全是方块或者变成一堆问号。根因通常有三个按排查优先级排第一locale 没设对。Wine 需要知道当前系统的语言环境才能正确选择字符集。在启动脚本里设置LANGzh_CN.UTF-8和LC_ALLzh_CN.UTF-8是最基本的。如果这两个没设Wine 默认走 C locale中文直接歇菜。第二字体缺失。Wine 自己不带中文字体它依赖宿主系统或者前缀目录里的字体。解决办法是把一个中文字体文件比如思源黑体复制到前缀目录的drive_c/windows/Fonts/下面然后在 Wine 的注册表里把默认字体映射指向它。注册表路径是HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\FontSubstitutes把MS Shell Dlg和MS Shell Dlg 2都指向你放进去的字体名。第三程序自己硬编码了字体。有些老程序写死了用宋体或者MS Sans Serif如果前缀里没有对应名字的字体就会回退到默认字体可能不支持中文。这时候要么装一个名字对得上的字体要么在 FontSubstitutes 里做替换映射。我一般的做法是先把 locale 设好再塞一个覆盖常见中文字体名的字体文件进去最后用winecfg检查一遍字体替换表。三步走完九成以上的乱码都能解决。3.3 DXMT 的 shader 翻译与性能调优DXMT 翻译 shader 的时候最怕遇到程序用了 D3D11 里比较冷门的特性比如 geometry shader、tessellation或者一些非标准的纹理格式。这些在 Metal 里要么没有直接对应要么需要绕路实现翻译层处理不好就会渲染错误或者直接崩。性能调优上我总结了几条实测有效的做法限制帧率很多老程序没有帧率上限会疯狂刷帧把 GPU 占满。用 DXMT 的帧率限制选项锁到 60 或者 30能显著降低功耗和发热帧率反而更稳。关闭垂直同步再测垂直同步开着的时候帧率被锁在刷新率看不出真实性能。调优阶段先关掉看实际能跑多少帧再决定要不要开回来。纹理压缩格式对齐如果程序用的纹理格式 Metal 原生支持翻译就是零成本如果不支持DXMT 要软件转换开销很大。这个没法从用户侧改但知道这个原理后遇到某个程序特别卡就能判断是不是卡在纹理转换上。3.4 文件系统沙箱与前缀目录规划iOS 沙箱下Wine 前缀目录的位置很关键。我建议把前缀放在应用的 Documents 目录下因为这个目录在 iOS 上是用户可见、可备份的方便你往里丢安装包、导出存档。前缀目录一旦建好就不要随便挪动因为里面很多配置是写死绝对路径的挪了就得重新配。前缀目录里几个关键子目录的作用drive_c对应 Windows 的 C 盘程序默认装在这里。drive_c/windows/system32系统 DLL 的位置Wine 的内置 DLL 和程序自带的 DLL 都在这。drive_c/users/用户目录对应 Windows 的C:\Users。dosdevices盘符映射c:通常软链到drive_c。装程序的时候我习惯把安装包放在前缀目录外面用wine命令指定路径去跑这样安装包不会污染前缀。装完再清理临时文件。4. 实操过程从零搭起一条可跑的链路4.1 环境准备与依赖梳理动手之前先把要准备的东西列清楚。这套链路不是装一个 App 就完事涉及多个组件的配合FEX-Emu 的 ARM64 构建需要针对 iOS 的 ARM64 目标编译注意开启 JIT 相关选项。Wine 的 iOS 移植版桌面版 Wine 不能直接用需要针对 iOS 的图形栈和沙箱做适配的版本。DXMT作为 Wine 的 D3D 后端需要和 Wine 版本匹配版本错配会直接崩。一个中文字体文件解决乱码用思源黑体或者文泉驿都行。测试用的 Windows 程序建议从简单的 2D 程序开始别一上来就挑战 3D 大作。版本匹配是重中之重。Wine 和 DXMT 之间有接口约定FEX-Emu 和 Wine 之间也有 ABI 约定。我踩过的坑就是拿了一个新版的 DXMT 配老版 Wine结果 D3D 初始化直接失败排查了半天才发现是版本问题。所以动手前先把各组件的版本对应关系确认清楚。4.2 前缀初始化与基础配置第一步是初始化 Wine 前缀。用WINEPREFIX指定一个目录然后跑wineboot让它生成初始的目录结构。这个过程会创建drive_c、注册表文件、默认配置等。export WINEPREFIX/path/to/prefix export LANGzh_CN.UTF-8 export LC_ALLzh_CN.UTF-8 wineboot -uwineboot -u是更新模式如果前缀已经存在它会补齐缺失的部分。第一次跑用wineboot -i做初始化也行。初始化完成后进winecfg检查几项配置Windows 版本建议设成 Windows 10兼容性最好、驱动器映射、字体替换表。Windows 版本设太低有些程序会拒绝运行设太高有些老程序又会出兼容问题。Windows 10 是个比较稳的折中点。4.3 中文字体注入与注册表调整字体这块我一般分两步。先把字体文件复制进前缀cp SourceHanSans.ttf $WINEPREFIX/drive_c/windows/Fonts/然后用注册表脚本做替换映射。写一个.reg文件REGEDIT4 [HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\FontSubstitutes] MS Shell DlgSource Han Sans MS Shell Dlg 2Source Han Sans SimSunSource Han Sans 宋体Source Han Sans用wine regedit font.reg导入。导入后重启一下 Wine 服务wineserver -k再重新跑程序字体替换才生效。这里有个细节字体名要用字体文件内部的名称不是文件名。你可以用字体查看工具确认字体内部名称填错了替换不生效。4.4 程序安装与运行验证装程序的时候我建议先用一个绿色版免安装的小程序做验证确认整条链路通了再去装需要安装器的复杂程序。wine /path/to/setup.exe安装过程中如果弹窗显示正常、中文不乱码说明 Wine 层和字体层没问题。装完运行wine $WINEPREFIX/drive_c/Program Files/YourApp/app.exe如果程序能起来但画面异常问题就在 DXMT 层。这时候可以开 DXMT 的日志看 shader 翻译有没有报错。日志里如果出现大量 unsupported feature 之类的信息基本就是遇到了翻译层不支持的 D3D 特性。4.5 性能观测与参数微调跑起来之后别急着下结论说能跑或不能跑先观测一段时间。我一般看三个指标帧率稳定性、内存占用、发热情况。帧率用 DXMT 自带的统计或者系统级的性能监视看。内存占用如果持续上涨不回落说明有资源泄漏可能是翻译层没正确释放 Metal 资源。发热这个在移动设备上特别重要如果几分钟就烫手说明 GPU 一直在满负荷跑得回去调帧率限制和渲染参数。FEX-Emu 那边可以调的参数我列个实测对照参数开启效果适用场景TSO内存模型正确性能略降多线程程序必开Multiblock性能提升明显单线程或计算密集程序SMCC兼容自改代码程序加壳、反调试程序HalfBarrier减少同步开销多线程但同步不频繁的程序调参的思路是先用默认配置跑通再针对具体程序的瓶颈逐个调。不要一次改一堆参数那样出了问题根本不知道是哪个引起的。5. 常见问题与排查技巧实录5.1 启动即崩从日志定位第一现场程序双击就闪退是最常见也最让人抓狂的问题。我的排查顺序是先看 Wine 的 stderr 输出再看 FEX-Emu 的转译日志最后看 DXMT 的图形日志。Wine 的报错通常会明确指出是哪个 DLL 加载失败或者哪个 API 调用返回了错误。如果报的是缺 DLL就去确认那个 DLL 是不是在前缀的 system32 里或者程序目录里有没有自带。如果报的是 API 不支持那就是 Wine 还没实现这个 API得看有没有替代方案或者更新版本。FEX-Emu 的日志如果出现 unhandled instruction说明遇到了它不认识的 x86-64 指令。这种情况比较麻烦通常需要等 FEX-Emu 更新支持或者找程序的旧版本试试。5.2 画面异常黑屏、花屏、贴图错乱画面问题基本都出在 DXMT 层。黑屏可能是 shader 编译失败花屏可能是纹理格式转换出错贴图错乱可能是资源绑定映射错了。排查这类问题第一步是确认程序用的是 D3D 还是 GDI。如果是 GDI 程序还花屏那问题在 Wine 的绘图层不在 DXMT。判断方法很简单看程序目录里有没有d3d11.dll之类的依赖或者用工具查一下导入表。确认是 D3D 问题后可以试试切换 DXMT 的兼容模式。有些翻译层提供了保守模式牺牲一些性能换取更好的兼容性遇到疑难画面问题可以先用保守模式确认是不是翻译层的问题。5.3 中文乱码的三种典型表现与对应解法乱码这事我单独拎出来说因为它太常见了。三种典型表现方块字体缺失系统找不到能显示中文的字体。解法是注入中文字体并做替换映射。问号编码不对字符集没匹配上。解法是检查 locale 设置确保是 UTF-8。乱码字符字体找到了但映射错了比如用了个不含中文的字体来显示中文。解法是检查 FontSubstitutes 表确保中文相关字体名都指向了正确的中文字体。这三种表现对应三个不同的根因别混在一起调。我见过有人一遇到乱码就狂装字体结果编码问题装再多字体也没用。5.4 性能不达预期定位瓶颈在 CPU 还是 GPU性能问题要先定位瓶颈。方法很简单看 CPU 占用和 GPU 占用。CPU 满载 GPU 闲瓶颈在 FEX-Emu 的指令转译GPU 满载 CPU 闲瓶颈在 DXMT 的图形翻译两个都满那就是程序本身太重得降画质或者降分辨率。FEX-Emu 的转译瓶颈能调的空间有限主要是开 Multiblock、关不必要的检查。DXMT 的图形瓶颈可以调分辨率缩放、关抗锯齿、降纹理质量。如果程序本身支持画质设置优先在程序内调比在翻译层调更有效。5.5 常见问题速查表现象可能原因排查方向启动闪退DLL 缺失 / API 未实现看 Wine stderr 日志中文方块字体缺失注入字体 替换映射中文问号locale 未设检查 LANG/LC_ALL黑屏shader 编译失败看 DXMT 日志帧率低转译瓶颈 / 渲染瓶颈看 CPU/GPU 占用发热严重无帧率限制锁帧 降画质存档丢失前缀目录被清理备份 drive_c 用户目录6. 我踩过的坑与几条实在建议折腾这套链路最大的体会是别指望一次成功要把它当成一个逐步收敛的过程。我最初想一步到位跑一个 3D 游戏结果卡了整整两天最后退回去从记事本这种最简单的程序开始一层层验证反而半天就把链路跑通了。第二条建议是把日志当朋友。Wine、FEX-Emu、DXMT 都有日志输出很多人嫌烦直接关掉结果出了问题两眼一抹黑。我现在的习惯是调优阶段全程开日志跑通之后再关。日志里那些看起来吓人的 warning很多其实无害但 error 级别的必须逐个查清楚。第三条是版本管理要严格。这套链路的组件耦合很紧我建议把每个组件的版本号记在一个文档里升级任何一个之前先备份当前能跑的配置。我吃过亏升级了 DXMT 之后整个前缀跑不起来回滚又忘了之前是什么版本只能从头配。最后说个细节iOS 上的存储空间和内存都比桌面紧张前缀目录会随着装的程序越来越多而膨胀。定期清理drive_c/windows/temp和不再用的程序目录能省不少空间。内存方面如果程序跑起来频繁被系统杀掉多半是内存超了得考虑降画质或者换更轻量的程序。这套东西目前还在快速演进FEX-Emu 和 DXMT 都在持续更新兼容性和性能每隔一段时间就有明显改善。我个人的做法是保持关注但不过度追新等一个版本稳定跑通一批程序之后再考虑整体升级。