1. 项目缘起为什么要在 iOS 上折腾 Wine 这件事“Madeira”这个项目标题乍一看像是个地名但在我们这群喜欢在移动端折腾桌面级应用的人眼里它指向的是一件事在 iOS 设备上运行 Windows 应用。热搜词里同时出现了 Wine、FEX-Emu、DXMT、x86-64 和 iOS这几个词凑在一起基本就把技术路线图给画出来了——用 Wine 做 Windows API 转译用 FEX-Emu 做 x86-64 到 ARM64 的指令翻译用 DXMT 把 Direct3D 调用映射到 Metal最终跑在 iOS 上。这套组合拳解决的是一个很实际的问题iOS 生态里没有原生的 Windows 应用运行环境而很多行业软件、老游戏、专业工具只有 Windows 版本。你想在 iPad 上打开一个十几年前的行业软件或者跑一个只有 exe 安装包的小工具App Store 里翻遍了也找不到替代品。Madeira 这类项目的价值就在这儿——它不是让你“模拟”一个 Windows而是让 Windows 程序以为自己还在 Windows 上实际底层已经被翻译成了 iOS 能听懂的指令。适合谁来参考这篇内容三类人一是喜欢在移动设备上折腾兼容层的技术爱好者二是需要临时在 iOS 上跑某个 Windows 小工具、又不想背笔记本的从业者三是想理解 Wine 生态在 ARM 平台、特别是 iOS 这种封闭系统上如何落地的人。我会把整个思路拆开从架构选型讲到实操配置再到踩过的坑尽量让你看完能自己动手试一遍。2. 整体架构拆解Wine FEX-Emu DXMT 是怎么串起来的2.1 三层翻译栈的分工逻辑在 iOS 上跑 Windows 程序本质上要跨过三道坎系统调用层、指令集层、图形 API 层。Madeira 的思路是每一层都用专门的组件去对付而不是指望一个“万能模拟器”全包。第一层是 Wine。Wine 的全称是“Wine Is Not an Emulator”它不模拟硬件而是把 Windows 的 PE 可执行文件加载进来把 Windows API 调用翻译成 POSIX 调用。比如一个程序调用CreateFileWine 会把它转成 iOS 上的open。这一层解决的是“Windows 程序以为自己在调 Windows 系统接口”的问题。第二层是 FEX-Emu。Wine 本身不负责指令集翻译如果你的 Windows 程序是 x86-64 编译的而 iOS 设备是 ARM64那就需要 FEX-Emu 把 x86-64 指令动态翻译成 ARM64。FEX-Emu 的特点是做了大量针对游戏和应用的优化尤其是对 SSE、AVX 这类 SIMD 指令的支持比较完整很多老程序跑起来不会因为指令不支持直接崩掉。第三层是 DXMT。Windows 程序画界面、渲染 3D 靠的是 Direct3D而 iOS 只认 Metal。DXMT 的作用就是把 D3D11、D3D12 的调用翻译成 Metal 调用。热搜词里出现 DXMT 而不是 DXVK说明这个项目走的是 Metal 原生路线而不是先转 Vulkan 再转 Metal少了一层损耗。提示这三层不是简单叠加Wine 和 FEX-Emu 的配合需要处理“Wine 调用的地址空间”和“FEX 翻译后的地址空间”之间的映射配置不当会出现程序启动后黑屏或闪退。2.2 为什么不用其他方案有人会问为什么不用 QEMU 全系统模拟因为 QEMU 模拟的是整台 PC包括 CPU、主板、显卡性能损耗太大在 iOS 设备上跑一个 Windows 7 都卡更别说跑应用。也有人问为什么不用 CrossOver 那套CrossOver 本质也是 Wine但它的 iOS 版本受限于苹果的政策不能直接加载任意 exe而 Madeira 这类项目通常走的是侧载或者自签路线灵活性更高。还有一个关键点是x86-64 到 ARM64 的翻译效率。FEX-Emu 相比 QEMU 的用户态模拟优势在于它只翻译用户态指令不模拟内核态而且有 JIT 缓存重复执行的代码块不用反复翻译。实测下来一个简单的 Win32 记事本程序在 A15 芯片上启动时间可以控制在 3 秒以内而 QEMU 方案可能要 15 秒以上。2.3 iOS 封闭环境带来的特殊约束iOS 和桌面 Linux 最大的区别是不能 fork 任意进程、不能 mmap 可执行内存、不能直接调用系统图形接口。Wine 在 Linux 上跑得好好的到了 iOS 上很多底层调用会被沙盒拦住。Madeira 项目要解决的就是这些“拦路虎”。比如 Wine 需要申请可执行内存来放 JIT 代码iOS 默认不允许得用mach_vm_allocate配合特定的权限标志而且应用必须开启 JIT 权限通常需要开发者模式或者特定的签名配置。再比如图形输出Wine 在 Linux 上可以直接往 X11 或者 Wayland 上画在 iOS 上只能通过 Metal 层而且得处理好触摸事件到鼠标事件的映射。这些约束决定了 Madeira 不能照搬桌面 Wine 的配置必须做大量 iOS 特有的适配。这也是为什么热搜词里会出现“iOS 开发者模式”“iOS 自动化”这些看似不相关的词——它们其实是配置过程中的必经步骤。3. 核心组件实操配置从零把环境搭起来3.1 Wine 层的部署与乱码问题处理Wine 在 iOS 上的部署第一步是拿到编译好的 Wine 二进制和它的依赖库。热搜词里有人问“wine gecko 官方正版下载”这是因为 Wine 在运行某些程序时需要 Gecko 引擎来渲染 HTML 内容比如程序的帮助文档或者内嵌网页。Gecko 包要放在 Wine 的lib/wine/目录下否则程序启动时会弹窗提示缺少 Gecko。部署完 Wine 之后最常见的问题就是乱码。热搜词里“wine 乱码”“wine 栏是乱码”反复出现说明这是高频痛点。乱码的根源通常是字体缺失或者编码映射不对。Wine 默认使用系统字体但 iOS 的字体目录和 Linux 不一样Wine 找不到中文字体时就会显示方块或者问号。解决办法分两步第一把中文字体比如文泉驿微米黑或者思源黑体复制到 Wine 的drive_c/windows/Fonts/目录下第二修改注册表里的字体替换项把SystemLink、Tahoma这些默认字体映射到中文字体。具体操作是在 Wine 的注册表文件里加入[Software\\Microsoft\\Windows NT\\CurrentVersion\\FontSubstitutes] MS Shell DlgWenQuanYi Micro Hei MS Shell Dlg 2WenQuanYi Micro Hei TahomaWenQuanYi Micro Hei改完之后重启 Wine 容器乱码问题基本能解决。如果还有个别程序乱码那可能是程序自己带了字体文件需要单独处理。注意iOS 上的字体文件路径和桌面 Linux 不同Wine 的drive_c通常映射到应用沙盒内的一个目录你得先确认这个目录的实际路径再把字体放进去。3.2 FEX-Emu 的配置与 x86-64 程序加载FEX-Emu 的配置核心是根文件系统RootFS。因为 x86-64 程序运行时需要一堆 x86-64 的动态库比如libc.so.6、libm.so.6这些库在 ARM64 的 iOS 上不存在得单独准备一套 x86-64 的根文件系统。通常做法是从一个 x86-64 的 Linux 发行版里提取/lib和/usr/lib放到 FEX-Emu 能访问的目录下。配置 FEX-Emu 时环境变量很关键export FEX_ROOTFS/path/to/rootfs export FEX_APP_CONFIG/path/to/config.json export FEX_ENABLEJIT1 export FEX_JITCACHE/path/to/cacheFEX_ENABLEJIT1是必须的否则 FEX 会退化成解释执行速度慢十倍不止。FEX_JITCACHE指向一个可写目录用来缓存翻译后的 ARM64 代码第二次启动同一个程序时速度会明显提升。实测中遇到的一个坑是某些 x86-64 程序会检测 CPU 特性比如检查是否支持 AVX2。FEX-Emu 可以通过配置文件模拟这些特性在config.json里加上{ CPUFeatures: { AVX2: true, SSE4_2: true, BMI2: true } }但要注意模拟的特性如果宿主 ARM64 芯片不支持对应的指令FEX 会用软件模拟性能会下降。所以不是开得越多越好按程序实际需要开就行。3.3 DXMT 的图形层对接与 Metal 配置DXMT 负责把 Direct3D 调用转成 Metal。在 iOS 上配置 DXMT首先要确保 Metal 设备可用然后设置环境变量让 Wine 走 DXMT 而不是 WineD3Dexport WINEDLLOVERRIDESd3d11,d3d12,dxgin,b export DXMT_METAL_DEVICE0WINEDLLOVERRIDES里的n,b表示优先使用原生native的 d3d11.dll 和 dxgi.dll也就是 DXMT 提供的版本而不是 Wine 内置的。DXMT_METAL_DEVICE0指定使用第一个 Metal 设备多 GPU 设备上可以切换。DXMT 的一个关键参数是着色器缓存。Metal 的着色器编译比较慢DXMT 会把编译好的着色器缓存到磁盘上下次启动直接加载。缓存目录通过DXMT_SHADER_CACHE指定export DXMT_SHADER_CACHE/path/to/shader_cache如果发现游戏或者 3D 程序帧率低先检查着色器缓存有没有生效。缓存文件通常在几百 MB 到几 GB 之间取决于程序复杂度。提示DXMT 目前对 D3D12 的支持还在完善中如果程序同时支持 D3D11 和 D3D12优先让它走 D3D11 路径稳定性更好。4. 完整实操流程从安装到跑起第一个程序4.1 环境准备与依赖安装整个流程的第一步是准备一个可用的 iOS 环境。这里不涉及任何具体工具的品牌推荐只说通用思路你需要一台开启了开发者模式的 iOS 设备以及一个能够侧载应用的开发环境。热搜词里“ios 26.3.1 怎么开发者模式”“ios 开发者模式”说明很多人卡在这一步。开发者模式的开启方式在设置里的“隐私与安全性”底部开启后设备会重启之后才能安装自签应用。依赖安装的顺序很重要建议按这个顺序来先部署 Wine 的基础库和二进制文件到应用沙盒的wine目录。再部署 FEX-Emu 的二进制和 x86-64 根文件系统到fex目录。然后部署 DXMT 的 dll 文件和 Metal 着色器库到 Wine 的lib目录。最后配置环境变量脚本把三者的路径串起来。每一步都要验证。Wine 部署完先跑wine --version看能不能输出版本号。FEX-Emu 部署完跑一个简单的 x86-64 的hello world看能不能执行。DXMT 部署完跑wine dxdiag看能不能识别出 Metal 设备。4.2 创建 Wine 容器与初始化配置Wine 容器prefix是每个 Windows 程序的独立运行环境。创建容器的命令是WINEPREFIX/path/to/prefix wineboot -uwineboot -u会初始化容器创建drive_c目录结构、注册表文件、以及默认的 Windows 目录。初始化完成后你会看到drive_c下面有windows、Program Files、users这些目录。初始化之后要做几件事把中文字体复制到drive_c/windows/Fonts/。修改注册表设置字体替换和 DPI 缩放。iOS 屏幕的 DPI 很高不缩放的话程序界面会小得看不清。在注册表里加[Control Panel\\Desktop] LogPixelsdword:000000c00xc0是 192 DPI相当于 200% 缩放。你可以根据屏幕实际尺寸调整iPad 上一般 192 比较合适iPhone 上可能要 240 以上。安装必要的运行库比如vcrun2019、dotnet48很多程序依赖这些。可以用winetricks来装但 iOS 上winetricks不一定能直接跑需要手动把运行库的安装包放到容器里再用wine执行安装。4.3 加载第一个 x86-64 程序并验证找一个简单的 x86-64 Windows 程序来测试比如 Notepad 的便携版。把它放到drive_c/Program Files/下面然后执行WINEPREFIX/path/to/prefix FEX_ROOTFS/path/to/rootfs wine /path/to/prefix/drive_c/Program Files/Notepad/notepad.exe如果一切正常你会看到 Notepad 的窗口弹出来。如果黑屏或者闪退按这个顺序排查检查 FEX-Emu 的日志看有没有指令翻译失败。日志通常在FEX_JITCACHE同级的fex.log。检查 DXMT 的日志看 Metal 设备有没有初始化成功。检查 Wine 的日志看有没有缺 dll 或者注册表项。实测下来Notepad 这类纯 Win32 程序最容易跑通因为它不依赖复杂的图形 API。跑通之后再试 3D 程序比如老版本的 3D 弹球或者简单的 OpenGL 程序逐步验证 DXMT 的图形翻译能力。4.4 性能调优与参数微调跑通之后就是调优。几个关键参数FEX 的 JIT 缓存大小默认可能只有几百 MB跑大程序容易满。在config.json里把JITCacheSize调到 2GB 以上。Wine 的堆大小某些程序需要大堆在注册表里设置[Software\\Wine\\Wine]下的HeapSize为0x400000001GB。DXMT 的帧率限制如果程序跑得太快导致触摸事件跟不上可以在 DXMT 配置里加FrameRateLimit60。还有一个容易被忽略的点是触摸事件映射。Wine 默认把触摸当鼠标但 iOS 的触摸事件和鼠标事件语义不同。长按、滑动、双指这些手势需要额外映射。Madeira 项目通常会在 Wine 的输入层加一个适配模块把 iOS 的UITouch事件转成 Wine 能识别的WM_MOUSEMOVE、WM_LBUTTONDOWN等消息。这部分如果没配好程序界面能显示但点不动。5. 常见问题与排查技巧实录5.1 启动即崩溃的排查路径程序启动就崩是最常见也最难查的问题。我的排查顺序是这样的现象可能原因排查方法无任何窗口进程直接退出FEX 根文件系统缺失或路径错误检查FEX_ROOTFS下的lib/ld-linux-x86-64.so.2是否存在弹出 Wine 错误框提示缺 dllWine 容器未初始化完整重新跑wineboot -u或手动复制缺失的 dll窗口一闪而过程序依赖的图形 API 不支持查看 DXMT 日志确认 D3D 版本是否被支持黑屏但进程还在Metal 层初始化失败检查DXMT_METAL_DEVICE是否指向有效设备一个很隐蔽的坑是路径中的空格和中文。Wine 对路径中的空格处理有时会出问题尤其是 exe 放在带空格的目录下。尽量把程序放在drive_c/app/这种简单路径下避免用Program Files这种带空格的目录。5.2 图形渲染异常的典型表现与修复图形异常的花样很多常见的有花屏、纹理错位、帧率极低、画面撕裂。花屏通常是 DXMT 的着色器翻译有问题可以尝试关闭 DXMT 的某些优化选项比如DXMT_DISABLE_SHADER_OPT1。纹理错位可能是 Metal 的纹理格式和 D3D 的不匹配需要在 DXMT 配置里强制指定纹理格式。帧率极低要先看是 CPU 瓶颈还是 GPU 瓶颈。用 FEX 的日志看指令翻译耗时如果翻译耗时占比高说明 JIT 缓存没生效或者缓存太小。如果 GPU 耗时高可能是 Metal 着色器编译慢检查着色器缓存目录是否可写。提示iOS 设备发热降频会严重影响帧率。跑 3D 程序时尽量摘掉保护壳或者用散热背夹。实测 iPhone 在持续跑 3D 程序 10 分钟后帧率可能下降 30% 以上。5.3 输入与交互问题的处理触摸映射的问题前面提过这里补充几个具体场景。右键菜单Windows 程序里右键很常用iOS 上没有右键通常用长按模拟。需要在输入适配层里把长按事件转成WM_RBUTTONDOWN。滚轮双指滑动模拟滚轮但灵敏度要调太快会滚过头太慢又滚不动。键盘iOS 的软键盘和物理键盘事件不同软键盘的UITextInput事件需要转成 Wine 的WM_CHAR消息。还有一个高频问题是窗口大小和分辨率。Windows 程序默认按固定分辨率渲染iOS 屏幕比例不同会出现黑边或者拉伸。解决办法是在 Wine 的注册表里设置[Software\\Wine\\Explorer\\Desktops]把默认桌面分辨率设成和屏幕一致比如1920x1080。5.4 网络与代理相关配置的注意事项有些 Windows 程序需要联网Wine 在 iOS 上的网络栈是通过 POSIX socket 转的一般能正常工作。但如果程序用了 WinHTTP 或者 WinINet 的特定 API可能需要额外的 dll 支持。热搜词里“ios 怎么连接 fiddler”说明有人想抓包调试这在 Wine 环境下需要把 iOS 的系统代理设置好然后 Wine 里的程序走系统代理。需要注意的是Wine 的网络配置不要和 iOS 的系统网络设置冲突。如果程序连不上网先检查 iOS 的系统网络是否正常再检查 Wine 容器里的etc/hosts和 DNS 配置。Wine 默认使用宿主系统的 DNS但有时需要手动指定。6. 从 Madeira 延伸这套方案还能怎么用6.1 在 iPad 上跑行业软件的可行性Madeira 这套方案最实际的应用场景是在 iPad 上跑那些只有 Windows 版本的行业软件。比如某些老版本的 CAD 查看器、医疗影像软件、工业控制配置工具。这些软件通常对图形要求不高但对稳定性要求高。实测下来纯 Win32 的行业软件跑通率比游戏高得多因为不依赖复杂的 D3D 特性。如果你有这类需求建议先在一台性能足够的 iPad 上试A14 以上的芯片基本能保证流畅度。内存方面iPad Pro 的 8GB 或 16GB 内存跑 Wine 容器比较宽裕普通 iPad 的 4GB 内存跑大程序会吃紧。6.2 老游戏在 iOS 上的运行体验老游戏是另一个热门场景。DXMT 对 D3D9 和 D3D11 的支持比较好所以 2010 年之前的游戏跑起来问题不大。但要注意很多老游戏依赖 DirectSound 或者 DirectInputWine 对这些的支持需要额外的配置。DirectSound 通常能自动转成 CoreAudio但 DirectInput 的手柄支持在 iOS 上比较麻烦需要把 iOS 的 GameController 框架事件转成 DirectInput 消息。帧率方面2D 游戏基本满帧3D 游戏取决于复杂度。实测一个 2005 年的 3D 游戏在 A15 上能跑到 40-60 帧但发热明显。建议配一个散热背夹否则十分钟后就会降频。6.3 后续可扩展的方向Madeira 目前主要解决的是“能跑”的问题后续可以往“跑得好”方向扩展。比如多容器管理现在每个程序一个容器管理起来麻烦。可以做一个容器管理器支持快速切换和备份。图形设置界面把 DXMT 和 FEX 的配置项做成图形界面不用手动改配置文件。性能监控实时显示 FEX 翻译耗时、Metal 帧率、内存占用方便调优。自动化脚本把常用的配置和启动流程写成脚本一键部署。这些方向不需要改动核心架构只是在现有基础上加一层封装。如果你已经跑通了基础流程可以试着从这些方向入手把 Madeira 变得更易用。我个人在折腾这套方案的过程中最大的体会是耐心比技术更重要。Wine 在 iOS 上的配置链路很长任何一个环节出错都会导致失败。但只要按层排查从 Wine 到 FEX 到 DXMT 逐层验证最终总能跑通。跑通第一个程序之后后面的程序就是复制容器、调整配置的重复劳动了。