1. 项目缘起为什么要在 iOS 上折腾 Wine第一次看到 Madeira 这个代号很多人会以为是某个度假海岛或者葡萄酒品牌但在我们这群喜欢折腾跨平台兼容层的人眼里它指向的是一件更硬核的事情把 Windows 应用的运行能力搬到 iOS 设备上。热搜词里同时出现了 Wine、FEX-Emu、DXMT、x86-64 这几个关键词基本可以确定这个项目的核心命题——在 ARM 架构的 iPhone 或 iPad 上通过一层层翻译和兼容机制让原本为 Windows x86-64 编译的程序跑起来。这件事听起来像是天方夜谭但拆开看其实是一条清晰的链路。Wine 负责把 Windows 的 API 调用翻译成 POSIX 调用FEX-Emu 负责把 x86-64 指令翻译成 ARM64 指令DXMT 负责把 Direct3D 调用翻译成 Metal 调用。三者叠加理论上就能在 iOS 上运行一部分 Windows 程序。Madeira 这个项目要做的就是把这套链路在 iOS 的沙盒环境里跑通并且尽量做到可安装、可配置、可复现。我关注这个方向有一段时间了。iOS 平台对可执行内存、动态链接、JIT 的限制非常严格普通 App 根本不允许加载外部二进制并执行所以这类项目要么走企业签名要么走自签工具要么依赖系统某些允许 JIT 的场景。热搜里出现的 ios开发者模式、免费证书ios、xcode从证书配置到上架全流程 这些词其实都指向同一个现实问题你想在 iOS 上跑非 App Store 的东西签名和权限是第一道坎绕不过去。这篇文章适合几类人看。第一类是喜欢在移动设备上折腾老游戏和 Windows 小工具的人想知道这条路到底能不能走通第二类是做 iOS 开发、对底层兼容层和指令翻译感兴趣的工程师想了解 Wine FEX-Emu DXMT 这套组合在 iOS 上的实际表现第三类是纯粹被 iOS 跑 Windows 程序 这个噱头吸引进来、想动手试一试的玩家。我会尽量把原理讲清楚把操作步骤写细把踩过的坑标出来让你少走弯路。2. 整体架构拆解Wine、FEX-Emu、DXMT 各自扮演什么角色2.1 三层翻译链路的分工逻辑要理解 Madeira 这类项目先得把三层翻译的分工搞清楚。很多人一上来就把 Wine 当成模拟器这是最常见的误解。Wine 的全称是 Wine Is Not an Emulator它不翻译 CPU 指令只翻译 API。Windows 程序调用CreateWindowEx、ReadFile、RegOpenKey这些函数时Wine 把这些调用映射到 Linux 或 macOS 或 iOS 底层对应的系统调用上。所以 Wine 解决的是 Windows 系统接口 到 类 Unix 系统接口 的转换问题。但光有 Wine 不够。Windows 程序绝大多数是 x86 或 x86-64 指令集编译出来的而 iPhone 和 iPad 用的是 ARM64。ARM64 的 CPU 根本不认识 x86-64 的机器码这时候就需要 FEX-Emu 出场。FEX-Emu 是一个用户态的 x86-64 到 ARM64 的二进制翻译器它把 x86-64 指令块动态翻译成 ARM64 指令块然后交给 CPU 执行。这个过程有性能损耗但比全系统模拟要轻量得多。第三层是图形。Windows 程序画界面、渲染 3D 用的是 Direct3D而 iOS 只认 Metal。DXMT 的作用就是把 D3D 的调用翻译成 Metal 的调用。热搜里出现 DXMT 而不是 DXVK说明这个项目走的是 Metal 原生路线而不是先转 Vulkan 再转 Metal。这样做的好处是少一层转换延迟更低但代价是 DXMT 的成熟度相对 DXVK 要低一些兼容性需要逐个程序去调。三层链路串起来就是Windows 程序发起 D3D 调用和 Win32 API 调用Wine 处理 API 翻译FEX-Emu 处理指令翻译DXMT 处理图形翻译最终落到 iOS 的系统调用和 Metal 上。任何一层出问题程序都跑不起来或者跑得很难受。2.2 为什么 iOS 是最难啃的平台同样一套组合在 Linux 桌面和 macOS 上已经相对成熟但搬到 iOS 上难度陡增。原因有几个。第一是 JIT 限制。FEX-Emu 需要把翻译后的代码写到可执行内存里再跳过去执行而 iOS 默认不允许普通 App 申请可执行内存除非开启 JIT 权限。这就是为什么热搜里反复出现 ios开发者模式——开启开发者模式后配合特定的签名方式才有可能拿到 JIT 能力。第二是沙盒限制。iOS 的每个 App 只能访问自己的沙盒目录Wine 需要模拟一个 Windows 的目录结构包括 C 盘、注册表、临时目录这些都得在沙盒里虚拟出来。第三是签名和分发。你没法把这样一个东西直接上架 App Store因为违反了审核指南里关于可执行代码下载的规定。所以实际分发只能靠自签、企业签或者 TestFlight 这类方式而热搜里 免费证书ios、xcode打包ios突然很慢如何解决 这些词反映的正是自签过程中的真实痛点。第四是图形栈的差异。iOS 的 Metal 和桌面平台的图形 API 差异不小DXMT 在 iOS 上要处理的边界情况更多比如后台切换、屏幕旋转、多任务分屏热搜里的 ios分屏都会影响渲染上下文的生命周期。这些在桌面端不是问题在移动端就是必须处理的细节。2.3 方案选型的取舍为什么是 FEX-Emu 而不是 QEMU有人会问既然要跑 x86-64为什么不用 QEMU 做全系统模拟答案很简单性能。QEMU 的全系统模拟要模拟 CPU、内存控制器、各种外设开销巨大在手机上跑 Windows 程序基本是幻灯片级别。FEX-Emu 是用户态翻译只翻译程序本身的指令系统调用直接走宿主系统开销小得多。代价是 FEX-Emu 对某些依赖特定 CPU 特性的程序支持不好比如用了 AVX-512 或者某些老式指令集的程序可能会崩。另一个取舍是 DXMT 和 DXVK 的选择。DXVK 走 Vulkan而 iOS 没有原生 Vulkan 驱动得再套一层 MoltenVK 把 Vulkan 转成 Metal链路更长延迟更高。DXMT 直接对接 Metal链路短但需要针对 Metal 的特性做适配。Madeira 选择 DXMT说明项目目标是尽量压低图形延迟优先保证能跑起来且跑得顺而不是追求最大兼容性。3. 环境准备从签名到 JIT 权限的完整链路3.1 iOS 开发者模式与签名方式的选择在 iOS 上跑这类项目第一步不是装 Wine而是解决签名和权限。你需要一台能装 Xcode 的 Mac一个 Apple ID以及足够的耐心。免费 Apple ID 可以签 7 天有效期的证书每次到期要重新签适合尝鲜付费开发者账号每年 99 美元可以签 1 年适合长期使用。热搜里 免费证书ios 和 xcode从证书配置到上架全流程 反映的就是这个环节的两种典型需求。具体操作上你需要用 Xcode 创建一个空壳 App 工程把 Madeira 的二进制和资源文件打包进去然后配置签名。关键点在于 entitlements 文件里要申请com.apple.security.cs.allow-jit和com.apple.security.cs.allow-unsigned-executable-memory这两个权限。前者允许 JIT后者允许可执行内存。没有这两个权限FEX-Emu 根本没法工作。注意申请 JIT 权限后App 只能在开启了开发者模式的设备上运行。开启开发者模式的路径是设置 - 隐私与安全性 - 开发者模式重启后生效。热搜里 ios 26.3.1怎么开发者模式 问的就是这个不同 iOS 版本路径略有差异但大体逻辑一致。签名完成后用 Xcode 直接安装到设备或者导出 ipa 用自签工具安装。这里有个坑如果你用的是免费证书App 的 Bundle ID 必须唯一不能和别人冲突否则签名会失败。建议用类似com.你的名字.madeira这种格式。3.2 目录结构与 Wine Prefix 的初始化装好 App 后第一次启动会初始化 Wine 的 prefix。所谓 prefix就是 Wine 模拟出来的 Windows 目录结构通常包含drive_c、windows、Program Files等目录。Madeira 一般会把这个 prefix 放在 App 的沙盒目录里比如Documents/prefix。初始化 prefix 的过程其实就是运行winebootWine 会创建注册表文件、系统目录、默认的 DLL 链接。这个过程在桌面端几秒钟就完成但在 iOS 上因为要翻译指令可能要等一两分钟。如果卡住不动多半是 JIT 权限没生效或者 FEX-Emu 的缓存目录没有写权限。实操心得prefix 初始化完成后建议立刻把整个 prefix 目录备份一份。因为后续装程序、改注册表很容易把 prefix 搞坏有备份就能快速回滚不用重新初始化。目录结构上你需要关注几个关键位置。drive_c/windows/system32放的是 Wine 自带的 DLLdrive_c/Program Files是你装 Windows 程序的地方drive_c/users/你的用户名是用户目录。DXMT 的 DLL 通常要覆盖到 system32 里替换掉 Wine 自带的 d3d11.dll、dxgi.dll 等文件。3.3 FEX-Emu 的配置与缓存优化FEX-Emu 在 iOS 上的配置主要通过环境变量控制。常用的几个变量包括FEX_APP_CONFIG指定配置文件路径FEX_ROOTFS指定根文件系统路径FEX_CACHE指定翻译缓存目录。翻译缓存非常重要因为 FEX-Emu 第一次遇到某段 x86-64 代码时要现场翻译翻译结果缓存下来下次就直接用能大幅提升启动速度。配置文件的格式是 JSON核心字段包括RootFS、ThunkHostLibs、ThunkGuestLibs等。Thunk 机制是 FEX-Emu 的一个亮点它允许 guest 程序直接调用 host 的库函数而不需要走完整的翻译流程。比如图形调用可以通过 thunk 直接进到 DXMT省掉一层翻译开销。注意FEX-Emu 的缓存目录要放在可写位置并且要有足够的空间。翻译缓存可能达到几百 MB如果沙盒空间不够程序会莫名其妙崩溃。建议定期清理不再使用的缓存。4. 核心实操从零跑通一个 Windows 程序4.1 安装 Wine Gecko 与 MonoWine 运行很多程序时需要 Gecko用于 HTML 渲染和 Mono用于 .NET。热搜里 wine gecko官方正版下载 说明很多人卡在这一步。在 iOS 上这两个组件不能像桌面端那样自动下载因为沙盒限制了网络访问和文件写入。你需要提前把 Gecko 和 Mono 的 msi 安装包放进 prefix 的对应目录然后手动触发安装。具体做法是把wine-gecko-x.x.x-x86.msi和wine-mono-x.x.x.msi放到drive_c/windows/temp或者 prefix 根目录然后用wine msiexec /i 路径安装。如果程序提示缺少 Gecko 或 Mono但你又不想装可以在winecfg里把对应的提示关掉不过很多程序会因此功能不全。实操心得Gecko 和 Mono 的版本要和 Wine 版本匹配。版本不匹配时Wine 会反复弹窗提示安装很烦人。建议先查清楚 Madeira 内置的 Wine 版本再下载对应版本的 Gecko 和 Mono。4.2 配置 DXMT 与图形后端DXMT 的配置是图形能否正常显示的关键。你需要把 DXMT 的d3d11.dll、dxgi.dll、d3d10core.dll等文件复制到drive_c/windows/system32覆盖 Wine 自带的版本。然后在注册表里设置 DXMT 的相关键值比如HKEY_CURRENT_USER\Software\Wine\Direct3D下的renderer设为metal。DXMT 还支持一些环境变量来调优比如DXMT_FRAME_RATE限制帧率DXMT_SHADER_CACHE指定着色器缓存路径。着色器缓存和 FEX 的翻译缓存一样重要第一次运行某程序时着色器要现场编译会卡顿缓存之后就流畅了。注意DXMT 对 Metal 的版本有要求太老的设备可能不支持某些特性。iPhone 8 及以后的设备一般没问题更老的设备建议降低期望。4.3 运行第一个程序以记事本为例理论讲完动手跑一个最简单的程序验证链路。把 Windows 的notepad.exe复制到drive_c/Program Files/notepad然后在 Madeira 的终端里执行wine notepad.exe。如果一切正常你应该能看到记事本窗口弹出来。这个过程会依次触发 FEX-Emu 翻译 notepad 的 x86-64 指令Wine 翻译 Win32 API 调用DXMT 翻译图形调用。第一次运行会比较慢因为要建立缓存。如果窗口没出来先看终端日志常见错误包括 JIT 权限不足、DLL 缺失、Metal 设备创建失败。跑通记事本后可以试试更复杂的程序比如老版本的 Winamp 或者一些小游戏。每换一个程序都可能遇到新的兼容性问题这就是折腾的乐趣所在。5. 常见问题与排查技巧实录5.1 乱码问题Wine 栏乱码与字体配置热搜里 wine 乱码 和 wine 栏是乱码 出现频率很高说明这是最普遍的痛点。乱码的根源是字体缺失。Wine 默认使用系统字体渲染界面但 iOS 沙盒里没有 Windows 常用的宋体、微软雅黑等字体所以中文显示成方块或乱码。解决办法是往 prefix 的drive_c/windows/Fonts目录里放字体文件比如从合法渠道获取的simsun.ttc、msyh.ttf。然后修改注册表把HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\FontSubstitutes下的字体映射改对。比如把MS Shell Dlg映射到Microsoft YaHei。实操心得字体文件不要贪多放两三个常用的就行。字体太多会拖慢 Wine 启动速度而且有些字体文件本身有问题会导致渲染崩溃。5.2 程序崩溃与日志分析程序崩溃是家常便饭关键是要会看日志。Wine 的日志通过WINEDEBUG环境变量控制比如WINEDEBUGall输出所有调试信息WINEDEBUGd3d11只看 D3D11 相关。日志量大得惊人建议重定向到文件再慢慢看。常见崩溃原因有几类。一是缺少 DLL日志里会有err:module:import_dll字样解决办法是找到对应的 DLL 放进 system32。二是指令不支持日志里会有 FEX-Emu 的报错说明程序用了 FEX 还没实现的指令只能等更新或者换程序。三是图形初始化失败日志里会有 DXMT 或 Metal 的报错通常是设备不支持或者着色器编译失败。5.3 性能调优让程序跑得更顺性能调优是个细活。首先确保 FEX 和 DXMT 的缓存都生效缓存命中率高的时候帧率能提升一大截。其次可以调整 FEX 的翻译块大小块越大翻译开销越小但内存占用越高。再次是关闭不必要的后台进程iOS 的内存管理很激进后台 App 多了会挤压前台的内存。还有一个技巧是降低分辨率。很多 Windows 程序默认按桌面分辨率渲染在手机上跑压力很大。可以在winecfg里把虚拟桌面分辨率调低比如 1280x720能明显改善流畅度。问题现象可能原因排查方向解决办法启动即崩溃JIT 权限不足检查 entitlements重新签名并开启开发者模式界面乱码字体缺失查看 Fonts 目录放入中文字体并改注册表图形花屏DXMT 配置错误查看 DXMT 日志覆盖正确 DLL 并设 renderer运行卡顿缓存未生效检查缓存目录确保缓存可写并预热程序无响应指令不支持查看 FEX 日志换程序或等 FEX 更新6. 影响范围与后续扩展方向6.1 这套方案能覆盖哪些场景Madeira 这类项目最直接的应用场景是运行老 Windows 游戏和小工具。很多经典游戏只有 Windows 版官方也没有移植到移动端的计划通过这套方案能在手机上重温。其次是运行一些 Windows 独占的办公或开发工具比如某些老版本的 IDE 或者专用软件。从技术角度看这套方案的价值在于验证了 ARM64 设备上运行 x86-64 Windows 程序的可行性。随着 FEX-Emu 和 DXMT 的成熟兼容性和性能都会逐步提升。热搜里 ios游戏、银行模拟器ios 这些词反映的正是用户对在 iOS 上运行特定 Windows 程序的真实需求。6.2 后续可以尝试的优化方向一个方向是优化 thunk 机制让更多调用绕过完整翻译直接进到 host 库。另一个方向是改进着色器缓存策略减少首次运行的卡顿。还有就是适配更多的 iOS 版本和设备特别是分屏、外接显示器这些场景。如果你对这个方向感兴趣建议先从跑通记事本开始然后逐步尝试更复杂的程序。每解决一个兼容性问题你对整个链路的理解就深一层。这个过程很磨人但跑通的那一刻成就感也是实打实的。我个人在实际操作中的体会是这类项目的门槛不在技术原理而在耐心。签名、权限、缓存、字体、DLL每一个环节都可能卡住你半天。但只要把日志看明白把缓存配好大部分问题都能解决。最后再分享一个小技巧遇到搞不定的程序先去 Wine 的应用数据库查一下看看别人在桌面端是怎么配置的很多经验可以直接搬过来用。