1. 项目缘起为什么要在 iOS 上折腾 Wine第一次看到 Madeira 这个代号很多人会以为是某个度假海岛或者葡萄酒品牌但在我们这群喜欢折腾跨平台兼容层的人眼里它指向的是一件事把 Windows 应用搬到 iOS 设备上跑起来。核心思路并不新鲜Wine 在桌面 Linux 和 macOS 上已经跑了二十多年它通过实现 Windows 的 API 把 PE 格式的可执行文件直接翻译成宿主系统能理解的调用不需要虚拟机也不需要把整个 Windows 塞进去。问题在于iOS 是一个封闭得多的环境没有普通的进程派生权限没有可写的系统目录JIT 编译还受到严格限制所以把 Wine 移植到 iOS 上难度比桌面端高出一个量级。我做这个方向的整理起因是身边不少朋友在问同一类问题手机上能不能玩老 Windows 游戏、能不能跑某个只有 exe 的行业工具、FEX-Emu 和 DXMT 到底在整条链路里扮演什么角色。这些问题背后其实是一条完整的技术栈Wine 负责 Windows API 翻译FEX-Emu 负责 x86-64 到 ARM64 的指令翻译DXMT 负责把 Direct3D 调用翻译成 Metal三者叠在一起才能在 iPhone 或 iPad 的 ARM 芯片上把一个 x86-64 的 Windows 程序跑起来。Madeira 就是把这套东西打包、适配、调优之后的一个集成方案。这篇文章适合三类人看一是想在 iOS 上跑 Windows 程序、但被各种名词绕晕的普通用户二是做 iOS 开发、想了解兼容层怎么和系统限制博弈的工程师三是单纯对 Wine、FEX-Emu、DXMT 这套组合好奇的技术爱好者。我会把整条链路的原理、关键参数、实操步骤、踩坑经验都摊开讲尽量让没有底层经验的人也能看懂每一步在干什么。2. 整体架构拆解Wine、FEX-Emu、DXMT 各自管什么2.1 三层翻译栈的分工逻辑要理解 Madeira先得把这三层拆清楚。很多人一上来就把 Wine 当成模拟器这是最常见的误解。Wine 的全称是 Wine Is Not an Emulator它不做指令级模拟它做的是一套 API 兼容层当 Windows 程序调用CreateWindowEx、ReadFile这些函数时Wine 提供同名的实现把这些调用转成宿主系统的对应操作。所以在 x86 的 Linux 上跑 x86 的 Windows 程序Wine 几乎不损失性能因为指令集是一样的。但 iOS 设备是 ARM64 架构Windows 程序绝大多数是 x86 或 x86-64指令集对不上这时候就需要第二层FEX-Emu。FEX-Emu 是一个 x86-64 到 ARM64 的二进制翻译器它把 x86-64 指令动态翻译成 ARM64 指令。这里有个关键点FEX-Emu 用的是 JIT即时编译而 iOS 对 JIT 有严格限制这是整个方案里最棘手的地方之一。第三层是图形。Windows 程序画图走的是 GDI 或 Direct3DiOS 上能用的图形 API 是 Metal。DXMT 的作用就是把 Direct3D 的调用翻译成 Metal让游戏和图形程序能真正显示出来。如果没有 DXMT很多程序能启动但黑屏或者直接崩溃。三层的关系可以这样理解FEX-Emu 让 x86-64 的指令能在 ARM 上执行Wine 让 Windows 的系统调用有对应的实现DXMT 让图形调用能落到 Metal 上。缺任何一层程序都跑不起来或者跑不完整。2.2 为什么选择这套组合而不是虚拟机有人会问为什么不直接在 iOS 上跑一个虚拟机装 Windows答案很现实iOS 不允许。虚拟化需要 hypervisor 权限普通 App 拿不到而且就算拿到了在手机上跑完整 Windows 的性能和功耗也是灾难。Wine 这套方案的优势在于轻量它不模拟硬件只翻译调用理论上性能损失比虚拟机小得多。代价是兼容性。Wine 不是万能的它实现的 Windows API 是子集遇到没实现的调用就会出问题。FEX-Emu 的翻译也有边界某些依赖特定指令行为的程序会跑飞。DXMT 对 Direct3D 的支持也有版本差异老游戏用 D3D9 通常比新游戏用 D3D12 更容易跑通。所以 Madeira 这类方案的实际体验很大程度上取决于你想跑的那个程序用了哪些 API。2.3 关键组件版本与选型考量在实际搭建时版本匹配是个大坑。Wine 的版本、FEX-Emu 的版本、DXMT 的版本之间是有依赖关系的不是随便拿最新版拼一起就能用。我实测下来比较稳的组合是 Wine 的某个稳定分支配合对应时期的 FEX-EmuDXMT 则要看它支持的 D3D 版本。下面这张表是我整理的各组件职责和选型要点组件核心职责选型要点常见坑WineWindows API 翻译选稳定分支别追最新开发版版本太新可能和 FEX 不兼容FEX-Emux86-64 到 ARM64 指令翻译关注 JIT 权限适配iOS 上 JIT 受限需特殊处理DXMTDirect3D 到 Metal 翻译按程序用的 D3D 版本选D3D12 支持不如 D3D9 成熟打包层整合上述组件为可安装形态注意签名和权限配置证书过期会导致无法启动这张表看着简单但每一项背后都是无数次试错。比如 Wine 的版本很多人习惯性去下最新版结果发现 FEX-Emu 还没适配程序一启动就崩。我的建议是先确定你要跑的程序再倒推需要的组件版本而不是先装最新版再找程序。3. 核心细节解析从 API 翻译到图形渲染的关键环节3.1 Wine 的 API 翻译机制与乱码问题根源Wine 最核心的工作是维护一张巨大的函数映射表。Windows 的kernel32.dll、user32.dll、gdi32.dll这些系统库Wine 都有对应的实现。当程序加载时Wine 的加载器会解析 PE 文件的导入表把对 Windows 函数的引用替换成 Wine 自己的实现。这个过程叫重定位。乱码问题是 Wine 用户遇到最多的现象之一热词里wine 乱码wine 栏是乱码出现频率很高。根源通常在字符编码。Windows 程序大量使用 GBK、Shift-JIS 这类本地编码而 Wine 在非中文 locale 下默认按 UTF-8 处理两边对不上就出乱码。解决办法有几个层次一是设置正确的 locale 环境变量让 Wine 知道该用哪种编码二是安装对应的字体Wine 自带的字体覆盖不全缺字也会显示成方块三是针对特定程序用LANG和LC_ALL强制指定编码。我踩过的一个坑是只设了LANGzh_CN.UTF-8但没装中文字体结果界面文字全是方块。后来把字体目录挂进去问题才解决。所以乱码要分两种情况看编码不对是乱码字体缺失是方块排查方向完全不同。3.2 FEX-Emu 的 JIT 困境与 iOS 限制FEX-Emu 的工作方式是程序执行到一段 x86-64 代码时FEX 把这段代码翻译成 ARM64 指令缓存起来下次再执行到就直接用缓存。这个翻译并缓存的过程就是 JIT。JIT 需要两块内存一块可写用来生成代码一块可执行用来运行代码。问题在于现代操作系统出于安全考虑通常不允许同一块内存既可写又可执行W^X 策略。iOS 对这件事管得特别严。普通 App 拿不到mprotect把内存改成可执行可写的权限除非走特定的系统接口。这就是为什么在 iOS 上跑 FEX-Emu 需要特殊处理也是为什么这类方案往往需要越狱或者特定的签名配置。热词里ios 开发者模式ios 自动化这些词某种程度上都和这类权限需求有关。在实际操作中如果 JIT 权限拿不到FEX-Emu 会退化成解释执行模式性能会掉一个数量级。我实测过一个简单的 Windows 程序JIT 模式下启动只要几秒解释模式下要等半分钟以上。所以 JIT 能不能开直接决定了这套方案是能用还是能用得舒服。3.3 DXMT 的图形翻译路径DXMT 处理的是图形管线。Windows 程序画一个三角形走的是 Direct3D 的DrawPrimitiveDXMT 要把它翻译成 Metal 的drawPrimitives。这中间的映射不是一对一的因为两套 API 的抽象层次和资源管理方式不同。一个典型的翻译路径是这样的程序创建 D3D 设备DXMT 创建对应的 Metal 设备程序创建顶点缓冲DXMT 在 Metal 里分配对应的 buffer程序设置着色器DXMT 把 HLSL 编译成 Metal Shading Language。每一步都有转换成本也有转换失败的可能。我遇到过的典型问题是着色器编译失败。某些老游戏的着色器用了 D3D9 特有的语法DXMT 的编译器不认结果就是画面全黑或者花屏。这种情况通常需要等 DXMT 更新或者找社区里已经适配好的配置。另一个常见问题是纹理格式不匹配D3D 的某些压缩纹理格式 Metal 不支持需要 CPU 端解压再上传性能会受影响。3.4 打包与签名让整套东西能在 iOS 上启动把 Wine、FEX-Emu、DXMT 编译好只是第一步真正让它们在 iOS 上跑起来还要过签名和权限这一关。iOS 的 App 必须签名才能安装签名证书有开发证书、企业证书、个人证书几种。开发证书需要设备 UDID 注册企业证书容易掉签个人证书有 7 天限制。热词里免费证书 iosxcode 从证书配置到上架全流程反映的就是这个环节的痛点。我的经验是自己折腾的话用开发证书配合自己的设备最稳虽然要每年续但不会突然掉签。企业证书看着方便但一旦被吊销所有装了的设备都打不开数据也可能丢。另外iOS 的开发者模式在较新版本里是必须手动开启的设置路径在隐私与安全性里不开的话连自己签的 App 都装不上。4. 实操过程从零搭建一套可运行的兼容环境4.1 环境准备与依赖梳理动手之前先把需要的东西列清楚。你需要一台能编译的电脑macOS 最好因为要处理 iOS 相关的工具链一台目标 iOS 设备以及各个组件的源码或预编译包。下面是我整理的准备清单编译机macOS装好 Xcode 和命令行工具目标设备iOS 设备系统版本别太新也别太旧太新可能权限更严太旧可能不支持某些 APIWine 源码从官方仓库拉稳定分支FEX-Emu 源码注意选支持 ARM64 宿主的分支DXMT 源码看它 README 里支持的 D3D 版本签名工具Xcode 自带的 codesign或者第三方签名工具字体包中文字体、常用西文字体解决乱码用这里有个容易被忽略的点编译机的 Xcode 版本要和目标 iOS 系统版本匹配。用太新的 Xcode 编译出的二进制可能在旧系统上跑不了用太旧的 Xcode又可能不支持新系统的某些特性。我一般会查一下目标系统对应的 Xcode 版本范围选一个中间值。4.2 编译 Wine 与 FEX-Emu 的关键参数编译 Wine 时配置参数决定了它支持哪些功能。下面是我常用的配置命令针对 iOS 交叉编译场景做了调整./configure \ --hostaarch64-apple-darwin \ --enable-win64 \ --disable-tests \ --without-x \ --with-coreaudio \ --with-freetype \ --prefix/path/to/install解释几个关键参数--hostaarch64-apple-darwin指定目标平台是 ARM64 的苹果系统--enable-win64开启 64 位支持因为现在大多数 Windows 程序是 64 位的--disable-tests跳过测试编译省时间--without-x因为 iOS 没有 X11--with-coreaudio和--with-freetype分别处理音频和字体。FEX-Emu 的编译更复杂一些因为它涉及 JIT需要处理内存权限。编译时要确保开启 ARM64 后端并且根据 iOS 的 JIT 限制调整配置。如果目标环境允许 JIT就开 JIT 支持如果不允许就得配成解释模式虽然慢但至少能跑。编译过程中最常见的错误是依赖缺失。Wine 依赖 freetype、fontconfig 这些库FEX-Emu 依赖一些底层工具。我的做法是先把依赖装齐再编译别边编边补那样容易出错还浪费时间。4.3 整合与打包把三层拼成一个可安装的 App编译出各个组件后要把它们整合到一个 App 包里。目录结构大致是这样的Madeira.app/ ├── Frameworks/ │ ├── wine.framework │ ├── fex.framework │ └── dxmt.framework ├── Resources/ │ ├── fonts/ │ └── wine-prefix/ └── Madeira (可执行文件)wine-prefix是 Wine 的瓶子目录里面模拟了 Windows 的 C 盘结构程序就装在这里面。字体目录放中文字体解决乱码。可执行文件是入口负责初始化环境、启动 Wine 服务器、加载目标程序。打包时要注意动态库的路径。iOS 对动态库加载有限制所有依赖库要么静态链接进去要么放在 Frameworks 目录并用正确的 rpath 引用。我踩过的坑是 rpath 写错App 启动时报找不到库排查了半天才发现是路径问题。4.4 签名、安装与首次运行配置打包完成后就是签名。用 Xcode 的话配置好证书和描述文件直接 archive 导出 ipa。用命令行的话codesign -f -s 证书名 Madeira.app给 App 签名然后打包成 ipa 安装。安装到设备后第一次运行要做几件事开启开发者模式设置里找信任证书设置-通用-关于本机-证书信任设置然后才能启动。启动后如果看到 Wine 的配置界面说明基础环境通了。接下来把 Windows 程序放进 wine-prefix 的对应目录用 Wine 的命令行启动。首次运行往往会遇到各种报错别慌看日志。Wine 的日志会告诉你缺哪个 DLL、哪个 API 没实现。根据日志逐个解决大部分问题都能搞定。5. 常见问题与排查技巧实录5.1 启动类问题速查程序启动不了是最常见的问题原因五花八门。我整理了一张速查表按现象找原因现象可能原因排查方向双击无反应签名问题或权限不足检查证书信任、开发者模式闪退缺少依赖 DLL看 Wine 日志的导入表错误卡在启动画面JIT 未生效或翻译慢确认 JIT 权限看是否走了解释模式报错找不到文件路径映射错误检查 wine-prefix 的 drive_c 结构提示 API 未实现Wine 版本不支持该调用升级 Wine 或找替代实现排查启动问题的核心是看日志。Wine 的WINEDEBUG环境变量可以控制日志级别WINEDEBUGall会输出所有调试信息但信息量巨大一般用loaddll看 DLL 加载relay看 API 调用。日志里出现err:开头的行要重点关注那通常是问题根源。5.2 显示与乱码问题处理乱码和显示异常是另一大类问题。前面说过乱码分编码问题和字体问题。编码问题通过设置 locale 解决字体问题通过装字体解决。具体操作# 设置中文 locale export LANGzh_CN.UTF-8 export LC_ALLzh_CN.UTF-8 # 把字体复制到 Wine 的字体目录 cp /path/to/simsun.ttc ~/.wine/drive_c/windows/Fonts/显示异常还包括分辨率不对、窗口大小异常、画面撕裂等。分辨率问题通常和 DXMT 的缩放设置有关可以在配置里指定输出分辨率。窗口大小异常可能是 Wine 的虚拟桌面设置没开开虚拟桌面能让窗口管理更可控。我遇到过一个奇葩问题程序界面正常但菜单栏是乱码。查了半天发现是菜单用的字体和主界面不同主界面字体装了菜单字体没装。所以装字体要装全别只装一个。5.3 性能优化与卡顿排查性能是 iOS 上跑 Wine 的另一个痛点。卡顿可能来自几个方面JIT 没开导致翻译慢、图形翻译开销大、内存不足、CPU 降频。排查顺序建议从 JIT 开始确认 JIT 生效后再看图形设置。图形方面的优化手段包括降低渲染分辨率、关闭抗锯齿、简化着色器。DXMT 的配置里通常有这些选项。另外iOS 设备发热后会降频长时间跑重负载程序性能会逐渐下降这是硬件限制软件层面只能缓解。内存方面iOS 对单个 App 的内存占用有限制跑大型程序容易触发内存警告然后被杀。解决办法是尽量精简 wine-prefix别装不必要的组件程序本身也选轻量的。5.4 几个我踩过的坑和独家技巧第一个坑是证书过期。用个人证书签的 App7 天后就打不开了得重新签。我的做法是写个脚本定期自动重签省得手动操作。第二个坑是 Wine 版本和程序不匹配。有些程序需要特定版本的 Wine新版反而不行。我的做法是准备几个不同版本的 Wine按程序切换。第三个技巧是善用社区配置。很多热门程序已经有人调好了配置直接拿来用能省大量时间。配置通常包括需要的 DLL 覆盖、注册表设置、图形参数等。第四个技巧是日志分级。别一上来就开全量日志先开loaddll看加载有问题再细化。全量日志能把人淹死。6. 影响范围与适用边界6.1 能跑什么、跑不了什么Madeira 这套方案的能力边界取决于三层组件的成熟度。能跑得比较好的通常是这几类老版本的 2D 游戏、用 D3D9 的 3D 游戏、不依赖复杂系统 API 的工具软件。跑得勉强的是 D3D11/12 的新游戏、依赖 .NET 或特定运行时的程序、需要硬件加速的视频处理。跑不了的是依赖内核驱动、需要特定硬件、用了未实现 API 的程序。这个边界不是固定的随着 Wine、FEX-Emu、DXMT 的更新能跑的东西会越来越多。但也要有心理预期不是所有 Windows 程序都能在 iOS 上跑有些程序可能永远跑不了。6.2 对 iOS 开发者的参考价值即使不直接做 Wine 移植这套方案对 iOS 开发者也有参考意义。它展示了如何在 iOS 的严格限制下做底层系统编程怎么处理 JIT 权限、怎么管理动态库、怎么做跨架构翻译。这些经验在做其他底层项目时也用得上。另外这套方案里用到的签名、打包、权限配置流程和正常 iOS 开发是相通的。了解这些对理解 iOS 的 App 生命周期和安全模型有帮助。6.3 后续可以扩展的方向如果这套基础环境搭起来了后续可以往几个方向扩展。一是做图形化的管理界面让用户不用命令行就能装程序、调配置。二是做程序兼容性数据库记录哪些程序能跑、需要什么配置。三是优化性能比如针对特定程序做翻译缓存、优化图形管线。我个人比较感兴趣的是兼容性数据库这个方向。现在跑一个程序要试半天如果有个库能直接查到配置效率会高很多。这个库可以社区共建每个人跑通的程序都贡献一条记录。最后分享一个小技巧如果你只是想跑某个特定程序别一上来就搭全套环境先搜一下有没有人已经跑通了直接抄配置。很多时候别人踩过的坑你不用再踩一遍。这套东西折腾起来费时间能省则省。