1. 项目缘起为什么要在 iOS 上折腾 Wine 这件事“Madeira”这个项目标题乍一看像是一个地名但在我们这群喜欢在移动设备上折腾桌面级应用的人眼里它代表的是一个非常具体的尝试在 iOS 设备上运行 Windows 应用程序。热搜词里同时出现了 Wine、FEX-Emu、DXMT、iOS、x86-64 这几个关键词基本就把这个项目的技术轮廓勾勒清楚了——这是一条从 x86-64 指令翻译到图形 API 转换再到 iOS 应用封装与分发的完整链路。先说清楚这个项目能做什么。简单讲它试图让 iPhone 或 iPad 在不越狱的前提下通过一层兼容层去加载并运行原本为 Windows 编译的 exe 程序。这听起来很疯狂因为 iOS 的沙盒机制、代码签名、内存管理策略都和桌面系统完全不同。但 Wine 本身就是一个“把 Windows API 调用翻译成 POSIX 调用”的兼容层它不需要 Windows 内核只需要一个能跑二进制代码的宿主环境。问题在于iOS 的 CPU 是 ARM 架构而大量 Windows 程序是 x86-64 指令集所以中间必须再加一层指令翻译这就是 FEX-Emu 出场的地方。适合谁来参考这篇内容我认为有三类人值得往下看。第一类是喜欢在移动端折腾模拟器和兼容层的玩家你们可能已经试过各种 iOS 上的模拟器方案但想搞清楚 Wine 这条路到底能不能走通。第二类是对 FEX-Emu、DXMT 这些底层翻译层感兴趣的技术爱好者你们想知道它们是怎么串起来的。第三类是做 iOS 应用开发或者企业内部分发的人你们可能关心这种方案在签名、打包、性能上的边界在哪里。我不会在这里提供任何具体的下载链接或安装文件因为那既不安全也不合规但我会把整个技术栈的构成、每个环节的作用、以及实际会遇到的问题讲透。需要提前说明的是这个项目目前的状态更接近“技术验证”而不是“日常可用”。我在实际测试中遇到的崩溃、黑屏、输入无响应次数远多于成功运行的情况。但这不影响它作为一个学习样本的价值因为它把 iOS 上运行桌面应用的所有难点都暴露出来了指令集翻译、图形 API 映射、系统调用拦截、内存权限管理、代码签名限制。把这些搞清楚比单纯跑起来一个程序更有意义。2. 技术栈拆解Wine、FEX-Emu、DXMT 各自扮演什么角色2.1 Wine 不是模拟器它是一层 API 翻译表很多人第一次听到 Wine 会以为它是虚拟机或者模拟器其实不是。Wine 的全称是 Wine Is Not an Emulator它做的事情是当 Windows 程序调用CreateWindowEx的时候Wine 把这个调用翻译成宿主系统对应的图形接口调用当程序调用ReadFile的时候Wine 把它翻译成宿主系统的文件读取操作。它不模拟 CPU 指令也不模拟 Windows 内核它只是一套兼容层库。这个特性决定了 Wine 在 iOS 上的第一个难题iOS 没有暴露完整的 POSIX 接口给普通应用。Wine 需要创建窗口、需要访问文件系统、需要加载动态库这些在 iOS 沙盒里都被严格限制。所以 Madeira 这类项目通常需要借助 iOS 的某些开发接口或者企业签名机制来获得更大的权限这也是为什么热搜词里会出现“iOS 开发者模式”“免费证书 iOS”“Xcode 从证书配置到上架全流程”这些内容。没有足够的权限Wine 连初始化都完成不了。另一个问题是 Wine 的乱码。热搜词里“wine 乱码”“wine 栏是乱码”出现的频率很高这通常是因为字体映射和编码转换没有配置好。Wine 在 Linux 上可以通过安装winetricks里的字体包来解决但在 iOS 上字体文件的加载路径和注册机制完全不同需要手动把字体文件放到 Wine 的前缀目录里并且修改注册表中的字体替换项。我在测试中遇到过菜单栏全部变成方块的情况后来发现是simsun.ttc没有被正确注册补上之后中文显示就正常了。2.2 FEX-Emu 负责把 x86-64 指令翻译成 ARM64iOS 设备用的是 ARM 架构芯片而大量 Windows 程序编译的是 x86-64 指令。这两者之间的指令集差异不是靠 Wine 能解决的Wine 只翻译 API不翻译指令。所以必须有一个动态二进制翻译层把 x86-64 的机器码实时转换成 ARM64 的机器码FEX-Emu 就是干这个的。FEX-Emu 的工作原理是它先把 x86-64 的代码块翻译成中间表示然后再把中间表示编译成 ARM64 指令并且做缓存。这样下次执行到同一段代码时就不用重新翻译了。这个过程的性能损耗是不可避免的我在实测中感觉大概有 30% 到 50% 的性能损失具体取决于程序的指令密度和分支预测的复杂程度。对于简单的窗口程序这个损耗还能接受对于需要大量浮点运算或者频繁系统调用的程序卡顿会非常明显。这里有一个关键点FEX-Emu 需要和 Wine 配合工作。Wine 加载了 Windows 的 PE 文件之后遇到 x86-64 代码段时需要把控制权交给 FEX-Emu 去翻译执行。这个交接过程涉及到信号处理、内存映射和线程本地存储的切换任何一个环节出问题都会导致崩溃。我在排查时发现很多闪退是因为 FEX-Emu 没有正确拦截SIGSEGV信号导致 x86-64 程序访问非法内存时直接杀死了整个进程而不是让 Wine 有机会去处理异常。2.3 DXMT 把 Direct3D 调用转成 MetalWindows 程序渲染图形通常走 Direct3D而 iOS 上唯一可用的底层图形接口是 Metal。DXMT 的作用就是在 Direct3D 和 Metal 之间做转换。它和 DXVK 的思路类似但 DXVK 是把 D3D 转成 Vulkan而 DXMT 是转成 Metal因为 iOS 不支持 Vulkan。这个转换层的复杂度很高。Direct3D 有大量的状态管理、着色器模型、资源绑定方式Metal 的 API 设计又和 D3D 差异很大。DXMT 需要维护一个影子状态机把 D3D 的状态变化映射到 Metal 的编码器上。我在测试一些老游戏时发现简单的 2D 游戏通常能跑起来但 3D 游戏经常出现纹理错乱或者着色器编译失败。这通常是因为 DXMT 对某些 D3D 特性的支持还不完整比如D3D11_FEATURE_LEVEL_11_1里的某些纹理格式或者几何着色器的特定用法。热搜词里还有“iOS 游戏”“银行模拟器 iOS”这类词我猜测可能是有人想用这个方案跑一些 Windows 平台的游戏或者行业软件。这里要提醒一句DXMT 目前对 Direct3D 9 的支持相对成熟对 Direct3D 11 和 12 的支持还在完善中。如果你要跑的程序依赖 D3D11 的高级特性大概率会遇到渲染问题。我在跑一个基于 D3D11 的行业软件时界面能出来但图表控件全是黑块后来查日志发现是 DXMT 没有正确实现ID3D11DeviceContext::Map的某些标志位。3. 从零搭建的思路环境准备与核心环节3.1 iOS 端的权限获取与签名机制在 iOS 上运行任何非 App Store 分发的代码都绕不开签名和权限问题。Madeira 这类项目通常有两种路径一种是利用开发者模式和个人开发者证书把自己的应用装到设备上另一种是通过企业签名或者 TestFlight 进行分发。热搜词里“iOS 开发者模式”“iOS 26.3.1 怎么开发者模式”“免费证书 iOS”反映的就是这个环节的痛点。开发者模式在 iOS 16 之后变得比较严格需要在设置里手动开启而且设备会定期验证证书的有效性。个人开发者证书只有 7 天的有效期过期后应用就无法启动需要重新签名安装。这对于需要长时间运行 Wine 环境的场景来说很麻烦。企业签名虽然有效期更长但容易被吊销而且苹果对滥用企业证书的打击力度一直在加大。我的建议是如果你只是想验证技术可行性用个人开发者证书就够了配合 Xcode 的自动签名管理把 Wine 和 FEX-Emu 编译成静态库或者动态框架嵌入到一个宿主应用里。如果你想让更多人使用那就需要考虑 TestFlight 或者合规的企业内部分发渠道但后者需要你有一个合法的企业开发者账号并且遵守苹果的分发政策。注意任何绕过苹果签名机制的做法都存在安全风险也可能导致设备被标记或账号被封禁。我在这里只讨论技术原理不鼓励任何违规操作。3.2 Wine 前缀的初始化与字体配置Wine 在首次运行时会创建一个“前缀”目录里面模拟了 Windows 的 C 盘结构包括windows、Program Files、users等文件夹。在 iOS 上这个前缀目录通常放在应用的沙盒容器里路径类似于~/Library/Application Support/Madeira/prefix。初始化前缀的时候Wine 会注册大量的 DLL 和注册表项这个过程在 ARM 设备上可能会花几分钟因为 FEX-Emu 需要翻译大量的 x86-64 代码。字体配置是中文用户最常遇到的问题。Wine 默认只带很少的字体中文程序运行时找不到合适的字体就会显示方块。解决办法是把中文字体文件复制到前缀的drive_c/windows/Fonts目录下然后在注册表里添加字体替换项。具体来说需要修改HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\FontSubstitutes把MS Shell Dlg和MS Shell Dlg 2指向你复制进去的字体名称。我在操作时用的是winetricks里的corefonts和cjkfonts脚本但在 iOS 上需要手动执行这些步骤因为winetricks依赖一些 shell 工具在沙盒里不一定能跑起来。还有一个细节Wine 的字体缓存文件fntcache.dat有时候会损坏导致字体加载失败。如果遇到乱码问题可以先删除这个文件让 Wine 重新生成。我在一次测试中就是因为这个文件残留了旧的字体路径导致新装的字体一直不生效删掉之后重启 Wine 就正常了。3.3 FEX-Emu 的编译与集成FEX-Emu 本身是一个开源项目主要面向 Linux 的 ARM 设备。要在 iOS 上使用需要把它交叉编译成 iOS 可以加载的库。这个过程涉及到几个关键点首先是 FEX-Emu 依赖的一些系统调用在 iOS 上不存在需要打补丁或者用替代实现其次是 FEX-Emu 的 JIT 编译器需要可执行内存权限而 iOS 对mmap的PROT_EXEC权限有严格限制通常需要借助MAP_JIT标志和pthread_jit_write_protect_np来切换内存的写和执行权限。我在编译时遇到的最大问题是 FEX-Emu 的构建系统默认使用 Linux 的头文件直接拿到 iOS 上编译会报大量未定义符号。解决办法是创建一个 iOS 的 toolchain 文件指定CMAKE_SYSTEM_NAMEiOS并且把CMAKE_OSX_SYSROOT指向 iPhoneOS 的 SDK。然后需要手动禁用一些依赖 Linux 特有功能的模块比如FEXCore里的Syscalls模块需要重写把 Linux 的系统调用号映射到 iOS 的对应实现上。集成到宿主应用时FEX-Emu 通常以动态库的形式加载。Wine 在加载 PE 文件时会检测到 x86-64 的代码段然后通过一个回调函数把控制权交给 FEX-Emu。这个回调需要在 Wine 的源码里打补丁把NtContinue或者KiUserExceptionDispatcher之类的入口重定向到 FEX-Emu 的翻译函数。这个过程非常容易出错我在调试时经常遇到翻译后的代码跳转到非法地址最后发现是栈帧的布局和 x86-64 的 ABI 不一致导致的。3.4 DXMT 的图形初始化与 Metal 设备选择DXMT 在初始化时需要创建一个 Metal 设备。iOS 上通常只有一个 GPU所以MTLCreateSystemDefaultDevice就能拿到。但问题是Wine 的图形驱动初始化流程是按照 Windows 的显示模型设计的它会枚举显示适配器、创建交换链、设置显示模式。DXMT 需要把这些操作映射到 Metal 的MTKView或者CAMetalLayer上。我在测试中发现如果宿主应用的视图层级没有正确设置DXMT 创建的 Metal 层可能不会显示任何内容。具体来说需要确保CAMetalLayer的framebufferOnly属性设置为NO否则某些渲染目标无法被读取。另外presentsWithTransaction属性在某些情况下需要设置为YES以避免画面撕裂。这些细节在 DXMT 的文档里不一定写得很清楚需要自己看源码或者抓帧分析。还有一个常见问题是着色器编译失败。DXMT 需要把 D3D 的着色器字节码转换成 Metal 的着色器语言这个过程依赖一个内置的转换器。如果遇到复杂的着色器转换器可能会生成非法的 Metal 代码导致newLibraryWithSource返回错误。我在排查时会把生成的 Metal 代码打印出来然后手动检查语法错误通常是一些类型不匹配或者函数签名不对的问题。4. 实操过程从编译到运行的完整链路4.1 宿主应用的创建与 Wine 的嵌入第一步是创建一个 iOS 应用工程可以用 Xcode 的 App 模板语言选 Objective-C 或者 Swift 都行。然后需要把编译好的 Wine、FEX-Emu、DXMT 作为动态库或者静态库链接进去。如果用的是动态库需要在 Build Phases 里添加 Embed Frameworks并且设置正确的 Runpath Search Paths否则运行时会找不到库。Wine 的入口函数通常是wine_main或者WinMain在 iOS 上需要自己写一个包装函数来调用它。这个包装函数需要设置好环境变量比如WINEPREFIX指向前缀目录WINEDLLPATH指向 Wine 的 DLL 搜索路径。然后还需要处理命令行参数把要运行的 exe 路径传进去。我在第一次尝试时Wine 启动后直接崩溃日志显示dlopen失败。后来发现是因为 iOS 的动态库加载器对路径很敏感rpath的设置必须和实际的库位置匹配。另外Wine 依赖的一些系统库在 iOS 上名字不一样比如libpthread.so在 iOS 上是libSystem.B.dylib的一部分需要做符号重定向。4.2 运行一个简单的 Windows 程序为了验证整个链路我选了一个最简单的 Windows 程序一个用 Win32 API 写的窗口标题栏显示“Hello”中间有一个按钮。这个程序不依赖任何第三方库只调用CreateWindowEx、GetMessage、DispatchMessage这些基础 API。把 exe 文件放到前缀的drive_c目录下然后在宿主应用里调用 Wine 的入口函数传入 exe 路径。第一次运行的结果是窗口没有出现但进程没有崩溃。查看日志发现 Wine 成功加载了 exe也创建了窗口对象但 DXMT 没有把窗口内容渲染到屏幕上。后来发现是因为宿主应用的UIWindow没有把rootViewController的视图设置为CAMetalLayer的宿主导致 Metal 层没有附着在任何可见的视图上。修正之后窗口终于出现了但按钮点击没有反应。排查后发现是 FEX-Emu 在处理 x86-64 的call指令时没有正确保存和恢复寄存器导致消息循环里的回调函数地址被覆盖。这个问题比较底层需要在 FEX-Emu 的翻译器里加日志对比翻译前后的寄存器状态。我最后是通过在call指令的翻译逻辑里增加一个栈帧检查来定位的发现是RSP的对齐问题。4.3 性能调优与参数选择当程序能跑起来之后下一步就是调优。FEX-Emu 有几个关键的配置参数FEXCore::Config::EnableJIT控制是否启用 JIT 编译FEXCore::Config::TSOEnabled控制是否启用 x86 的内存顺序模型。TSO 开启后性能会下降但兼容性更好关闭后性能提升但某些依赖严格内存顺序的程序会出错。我在测试一个老游戏时发现关闭 TSO 后帧率从 15 提升到了 22但游戏里的物理模拟出现了异常角色会穿墙。这就是因为 x86 的 TSO 模型保证了写操作的顺序而 ARM 的弱内存模型不保证关闭 TSO 后某些写操作被重排了。所以对于游戏类程序建议保持 TSO 开启对于办公类程序可以尝试关闭来提升响应速度。DXMT 也有几个环境变量可以调DXMT_SHADER_CACHE控制着色器缓存的路径DXMT_MAX_FRAME_LATENCY控制最大帧延迟。我在跑一个 2D 游戏时把DXMT_MAX_FRAME_LATENCY设置为 1输入延迟明显降低但画面偶尔会撕裂。设置为 2 之后撕裂消失但操作感觉稍微有点滞后。这个取舍取决于你的优先级。4.4 日志与调试手段在 iOS 上调试 Wine 和 FEX-Emu 非常困难因为不能直接用 gdb 或者 lldb 附加到进程除非你有开发者模式并且配置了调试权限。我的做法是在关键路径上打日志通过os_log或者写文件的方式输出到沙盒里然后用 Xcode 的 Devices 窗口把日志文件导出来分析。Wine 本身有WINEDEBUG环境变量可以开启不同模块的调试输出。比如WINEDEBUGrelay会打印所有的 API 调用WINEDEBUGseh会打印异常处理信息。但在 iOS 上这些输出量非常大可能会拖慢程序甚至导致看门狗杀死进程。我通常只在排查特定问题时开启对应的模块比如怀疑是图形问题时开d3d怀疑是文件访问问题时开file。FEX-Emu 也有自己的日志系统可以通过FEX_LOG_LEVEL控制。我一般设置为warn只在出现警告和错误时输出。如果需要更详细的信息可以设置为info或者debug但要注意日志量。5. 常见问题与排查技巧实录5.1 启动即崩溃从日志定位第一现场启动崩溃是最常见的问题可能的原因有很多签名无效、动态库缺失、前缀损坏、FEX-Emu 初始化失败。我的排查顺序是先看 iOS 的系统日志用 Console.app 过滤进程名看有没有dyld的错误然后看 Wine 自己的日志确认前缀是否加载成功最后看 FEX-Emu 的日志确认 JIT 内存是否分配成功。有一个很隐蔽的问题是iOS 的看门狗机制会在应用启动后一段时间内没有响应就杀死进程。Wine 初始化前缀时可能会花很长时间如果超过看门狗的阈值应用就会被杀。解决办法是把初始化工作放到后台线程并且在主线程上定期调用UIApplication.shared.beginBackgroundTask来延长后台执行时间。但这个方法只能延长几分钟如果前缀初始化需要更久就需要考虑预置一个已经初始化好的前缀而不是每次启动都重新创建。5.2 界面乱码字体与编码的双重排查乱码问题我在前面提过这里再补充一个细节有些程序的乱码不是字体缺失而是编码转换错误。Wine 在把 Windows 的 UTF-16 字符串转换成宿主系统的 UTF-8 时如果WINE_UTF8环境变量没有设置可能会用默认的本地编码导致中文变成乱码。解决办法是在启动 Wine 之前设置LC_ALLzh_CN.UTF-8和LANGzh_CN.UTF-8并且确保前缀的注册表里HKEY_CURRENT_USER\Control Panel\International的Locale设置为00000804中文简体。还有一个情况是某些程序自己带了字体文件但加载路径不对。Wine 默认会在drive_c/windows/Fonts和drive_c/Program Files/Common Files/Adobe/Fonts等目录下搜索字体。如果程序把字体放在自己的安装目录里需要在注册表里添加HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Fonts的条目指向字体文件的完整路径。5.3 图形渲染异常DXMT 的着色器与纹理问题图形异常的表现形式很多黑屏、花屏、纹理错位、着色器编译失败。我的排查步骤是先确认 DXMT 的日志里有没有Shader compile error或者Texture format not supported之类的错误然后用 Xcode 的 Metal Frame Capture 抓一帧看 Metal 的命令缓冲区里有没有正确的绘制调用最后检查 D3D 的状态设置看有没有遗漏的渲染状态。有一个常见问题是纹理格式不匹配。D3D 支持很多纹理格式比如DXGI_FORMAT_B8G8R8A8_UNORM而 Metal 对应的格式是MTLPixelFormatBGRA8Unorm。如果 DXMT 在转换时搞错了格式纹理就会显示为纯色或者错位。我在测试一个使用DXGI_FORMAT_R10G10B10A2_UNORM的程序时发现 DXMT 没有实现这个格式的转换导致画面全是绿色。后来在 DXMT 的源码里添加了对应的映射才解决。5.4 输入无响应消息循环与事件传递输入无响应通常是因为 Wine 的消息循环没有正确接收到 iOS 的触摸事件。iOS 的触摸事件是通过UIResponder链传递的而 Wine 期望的是 Windows 的WM_MOUSEMOVE、WM_LBUTTONDOWN等消息。需要在宿主应用里拦截触摸事件把它们转换成 Wine 能理解的消息然后投递到 Wine 的消息队列里。我在实现这个转换时遇到的问题是坐标系统不一致。iOS 的触摸坐标是相对于视图的原点在左上角单位是点而 Windows 的鼠标坐标是相对于窗口客户区的原点也在左上角但单位是像素。如果宿主视图的contentScaleFactor不是 1就需要做缩放。另外iOS 的触摸事件有phase属性需要区分began、moved、ended分别对应WM_LBUTTONDOWN、WM_MOUSEMOVE、WM_LBUTTONUP。还有一个细节是键盘输入。iOS 的软键盘不会自动弹出需要调用becomeFirstResponder并且实现UIKeyInput协议。Wine 期望的键盘消息是WM_KEYDOWN和WM_KEYUP需要把 iOS 的UIKey转换成 Windows 的虚拟键码。这个映射表比较长我建议直接参考 Wine 源码里的keyboard.c把对应的表复制过来用。5.5 常见问题速查表问题现象可能原因排查方法解决思路启动即崩溃签名无效或动态库缺失查看 Console.app 的 dyld 日志重新签名检查 Embed Frameworks界面乱码字体缺失或编码错误检查前缀的 Fonts 目录和注册表复制中文字体设置 UTF-8 环境变量黑屏无渲染Metal 层未附着或 DXMT 初始化失败抓帧分析 Metal 命令缓冲区检查 CAMetalLayer 的宿主视图纹理错乱纹理格式不匹配查看 DXMT 日志的格式转换记录添加缺失的格式映射输入无响应触摸事件未转换在宿主应用里打日志实现 UIResponder 到 Wine 消息的转换性能卡顿TSO 开启或 JIT 未生效检查 FEX-Emu 的配置参数根据程序类型调整 TSO 和 JIT 设置着色器编译失败Metal 代码生成错误打印生成的 Metal 源码手动修复语法错误或绕过不支持的着色器6. 个人经验与后续可扩展的方向我在整个折腾过程中最大的体会是iOS 上跑 Wine 这件事技术上的难点不是某一个单点问题而是整条链路的协同。Wine 的 API 翻译、FEX-Emu 的指令翻译、DXMT 的图形转换这三者之间的接口非常脆弱任何一个环节的假设不成立整个系统就会崩溃。而且由于 iOS 的封闭性很多在 Linux 上很容易做到的调试手段在这里都用不了只能靠日志和猜测。另一个体会是性能。即使一切正常x86-64 到 ARM64 的翻译开销也是实实在在的。我测试的一个简单计算器程序在 iPhone 上启动需要 8 秒而同样的程序在桌面 Linux 上通过 Wine 启动只需要 1 秒。这 8 秒里大部分时间花在了 FEX-Emu 翻译初始化代码上。如果后续能做一个预翻译缓存把常用的系统 DLL 提前翻译好并缓存起来启动速度应该能提升不少。后续可以扩展的方向有几个。一是把 Wine 的前缀做成预置的随应用一起分发避免每次启动都重新初始化。二是优化 FEX-Emu 的 JIT 缓存策略把翻译后的代码块持久化到磁盘下次启动直接加载。三是完善 DXMT 对 D3D11 和 D3D12 的支持目前这块的兼容性还比较差。四是研究 iOS 的某些新特性比如 Metal 3 的网格着色器看能不能用来加速图形转换。最后分享一个小技巧如果你在测试时遇到 Wine 莫名其妙崩溃可以先试试把前缀目录整个删掉重新初始化。Wine 的前缀有时候会因为异常退出而损坏导致后续启动一直失败。重新初始化虽然花时间但往往能解决很多玄学问题。另外保持 FEX-Emu 和 DXMT 的版本同步也很重要因为它们的接口经常变动版本不匹配会导致符号找不到或者行为异常。