1. 项目缘起：为什么要在 iOS 上折腾 Wine
“Madeira”这个项目标题，乍一看像是个地名，但在我们这行里，它指向的是一套非常具体的工程实践：在 iOS 设备上通过 Wine 及其衍生方案运行 x86-64 架构的 Windows 应用。热搜词里同时出现了 Wine、FEX-Emu、DXMT、iOS、x86-64 这几个关键词，基本可以确定这个项目的核心命题——把原本属于桌面端的 Windows 兼容层，搬到移动端的 iOS 环境里跑起来。
先说清楚这件事到底解决什么问题。iOS 生态长期是封闭的，App Store 上架审核严格，很多老旧的 Windows 工具、行业软件、单机游戏根本没有 iOS 原生版本。而 Wine 的思路不是模拟 Windows，而是把 Windows 的 API 调用翻译成宿主系统能理解的调用，从而直接运行 exe 文件。桌面 Linux 和 macOS 上这套玩法已经成熟多年，但 iOS 因为系统限制、架构差异、签名机制，一直是个硬骨头。Madeira 要啃的就是这块骨头。
适合看这篇内容的人有三类：一是想在 iPad 或 iPhone 上跑 Windows 老软件的技术爱好者；二是研究跨架构二进制翻译的开发者，尤其是对 FEX-Emu 这类 x86-64 到 ARM64 翻译层感兴趣的人；三是做 iOS 自动化、企业内部分发、兼容层工具链的工程人员。如果你只是想在手机上装个 Windows 游戏图个新鲜，那这篇也能帮你看清门槛在哪，少走弯路。
需要提前说明的是，iOS 上的 Wine 方案和桌面端完全不是一个难度量级。桌面端你apt install wine就完事了，iOS 上你要面对的是：没有 root、不能随意 fork 进程、JIT 权限受限、代码签名强制、沙盒路径隔离。所以 Madeira 这类项目的价值，不在于“能不能跑”，而在于“在这么多限制下怎么把它跑稳”。
2. 整体架构设计：Wine + FEX-Emu + DXMT 的分工逻辑
2.1 三层翻译栈的职责划分
Madeira 的核心不是单一组件，而是一条翻译链路。理解这条链路，比记任何命令都重要。
第一层是Wine，负责 Windows API 到 POSIX 的翻译。它把kernel32.dll、user32.dll、ntdll.dll这些 Windows 核心库的调用，映射到宿主系统的文件、线程、内存、图形接口上。Wine 本身不翻译 CPU 指令，它翻译的是系统调用层面的语义。
第二层是FEX-Emu，负责 x86-64 指令到 ARM64 指令的翻译。iOS 设备全是 ARM 架构，而绝大多数 Windows exe 是 x86 或 x86-64 编译的。FEX-Emu 做的是动态二进制翻译，把 x86-64 的机器码在运行时翻译成 ARM64 能执行的指令。这一步是性能瓶颈的主要来源，也是整个方案里技术含量最高的部分。
第三层是DXMT，负责 Direct3D 到 Metal 的翻译。Windows 应用和游戏大量依赖 DirectX，而 iOS 的图形栈是 Metal。DXMT 把 D3D11、D3D12 的调用转换成 Metal 调用，让图形渲染能真正落到 GPU 上。没有这一层，Wine 跑起来的窗口就是黑屏或者软件渲染的幻灯片。
这三层的顺序是：Windows 应用发出 x86-64 指令和 D3D 调用，FEX-Emu 翻译指令，Wine 翻译系统调用，DXMT 翻译图形调用，最终落到 iOS 的 ARM64 CPU 和 Metal GPU 上。任何一层出问题，表现都不一样：FEX-Emu 挂了通常是崩溃或非法指令，Wine 挂了通常是缺 dll 或路径错误，DXMT 挂了通常是花屏、黑屏或帧率极低。
2.2 为什么不用 QEMU 全系统模拟
有人会问，为什么不直接用 QEMU 跑一个完整的 Windows 虚拟机？答案很简单：性能。QEMU 全系统模拟要模拟 CPU、内存控制器、磁盘、网卡、显卡，每一条指令都要经过软件模拟，在移动端 ARM 芯片上跑 x86 Windows，帧率通常是个位数，连基本操作都卡。而 Wine + FEX-Emu 的方案是用户态翻译，只翻译应用本身的指令，系统调用直接走宿主，图形走 Metal，性能能提升一个数量级。
另一个原因是 iOS 的限制。QEMU 需要创建虚拟设备、需要更大的内存映射、需要更底层的权限，在非越狱 iOS 上几乎不可能稳定运行。而 Wine 方案虽然也受限，但至少能在用户态找到生存空间。
2.3 架构选型的关键取舍
Madeira 在架构上有几个关键取舍，值得展开说。
取舍一：x86-64 还是 x86？热搜词里明确写了 x86-64，说明项目瞄准的是 64 位 Windows 应用。32 位 x86 应用虽然也能通过 FEX-Emu 跑，但 64 位是主流，且 64 位应用能利用更大的地址空间。代价是 FEX-Emu 对 x86-64 的翻译复杂度更高，尤其是 REX 前缀、64 位寄存器、新的指令集扩展。
取舍二：Wine 版本怎么选。Wine 有 stable、devel、staging 三个分支。Madeira 这类项目通常跟 devel 或 staging，因为需要最新的 WoW64 支持、最新的图形驱动接口。但 devel 分支的回归 bug 也多，所以实际部署时往往要锁定某个 commit，而不是无脑跟最新。
取舍三：DXMT 还是 DXVK + MoltenVK？DXVK 是把 D3D 翻译成 Vulkan，MoltenVK 再把 Vulkan 翻译成 Metal，两层翻译开销大。DXMT 是直接 D3D 到 Metal，少一层，延迟更低，但成熟度不如 DXVK 生态。Madeira 选 DXMT 是性能优先的思路。
3. 核心细节解析：iOS 环境下的关键限制与应对
3.1 JIT 权限：整个方案的生命线
iOS 上跑 FEX-Emu，最核心的依赖是JIT（即时编译）权限。FEX-Emu 要把 x86-64 指令翻译成 ARM64 指令，翻译结果需要写到可执行内存里再跳过去执行。iOS 默认禁止普通应用申请可写且可执行的内存页（W^X 保护），没有 JIT，FEX-Emu 只能走解释执行，速度慢到无法接受。
获取 JIT 权限的常见路径有几条：一是利用调试器附加时的cs_debugged标志，让系统放宽限制；二是通过特定的 entitlement 配置；三是在支持的环境下使用MAP_JIT标志配合pthread_jit_write_protect_np切换写保护。Madeira 这类项目通常依赖第一条或第二条，这也是为什么很多 iOS Wine 方案需要配合特定的签名和调试环境。
注意：JIT 权限的获取方式直接决定了方案的适用范围。如果依赖调试器附加，那每次启动都要走一遍附加流程，自动化和稳定性都会打折扣。这是 iOS Wine 方案和桌面方案最大的体验差距来源。
3.2 代码签名与沙盒路径
iOS 应用的代码签名是强制的。Wine 运行 Windows exe 时，exe 本身不是签名的 iOS 可执行文件，它只是被 Wine 加载的数据。但 Wine 内部会 mmap 出可执行内存来跑翻译后的代码，这部分内存的签名状态就变得敏感。如果签名策略太严，翻译后的代码页会被系统拒绝执行。
沙盒路径是另一个坑。Windows 应用习惯写C:\Users\...、C:\Program Files\...，而 iOS 应用只能访问自己的沙盒目录。Wine 需要把C:盘映射到沙盒内的某个目录，通常是Documents/或Library/下的一个子目录。这个映射关系如果配错，应用会找不到自己的配置文件、存档、dll，表现就是启动即崩或者功能缺失。
3.3 图形栈的适配难点
DXMT 在 iOS 上要面对 Metal 的特性限制。Metal 不像 Vulkan 那样有丰富的扩展，某些 D3D 特性在 Metal 上没有直接对应，需要绕行实现。比如 D3D11 的某些纹理格式、多采样抗锯齿、计算着色器的特定用法，在 Metal 上要么用近似方案，要么直接不支持。
实测下来，DXMT 对 D3D11 的支持相对成熟，D3D12 还在完善中。如果目标应用是 D3D9 时代的产物，可能还要经过 D3D9 到 D3D11 的转换层，链路更长，问题更多。所以选应用时，优先选 D3D11 的，能省很多事。
3.4 输入与窗口系统的映射
Windows 应用的输入模型和 iOS 的触摸模型差异巨大。Wine 需要把触摸事件翻译成鼠标事件，把软键盘输入翻译成 Windows 的键盘消息。Madeira 这类项目通常会在 Wine 的窗口系统层做适配，把 iOS 的UIEvent转成 Wine 的INPUT结构。
窗口管理也是问题。Windows 应用假设有可调整大小的窗口、有标题栏、有最小化最大化按钮，而 iOS 是全屏单窗口模型。Wine 的虚拟桌面模式可以把多个 Windows 窗口合成到一个 iOS 视图里，但交互体验需要额外打磨。
4. 实操过程：从零搭建 Madeira 运行环境
4.1 环境准备与依赖清单
先列一下需要准备的东西。以下清单基于常见 iOS Wine 方案的通用实践，具体版本号需要根据你手头的工具链调整。
| 组件 | 作用 | 备注 |
|---|---|---|
| iOS 设备 | 运行宿主 | 建议 A12 及以上芯片，内存 4GB 起 |
| 签名工具 | 应用签名 | 需支持所需 entitlement |
| Wine 源码 | API 翻译层 | 建议 devel 或 staging 分支 |
| FEX-Emu | x86-64 翻译 | 需 ARM64 构建 |
| DXMT | D3D 到 Metal | 需匹配 Wine 版本 |
| 调试环境 | 获取 JIT | 视具体方案而定 |
设备选择上，A12 之后的芯片对 ARM64 的优化更好，FEX-Emu 的翻译效率也更高。内存方面，Wine 本身加上翻译缓存，再加上应用本身，4GB 是底线，6GB 以上会舒服很多。存储空间要留足，Wine 的 prefix 目录加上应用文件，几个 GB 是常态。
4.2 Wine Prefix 的初始化
Wine 的 prefix 是它模拟的 Windows 环境根目录。初始化 prefix 是第一步，也是最容易出问题的一步。
# 设置 Wine 的 prefix 路径，指向 iOS 沙盒内可写目录 export WINEPREFIX=/path/to/sandbox/Documents/madeira-prefix # 设置 Wine 架构为 64 位 export WINEARCH=win64 # 初始化 prefix，这一步会创建 C: 盘目录结构 wineboot -uwineboot -u会创建drive_c、windows、Program Files等目录，并注册基本的注册表项。如果这一步报错，通常是路径权限问题或者缺少必要的 dll。在 iOS 上，路径必须指向沙盒内可写的位置，指向只读位置必然失败。
初始化完成后，可以检查一下目录结构：
ls -la $WINEPREFIX/drive_c/ # 应该能看到 windows、Program Files、users 等目录4.3 FEX-Emu 的配置与调优
FEX-Emu 的配置直接影响性能。核心参数有几个：
- 核心数：FEX-Emu 可以配置使用多少个翻译线程。iOS 设备的核心数有限，通常设成性能核的数量比较合适。
- 翻译缓存大小：缓存越大，重复执行的代码命中率越高，但内存占用也越大。移动端要在性能和内存之间找平衡。
- 指令集特性：可以配置是否启用某些 x86 指令集扩展的翻译。如果目标应用用到了 AVX，而 FEX-Emu 的 AVX 支持不完整，就可能出问题。
# FEX-Emu 环境变量示例 export FEX_CORES=4 export FEX_TSOENABLED=1 export FEX_VECTORTSOENABLED=1 export FEX_MEMCPYSETTSOENABLED=1FEX_TSOENABLED是开启 x86 的强内存序模拟。x86 是 TSO（Total Store Order）内存模型，ARM 是弱内存序，如果不开启 TSO 模拟，多线程应用可能出现数据竞争导致的诡异 bug。这个选项对性能有影响，但为了正确性，多数情况下必须开。
4.4 DXMT 的部署与验证
DXMT 需要把编译好的d3d11.dll、dxgi.dll等文件放到 Wine prefix 的对应目录里，通常是drive_c/windows/system32/。
# 复制 DXMT 的 dll 到 system32 cp dxmt/build/bin/d3d11.dll $WINEPREFIX/drive_c/windows/system32/ cp dxmt/build/bin/dxgi.dll $WINEPREFIX/drive_c/windows/system32/ # 设置 DXMT 相关环境变量 export DXMT_LOG_LEVEL=info export DXMT_ENABLE_METAL=1验证 DXMT 是否生效，可以跑一个简单的 D3D11 测试程序，看日志里有没有 Metal 设备的初始化信息。如果日志显示回退到软件渲染，说明 DXMT 没加载成功，要检查 dll 路径和版本匹配。
4.5 运行第一个 Windows 应用
选一个简单的应用做首次验证，比如记事本或者一个小的 D3D11 示例程序。
# 运行一个 exe wine /path/to/app.exe首次运行会看到大量日志输出。重点关注几类信息：FEX-Emu 的翻译统计、Wine 的 dll 加载情况、DXMT 的 Metal 初始化结果。如果应用窗口能出来且能交互，说明整条链路通了。
提示：第一次运行不要直接上大型游戏或复杂软件。先用小工具验证链路，再逐步增加复杂度。这样出问题时容易定位是哪一层的问题。
5. 常见问题与排查技巧实录
5.1 启动即崩：从日志定位问题层
应用启动就崩溃是最常见的问题。排查思路是按层排除。
先看 FEX-Emu 日志。如果日志里有Unhandled instruction或SIGILL，说明遇到了 FEX-Emu 不支持的 x86 指令。这种情况要么换应用版本，要么等 FEX-Emu 更新支持。
再看 Wine 日志。如果日志里有err:module:import_dll或Library not found，说明缺 dll。需要把对应的 Windows dll 放到 system32 或者应用目录。
最后看 DXMT 日志。如果日志里有Failed to create Metal device或Unsupported format，说明图形层有问题。可能是 Metal 设备初始化失败，或者应用用了 DXMT 不支持的格式。
5.2 中文乱码：字体与编码的双重问题
热搜词里出现了“wine 乱码”和“wine 栏是乱码”，这是 Wine 的经典问题。乱码通常有两个来源：字体缺失和编码不匹配。
字体方面，Wine 默认不带中文字体，需要把中文字体文件（如simsun.ttc、msyh.ttf）放到$WINEPREFIX/drive_c/windows/Fonts/目录，并在注册表里配置字体替换。
# 复制中文字体 cp simsun.ttc $WINEPREFIX/drive_c/windows/Fonts/ # 注册表配置字体替换 wine reg add "HKCU\\Software\\Wine\\Fonts\\Replacements" /v "MS Shell Dlg" /d "SimSun" /f wine reg add "HKCU\\Software\\Wine\\Fonts\\Replacements" /v "MS Shell Dlg 2" /d "SimSun" /f编码方面，某些应用依赖特定的代码页。可以在 Wine 的 locale 设置里指定zh_CN.UTF-8或zh_CN.GBK，看应用的实际需求。
5.3 性能问题：帧率低与卡顿的排查
性能问题要分清楚是 CPU 瓶颈还是 GPU 瓶颈。
CPU 瓶颈的表现是：应用逻辑慢、界面响应迟钝、但图形渲染本身不卡。这时候要看 FEX-Emu 的翻译缓存命中率，如果命中率低，说明大量代码在重复翻译，需要增大缓存。另外检查是否开启了 TSO 模拟，TSO 对性能有影响，但关了可能出正确性问题。
GPU 瓶颈的表现是：帧率低、画面卡顿、但 CPU 占用不高。这时候要看 DXMT 的日志，确认是否走了 Metal 硬件加速。如果回退到软件渲染，帧率必然低。还要检查应用的图形设置，降低分辨率、关闭抗锯齿、减少特效，都能显著提升帧率。
5.4 常见问题速查表
| 现象 | 可能原因 | 排查方向 |
|---|---|---|
| 启动即崩 | 缺 dll / 不支持指令 | 看 Wine 和 FEX 日志 |
| 中文乱码 | 字体缺失 / 编码错误 | 装字体、配注册表 |
| 黑屏 | DXMT 未加载 | 检查 dll 路径和日志 |
| 帧率极低 | 软件渲染 / TSO 开销 | 确认 Metal 加速、调 FEX 参数 |
| 存档丢失 | 路径映射错误 | 检查 C: 盘映射 |
| 输入无响应 | 事件映射问题 | 检查触摸到鼠标的转换 |
5.5 几个踩过的坑
第一个坑是prefix 路径带空格或中文。Wine 对路径里的特殊字符处理不好，prefix 路径尽量用纯英文、无空格的短路径。
第二个坑是dll 版本不匹配。Wine 的版本和 DXMT 的版本必须匹配，Wine 升级后 DXMT 也要跟着重新编译，否则接口对不上，加载就失败。
第三个坑是JIT 权限不稳定。某些环境下 JIT 权限时有时无，表现是应用有时能跑有时崩。这种情况要检查签名配置和调试附加流程，确保每次启动的环境一致。
第四个坑是内存不足被系统杀掉。iOS 对应用内存有硬限制，Wine 加翻译缓存加应用，很容易触顶。解决方法是减小 FEX 缓存、关闭不必要的 Wine 服务、优化应用本身的内存占用。
6. 性能调优与进阶玩法
6.1 FEX-Emu 的缓存策略调优
FEX-Emu 的翻译缓存是性能关键。缓存太小，重复翻译多；缓存太大，内存压力大。移动端建议从较小的缓存开始，逐步增大，观察帧率和内存占用的变化曲线，找到拐点。
另外可以开启 FEX 的块链接（block linking）优化，把频繁连续执行的翻译块链接起来，减少查找开销。这个优化对循环密集的应用效果明显。
6.2 DXMT 的渲染路径选择
DXMT 支持多种渲染路径，不同路径的性能和兼容性不同。有的路径延迟低但兼容性差，有的路径兼容性好但多一层拷贝。实际调优时，可以针对具体应用切换路径，看哪个组合最稳。
对于 D3D11 应用，优先用原生 Metal 路径。对于 D3D9 应用，可能要走转换层，这时候要关注转换层的开销。
6.3 多应用隔离与资源管理
如果要在同一台设备上跑多个 Windows 应用，建议用独立的 Wine prefix。每个 prefix 有自己的注册表、dll、配置，互不干扰。代价是磁盘占用增加，但稳定性提升明显。
资源管理方面，iOS 的后台限制很严，Wine 应用切到后台可能被挂起或杀掉。如果需要后台运行，要配置相应的后台模式，但这会进一步增加内存压力，需要权衡。
7. 我个人在实际操作中的几点体会
折腾 iOS 上的 Wine 方案，最大的感受是：桌面端的经验只能参考三成，剩下七成要在 iOS 的限制里重新摸索。桌面端一个winetricks能解决的问题，iOS 上可能要改签名、调 entitlement、重新编译。
另一个体会是，日志是你的唯一朋友。iOS 上没有 strace、没有 gdb 随手可用，出问题时只能靠 Wine、FEX-Emu、DXMT 各自输出的日志来定位。所以从第一天起就要把日志级别调好，把日志收集流程建起来，不然出了问题就是两眼一抹黑。
还有一点，不要追求一次跑通所有应用。先跑通一个最简单的，把链路验证透，再逐步增加复杂度。每增加一个应用，都可能引入新的 dll 依赖、新的图形特性、新的指令集需求。稳扎稳打比贪多求快靠谱得多。
最后分享一个小技巧：如果某个应用在 FEX-Emu 下崩溃，可以试试用FEX_DEBUG=1打开详细日志，看崩溃前最后翻译的是哪条指令。很多时候问题就出在某个不常用的指令集扩展上，知道是哪条指令，就能判断是等更新还是找替代方案。这个排查思路帮我省了不少时间。
