iOS上运行Windows程序：Wine+FEX-Emu+DXMT兼容层实战

1. 项目缘起：为什么要在 iOS 上折腾 Wine 兼容层

第一次看到 "Madeira" 这个项目名，很多人会以为是那个葡萄牙的旅游海岛，但在我们这群喜欢折腾跨平台兼容层的人眼里，它指向的是另一件事：把 Windows 应用搬到 iOS 设备上跑起来。这个方向听起来有点反常识，毕竟 iOS 的沙盒机制、签名体系、架构限制摆在那里，但恰恰是这些限制，让 Madeira 这类项目变得有意思。

我做跨平台兼容这块差不多有十来年，从早期在 Linux 上编译 Wine 源码，到后来接触 FEX-Emu、DXMT 这些新工具链，踩过的坑能写满一个笔记本。Madeira 这个标题背后，核心诉求其实很明确：让 iOS 设备能够运行 x86-64 架构的 Windows 程序。注意这里有两个关键点，一是 x86-64 指令集的翻译，二是 Windows API 的兼容。前者靠 FEX-Emu 这类模拟器解决，后者靠 Wine 解决，而 DXMT 则是把 DirectX 调用翻译成 Metal，让图形渲染能在 iOS 的 GPU 上跑起来。

这套组合拳解决的是什么问题？简单说，就是让那些只有 Windows 版本、没有 iOS 版本的老软件、小工具、独立游戏，能在 iPhone 或 iPad 上跑起来。适合谁来参考？如果你是对兼容层技术感兴趣的开发者，或者手头有一堆 Windows 小工具想在 iPad 上用的折腾党，再或者你是做 iOS 开发想了解底层架构翻译原理的工程师，这篇内容都能给你一些可以直接抄作业的东西。

我先把话说在前面：这不是一个点一下就能用的成品方案，中间涉及签名、架构翻译、图形 API 转换、输入映射等一堆环节，任何一个环节出问题都会导致黑屏或者闪退。但正因为难，搞通之后的成就感也完全不一样。

2. 核心技术栈拆解：Wine、FEX-Emu、DXMT 各自扮演什么角色

2.1 Wine 在 iOS 上的定位与限制

Wine 的本质是一个 Windows API 兼容层，它把 Windows 程序发起的系统调用翻译成宿主系统的调用。在桌面 Linux 上，Wine 已经相当成熟，但到了 iOS 上，情况完全变了。iOS 不允许动态生成可执行代码，不允许 fork 进程，文件系统访问被严格限制在沙盒内，这些限制直接砍掉了 Wine 的一大半能力。

所以在 iOS 上跑 Wine，你不能指望它像在 Linux 上那样直接加载 exe 就跑。通常的做法是把 Wine 的组件编译成静态库或者动态库，嵌入到一个宿主 App 里，然后由这个 App 来加载 Windows 程序的 PE 文件。这个过程里，Wine 的 winserver 进程模型需要被改造，因为 iOS 不允许你起一个独立的服务进程。常见的做法是把 winserver 的逻辑塞进主进程的一个线程里，用 Mach 端口或者共享内存来模拟进程间通信。

还有一个绕不开的问题是乱码。热词里提到的 "wine 乱码" 和 "wine 栏是乱码"，本质上都是字符编码和字体缺失导致的。Wine 默认使用 UTF-8 和 Unicode，但很多 Windows 程序内部用的是 GBK 或者 ANSI 编码，如果宿主环境没有对应的字体和 locale 配置，菜单栏、按钮文字就会变成方块或者问号。解决办法是在 Wine 的注册表里把字体替换规则配好，同时把中文字体文件放进宿主 App 的资源目录，让 Wine 能加载到。

2.2 FEX-Emu 如何把 x86-64 指令翻译成 ARM64

iOS 设备清一色是 ARM 架构，而绝大多数 Windows 程序是 x86 或 x86-64 架构。要让这些程序跑起来，必须做指令集翻译。FEX-Emu 就是干这个的，它把 x86-64 指令动态翻译成 ARM64 指令，翻译的粒度是基本块级别，翻译结果会缓存起来，下次遇到同样的代码块就直接用缓存，不用重新翻译。

FEX-Emu 的工作流程大致是这样的：首先加载 x86-64 的 PE 文件，解析出代码段和数据段；然后从入口点开始，逐块读取 x86-64 指令，翻译成等价的 ARM64 指令序列；翻译过程中需要维护一套虚拟的 CPU 状态，包括通用寄存器、标志寄存器、浮点寄存器等，这些状态在翻译后的代码里用 ARM64 的寄存器和内存来模拟。

这里有个关键点：FEX-Emu 需要处理自修改代码。有些 Windows 程序会在运行时修改自己的代码段，这在 x86 上很常见，但在 ARM 上，代码段通常是只读的。FEX-Emu 的做法是监控代码段的写操作，一旦发现某块代码被修改，就把对应的翻译缓存失效掉，下次执行时重新翻译。这个机制会带来性能开销，但为了保证兼容性，不得不这么做。

2.3 DXMT 把 DirectX 调用翻译成 Metal

图形渲染是另一个大坑。Windows 程序通常调用 DirectX 来做渲染，而 iOS 只认 Metal。DXMT 的作用就是在中间做翻译，把 Direct3D 的调用转换成 Metal 的调用。这个翻译不是简单的函数映射，因为 Direct3D 和 Metal 的渲染管线模型有差异，资源管理方式也不同。

DXMT 的实现思路是拦截 Direct3D 的 API 调用，比如 CreateDevice、CreateTexture、DrawPrimitive 这些，然后在内部维护一套 Metal 的资源对象。当程序调用 DrawPrimitive 时，DXMT 会把当前的渲染状态、顶点缓冲、索引缓冲、着色器都转换成 Metal 对应的对象，然后提交一个 Metal 的 draw call。着色器的翻译是最复杂的部分，因为 HLSL 和 Metal Shading Language 语法不同，需要做源码级别的转换，或者用 SPIR-V 做中间表示再转成 Metal。

实测下来，DXMT 对 Direct3D 9 和 Direct3D 11 的支持相对好一些，Direct3D 12 的支持还在完善中。如果你要跑的程序用的是 Direct3D 12，可能会遇到渲染错误或者直接崩溃。这时候可以试试在 Wine 的配置里强制指定用 Direct3D 11 或者 9 来渲染，有些程序是支持回退的。

3. 从零搭建：iOS 上运行 Wine 兼容层的完整实操流程

3.1 环境准备与工具链配置

在开始之前，你需要一台 macOS 电脑，安装 Xcode，版本建议 15 以上。然后需要准备以下工具：

• FEX-Emu 源码：从官方仓库拉取，编译成 iOS 可用的静态库。注意要选对分支，有些分支是针对 Linux 的，编译到 iOS 上会缺头文件。
• Wine 源码：同样从官方仓库拉取，编译时需要用 iOS 的 SDK，并且要打一些补丁来绕过 iOS 的限制，比如禁用 fork、禁用动态代码生成。
• DXMT 源码：这个相对独立，编译成动态库后链接到宿主 App 里。
• iOS 签名证书：如果你只是自己测试，可以用免费的个人开发者证书，但要注意免费证书的有效期只有 7 天，过期后需要重新签名。热词里提到的 "免费证书 ios" 和 "ios 开发者模式" 就是在这个环节涉及的。

编译顺序很重要：先编译 FEX-Emu，因为它不依赖其他组件；然后编译 Wine，链接 FEX-Emu 的库；最后编译 DXMT，链接 Wine 的库。每一步都可能报错，常见的错误包括头文件路径不对、架构不匹配、符号未定义等。

提示：编译 FEX-Emu 时，记得在 CMake 参数里加上-DCMAKE_OSX_ARCHITECTURES=arm64，否则默认会编译成 x86-64，链接到 iOS App 时会报架构不匹配。

3.2 宿主 App 的创建与 Wine 库的集成

宿主 App 是一个普通的 iOS 应用，用 Swift 或者 Objective-C 写都行。它的主要职责是：初始化 Wine 运行环境、加载 Windows 程序的 PE 文件、提供图形渲染的宿主视图、处理输入事件。

创建宿主 App 的步骤：

1. 在 Xcode 里新建一个 iOS App 项目，界面用 Storyboard 或者 SwiftUI 都行。
2. 把编译好的 Wine、FEX-Emu、DXMT 的静态库和动态库拖进项目里，在 Build Phases 的 Link Binary With Libraries 里加上。
3. 在 Build Settings 里设置 Header Search Paths，指向 Wine 和 FEX-Emu 的头文件目录。
4. 创建一个继承自 UIView 的类，用来承载 Metal 的渲染层。DXMT 会往这个视图里提交渲染命令。
5. 在 AppDelegate 的 didFinishLaunchingWithOptions 里调用 Wine 的初始化函数，传入沙盒内的路径作为 Wine 的 C 盘根目录。

这里有个细节：iOS 的沙盒路径每次安装都会变，所以不能在代码里写死路径，要用 NSSearchPathForDirectoriesInDomains 动态获取。Wine 的注册表文件、字体文件、临时目录都要放在沙盒内，否则会因为没有写权限而失败。

3.3 加载 Windows 程序并处理输入映射

加载 Windows 程序的过程，本质上是调用 Wine 的wine_init和wine_load_exe函数。你需要把 Windows 程序的 exe 文件和它依赖的 dll 文件一起放进沙盒的一个目录里，然后把这个目录的路径传给 Wine。

输入映射是另一个需要仔细处理的地方。iOS 的触摸事件和 Windows 的鼠标事件模型不同，你需要把触摸事件转换成鼠标移动、左键点击、右键点击。如果程序需要键盘输入，还要把 iOS 的软键盘事件转换成 Windows 的键盘消息。实测下来，最简单的做法是提供一个虚拟鼠标指针，用户手指在屏幕上滑动时，指针跟着移动，点击屏幕就是左键点击，双指点击就是右键点击。

注意：有些 Windows 程序会检测鼠标是否在窗口内，如果指针移出窗口范围，程序可能会暂停渲染或者弹出提示。所以在做输入映射时，要确保指针坐标始终在窗口范围内，或者把窗口设成全屏模式。

4. 常见问题与排查技巧实录

4.1 启动就闪退：签名与权限问题

这是最常见的问题，表现是 App 图标点进去，白屏一秒然后闪退。原因通常是签名证书过期，或者 App 没有开启必要的权限。iOS 对动态库的加载有严格限制，如果你的 Wine 库是动态库，需要在 App 的 entitlements 文件里加上com.apple.security.cs.allow-dyld-environment-variables和com.apple.security.cs.disable-library-validation。

排查步骤：

1. 用 Xcode 的 Devices and Simulators 窗口查看设备日志，搜索 "dyld" 关键字，看是不是动态库加载失败。
2. 检查证书的有效期，如果过期了，重新签名。
3. 检查 entitlements 文件是否正确配置，可以用codesign -d --entitlements - YourApp.app命令查看。

4.2 界面乱码：字体与编码配置

热词里反复出现的 "wine 乱码" 问题，根源在于字体缺失和编码不匹配。Wine 默认会去找系统字体，但 iOS 的字体目录和 Linux 不同，Wine 找不到就会用内置的替代字体，而内置字体往往不包含中文字形，所以中文就变成了方块。

解决办法分两步：第一步是把中文字体文件（比如 Noto Sans CJK 或者文泉驿）复制到沙盒的 Wine 字体目录里；第二步是在 Wine 的注册表里配置字体替换规则，把 "Tahoma"、"Arial"、"Microsoft YaHei" 这些常用字体名映射到中文字体上。

注册表配置可以用 reg 文件导入，内容大概是这样的：

[HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\FontSubstitutes] "Arial"="Noto Sans CJK SC" "Tahoma"="Noto Sans CJK SC" "Microsoft YaHei"="Noto Sans CJK SC"

导入之后重启 Wine 环境，乱码问题基本就能解决。如果还有个别地方乱码，可能是程序内部硬编码了字体名，这时候需要用十六进制编辑器改 exe 文件里的字体名字符串，或者用 API hook 的方式在运行时替换。

4.3 图形渲染异常：DXMT 的兼容性调优

DXMT 虽然能把 DirectX 翻译成 Metal，但并不是所有 DirectX 调用都能完美转换。常见的渲染问题包括：纹理显示为黑色、模型缺失、画面闪烁、帧率极低。

排查思路：

• 先看日志，DXMT 会输出哪些 API 调用没有被正确处理，根据日志定位问题。
• 如果是纹理问题，检查纹理格式是否被 Metal 支持，有些 DirectX 的压缩纹理格式在 Metal 上没有对应，需要做软件解码。
• 如果是帧率低，可能是着色器翻译开销太大，可以试试开启 DXMT 的着色器缓存，把翻译结果存到磁盘上，下次直接加载。
• 如果是画面闪烁，可能是双缓冲或者垂直同步的问题，可以在 DXMT 的配置里强制开启垂直同步。

下面这个表格整理了我遇到过的典型渲染问题和对策：

问题现象	可能原因	解决方向
纹理全黑	纹理格式不支持	检查格式，必要时软件解码
模型缺失	顶点着色器翻译错误	查看 DXMT 日志，定位着色器
画面闪烁	缓冲策略不匹配	强制垂直同步，调整缓冲数量
帧率极低	着色器翻译开销大	开启着色器磁盘缓存
颜色偏差	色彩空间转换错误	检查 sRGB 配置

4.4 性能调优：让 x86-64 翻译跑得更快

FEX-Emu 的翻译开销是性能瓶颈的主要来源。实测下来，同样的程序，在原生 ARM64 上跑和在 FEX-Emu 翻译后跑，帧率可能差三到五倍。要提升性能，可以从这几个方面入手：

• 开启翻译缓存：FEX-Emu 支持把翻译后的代码块缓存到磁盘，下次启动时直接加载，省去重新翻译的时间。缓存文件放在沙盒的 Caches 目录里，注意 iOS 可能会在存储空间紧张时清理这个目录。
• 调整翻译块大小：FEX-Emu 默认的翻译块大小是 1 个基本块，可以调大一些，减少翻译次数，但会增加内存占用。需要根据设备的内存大小来权衡。
• 关闭不必要的调试功能：FEX-Emu 在编译时如果开启了调试符号和断言检查，运行时会慢很多。发布版本一定要用 Release 模式编译，关掉所有调试开关。
• 使用多线程翻译：FEX-Emu 支持多线程翻译，可以把不同的代码块分配到不同的线程上翻译，充分利用多核 CPU。但 iOS 对线程数量有限制，不能开太多。

提示：在 iPhone 上跑 Wine 兼容层，发热和耗电是不可避免的。建议插着电源用，并且不要长时间连续跑大型程序，否则设备会降频，帧率会越来越低。

5. 进阶玩法：从单机运行到自动化与扩展

5.1 用 iOS 自动化工具简化启动流程

每次启动都要手动点好几步才能进到 Windows 程序里，确实麻烦。iOS 自带的快捷指令（Shortcuts）可以帮上忙，你可以创建一个快捷指令，自动打开宿主 App，并且通过 URL Scheme 传入要加载的 exe 文件路径。宿主 App 在启动时解析这个 URL，直接加载对应的程序，省去手动选择的步骤。

如果要做更复杂的自动化，比如定时启动、根据条件启动，可以结合 iOS 的自动化触发条件，比如连接电源时启动、到达某个位置时启动。热词里提到的 "ios 自动化" 和 "ios 无感" 就是这个方向的应用。

5.2 多程序管理与文件系统隔离

当你需要在 iOS 上跑多个 Windows 程序时，文件系统的管理就变得重要了。每个程序可能需要不同的 dll 版本、不同的注册表配置，如果全部混在一起，很容易冲突。我的做法是给每个程序建一个独立的目录，目录里包含一个精简的 Wine prefix，只放这个程序需要的 dll 和注册表项。宿主 App 在加载时，根据程序名切换到对应的 prefix。

这样做的好处是隔离性好，一个程序出问题不会影响其他程序。坏处是每个 prefix 都会占用额外的存储空间，因为 Wine 的基础文件在每个 prefix 里都有一份。如果存储空间紧张，可以用符号链接把公共文件链接到同一个位置，但 iOS 对符号链接的支持有限，需要测试确认。

5.3 外设支持：手柄与键盘

iOS 支持蓝牙手柄和键盘，如果你要跑的是游戏，用手柄操作体验会好很多。Wine 本身不直接处理手柄输入，需要宿主 App 把 iOS 的 GameController 框架的事件转换成 Windows 的 XInput 或者 DirectInput 消息。这个转换层需要自己写，工作量不小，但一旦写好，兼容性会好很多。

键盘支持相对简单，iOS 的软键盘事件可以直接映射成 Windows 的键盘消息。但要注意，有些 Windows 程序会检测键盘布局，如果宿主环境没有正确设置键盘布局，程序可能会把按键识别错。可以在 Wine 的注册表里设置键盘布局为 "00000804"（中文简体）或者 "00000409"（美式英语），根据程序的需求来定。

6. 我个人在实际操作中的几点体会

折腾这套东西差不多花了小半年时间，中间有几次差点放弃。最大的感受是，iOS 的沙盒限制不是靠技术手段能完全绕过的，你只能在它的规则内找空间。比如动态代码生成被禁，FEX-Emu 就只能用解释执行加静态翻译的混合模式，性能损失是必然的。再比如进程模型被限制，Wine 的 winserver 就只能塞进主进程里，稳定性和桌面版没法比。

但话说回来，当你第一次在 iPad 上看到那个只有 Windows 版本的老工具跑起来，菜单栏的中文正常显示，鼠标指针跟着手指移动，那种感觉还是挺爽的。如果你也在折腾类似的东西，我的建议是先把最小闭环跑通：能加载一个最简单的 Windows 程序，能显示窗口，能响应点击。这个闭环跑通之后，再去解决乱码、图形、性能这些细节问题。不要一上来就想着跑大型游戏，那样很容易卡在某个环节出不来。

另外，编译 Wine 和 FEX-Emu 的时候，一定要有耐心。报错是常态，不报错才是意外。每次报错都仔细看日志，大部分问题都能在网上找到答案。实在找不到的，就去翻源码，看那个函数到底在做什么，往往比搜半天更有效。