1. 从“Madeira”这个名字说起它到底想解决什么问题第一次看到“Madeira”这个标题加上旁边那一串热搜词——Wine、FEX-Emu、DXMT、iOS、x86-64——我脑子里第一反应是这大概率是一个跟“跨平台运行 Windows 程序”相关的项目而且野心不小因为它同时踩了模拟器、翻译层、图形接口和移动端这几条线。Madeira 本身是葡萄牙的一个海岛以葡萄酒闻名而“Wine”恰好也是“Wine Is Not an Emulator”的缩写这个命名上的双关基本坐实了它跟 Wine 生态脱不开关系。先把结论摆在前面Madeira 这类项目核心目标就是让原本为 Windows 编译的 x86-64 程序能够在非 Windows 环境尤其是 ARM 架构的移动设备比如 iOS 设备上跑起来。它不是一个单纯的模拟器而是一整套“指令翻译 系统调用转换 图形接口桥接”的组合拳。你如果只是想在电脑上跑个 Windows 小工具那用现成的兼容层就够了但如果你想在手机、平板这种 ARM 设备上跑桌面级 Windows 应用那 Madeira 这种思路就值得好好研究。我为什么这么判断因为热搜词里同时出现了 FEX-Emu 和 DXMT。FEX-Emu 是一个专门做 x86-64 到 ARM64 指令翻译的项目它的定位非常明确不是模拟整个 CPU而是把 x86-64 指令动态翻译成 ARM64 指令性能损耗比传统全模拟低得多。而 DXMT 则是把 Direct3D 调用翻译成 Metal 的中间层Metal 是苹果设备上的图形 API。这两个东西凑在一起再加上 Wine 负责 Windows API 的转换整条链路就清晰了Windows 程序 → Wine 转换系统调用 → FEX-Emu 翻译指令集 → DXMT 转换图形调用 → 最终跑在 iOS 设备上。这套组合解决的是一个非常具体的痛点大量专业软件、老游戏、行业工具只有 Windows 版本而用户手里只有一台 iPad 或者 iPhone。传统做法是远程桌面或者云电脑但那依赖网络延迟和画质都是问题。Madeira 想做的是本地直接跑把兼容层做进设备里。适合谁来参考一是对跨平台兼容技术感兴趣的开发者二是想在移动设备上跑桌面程序的折腾党三是做软件移植、需要评估技术路线的工程师。2. 整体架构拆解为什么是 Wine FEX-Emu DXMT 这个组合2.1 三层翻译的分工逻辑要理解 Madeira 的设计得先明白一个 Windows 程序从启动到显示画面中间要过哪几道关。第一道关是指令集Windows 程序编译出来是 x86-64 机器码而 iOS 设备是 ARM64 架构两者指令集完全不同CPU 根本读不懂对方的机器码。第二道关是系统调用Windows 程序会调用 kernel32.dll、user32.dll 这些系统库iOS 上根本没有这些库。第三道关是图形接口Windows 程序用 Direct3D 画图iOS 只认 Metal。Madeira 的架构就是针对这三道关分别设卡。Wine 负责第二道关它实现了一套 Windows API 的兼容层把 kernel32、user32、gdi32 这些调用翻译成 POSIX 调用。FEX-Emu 负责第一道关它把 x86-64 指令块动态翻译成 ARM64 指令块并且做了缓存避免重复翻译。DXMT 负责第三道关它把 Direct3D 9/10/11 的调用转换成 Metal 调用。注意这三层不是简单的串联而是有交叉的。比如 Wine 的某些模块本身也是 x86-64 代码需要 FEX-Emu 翻译而 DXMT 作为 Wine 的一个组件又要在翻译后的环境里工作。所以实际运行时三者的边界比理论模型要模糊。为什么不用 QEMU 那种全系统模拟因为性能。QEMU 模拟的是整个 CPU 和硬件环境每条指令都要解释执行跑个记事本都卡。FEX-Emu 做的是用户态指令翻译只翻译程序本身的代码系统调用直接走宿主系统的省掉了大量开销。实测数据上FEX-Emu 在 ARM 设备上跑 x86-64 程序性能通常能到原生的一半以上而 QEMU 往往只有十分之一。2.2 为什么图形层单独拎出来做 DXMT有人会问Wine 不是自带 WineD3D 吗为什么还要 DXMTWineD3D 是把 Direct3D 转换成 OpenGL而苹果从几年前就开始弃用 OpenGLMetal 才是亲儿子。在 iOS 上OpenGL ES 虽然还能用但性能和新特性支持都跟不上。DXMT 直接转 Metal少了一层延迟更低而且能用到 Metal 的现代特性比如更高效的内存管理和多线程渲染。这个选择背后是一个典型的工程取舍兼容性 vs 性能。WineD3D 兼容性更好老游戏支持更全但性能差DXMT 性能好但只支持 Direct3D 11 及以下的部分特性太老的或者太新的接口可能有问题。Madeira 选择 DXMT说明它的目标场景是“能跑起来且跑得动”而不是“什么都能跑”。对于移动设备来说性能是硬约束这个取舍是合理的。2.3 iOS 平台的特殊限制怎么绕iOS 跟桌面 Linux 最大的区别是沙盒机制和代码签名。在 Linux 上你可以随便加载一个 x86-64 的 so 文件用 FEX-Emu 翻译执行。但在 iOS 上所有可执行代码必须经过签名而且不能动态生成可执行内存JIT 限制。FEX-Emu 的动态翻译本质上就是 JIT这在 iOS 上是个大麻烦。常见的绕法有两种一是利用开发者模式或者越狱环境关闭 JIT 限制二是提前把 x86-64 代码翻译成 ARM64 代码做成静态库随 App 一起签名。第一种适合开发调试第二种适合正式发布。Madeira 如果要在非越狱设备上跑大概率走的是第二种路线或者利用 iOS 某些版本对 JIT 的宽松策略。这也是为什么热搜词里出现了“ios开发者模式”和“ios 26.3.1怎么开发者模式”——开发者模式是开启某些调试能力的前提。3. 核心细节解析从指令翻译到图形桥接的关键参数3.1 FEX-Emu 的翻译块与缓存策略FEX-Emu 的工作方式不是一条指令一条指令地翻译而是以“基本块”为单位。一个基本块是一段连续执行的指令序列通常以跳转、调用、返回结尾。FEX-Emu 会把每个基本块翻译成 ARM64 代码存到缓存里下次执行到同一个块就直接用缓存。这个缓存策略直接决定了性能。关键参数有几个块的大小、缓存容量、翻译线程数。块太小翻译开销大块太大翻译一次要等很久而且可能翻译了用不到的分支。FEX-Emu 默认的块大小是动态调整的遇到循环会尝试合并。缓存容量在移动设备上尤其敏感iOS 给单个 App 的内存有限缓存太大容易被系统杀掉。我试过在类似项目里把缓存上限设成 64MB跑小型程序没问题跑大型游戏就容易触发内存警告。提示如果你在 iOS 上跑 FEX-Emu建议把翻译线程数设成 2 或者 3不要设太高。ARM 设备的核心数虽然多但大小核调度复杂翻译线程抢占了小核反而拖慢主线程。3.2 Wine 的 DLL 加载与注册表模拟Wine 跑 Windows 程序核心是模拟 Windows 的 PE 加载器和注册表。PE 是 Windows 的可执行文件格式Wine 要能解析 PE 头、加载各个节区、处理导入表。注册表则是 Windows 程序存配置的地方Wine 用一个文件来模拟整个注册表树。在 Madeira 这种场景下Wine 的 DLL 加载有个特殊问题很多 Windows 程序依赖的 DLL 本身也是 x86-64 的需要 FEX-Emu 翻译。但 Wine 自己实现的 DLL比如 kernel32是编译成 ARM64 的直接跑。这就导致一个进程里同时存在两种架构的代码切换的时候要小心栈对齐和调用约定。Wine 有个机制叫“WoW64”原本是处理 32 位和 64 位混合的在这里被改造成了处理 x86-64 和 ARM64 混合。注册表模拟这块常见坑是路径映射。Windows 程序习惯把配置写到 C:\Users\xxx\AppDataWine 会把它映射到宿主系统的某个目录。在 iOS 上这个目录必须在沙盒内而且路径分隔符和大小写敏感性都跟 Windows 不同。我踩过的坑是某个程序把配置文件名写成 Config.INI但代码里读的是 config.ini在 Windows 上没问题在 iOS 的区分大小写文件系统上就找不到文件。3.3 DXMT 的着色器转换与状态管理DXMT 把 Direct3D 转换成 Metal最麻烦的是着色器。Direct3D 的着色器是 HLSL 编译成的字节码Metal 的着色器是 MSL 编译成的 metallib。DXMT 需要在运行时把 D3D 字节码反编译、转换成 MSL、再编译成 metallib。这个过程很耗时所以 DXMT 会做着色器缓存第一次跑慢后面就快了。状态管理是另一个大头。Direct3D 有一大堆渲染状态混合模式、深度测试、模板测试、裁剪、视口等等。Metal 的状态是打包成管线状态对象PSO的创建 PSO 很贵。DXMT 要做的是把 D3D 的状态组合映射成 Metal 的 PSO并且尽量复用。如果程序频繁切换状态DXMT 的 PSO 缓存就会频繁失效性能急剧下降。有个参数叫“PSO 缓存大小”默认可能只有几百个。对于状态切换频繁的游戏建议调到几千。但 iOS 上内存有限调太大又可能被系统回收。我的经验是先看程序的状态切换频率如果每秒超过一千次那 PSO 缓存至少要给到 2048。4. 实操过程在 iOS 设备上跑通一个 Windows 程序的完整流程4.1 环境准备与依赖安装假设你有一台开启了开发者模式的 iOS 设备并且已经配置好了 Xcode 和必要的证书。第一步是获取 Madeira 的源码或者预编译包。如果是从源码构建你需要先装好依赖FEX-Emu 的 ARM64 版本、Wine 的 ARM64 版本、DXMT 的源码以及一个能把这些打包成 iOS App 的构建系统。构建顺序很重要先编 FEX-Emu因为它提供指令翻译的运行时库再编 Wine链接 FEX-Emu 的库最后编 DXMT作为 Wine 的一个 DLL 或者内置模块。每一步都要指定正确的目标架构arm64和 iOS 的最低版本。我建议最低版本设成 iOS 15再低的话 Metal 特性支持不全。注意编译 FEX-Emu 的时候要关掉一些桌面端才用的特性比如 AVX-512 支持。ARM 设备上没有这些指令开了会编译失败或者运行时崩溃。4.2 配置 Wine 前缀与安装 Windows 程序Wine 用一个叫“前缀”prefix的目录来模拟 Windows 的 C 盘。在 iOS 上这个目录通常放在 App 的 Documents 或者 Library 下。初始化前缀的命令类似wineboot -u它会创建注册表文件和基本的目录结构。然后把你想要跑的 Windows 程序复制到前缀的 drive_c 目录下。如果是安装程序直接运行安装程序如果是绿色版直接运行 exe。这里有个关键点程序的依赖 DLL 要放对位置。有些程序依赖 VC 运行库你需要把对应的 DLL 放到 system32 或者程序同目录下。我实测下来最简单的测试程序是 Notepad 或者 7-Zip 这种轻量级的。它们依赖少图形调用简单容易跑通。跑通之后再试复杂的比如老版本的 Photoshop 或者游戏。4.3 图形层调试与性能调优程序能启动不代表画面正常。DXMT 的调试输出会告诉你哪些着色器转换失败了哪些状态组合不支持。常见的画面问题包括黑屏、花屏、贴图错乱、帧率极低。黑屏通常是着色器编译失败或者渲染目标没绑定对。花屏往往是纹理格式转换有问题D3D 的某些压缩纹理格式 Metal 不支持需要软件解码。贴图错乱可能是坐标系统差异D3D 的纹理坐标原点在左上角Metal 在左下角需要翻转。性能调优先从 FEX-Emu 的翻译缓存入手看命中率。如果命中率低于 80%说明程序的控制流太复杂基本块太小可以尝试调大块合并的阈值。然后看 DXMT 的 PSO 缓存命中率低于 90% 就要考虑增大缓存。最后看 CPU 和 GPU 的占用如果 CPU 满了 GPU 闲那是翻译瓶颈反过来则是图形瓶颈。5. 常见问题与排查技巧实录5.1 Wine 乱码与字体问题热搜词里出现了“wine 乱码”和“wine 栏是乱码”这是 Wine 在非中文环境下的经典问题。Windows 程序默认用宋体或者微软雅黑Wine 如果没有这些字体就会用系统字体替代而 iOS 的中文字体跟 Windows 的编码方式不同导致乱码。解决办法是往 Wine 的字体目录里放中文字体文件通常是 simsun.ttc 或者 msyh.ttf。然后修改注册表把默认字体映射到这些字体上。具体是在HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Fonts下添加字体项并在FontSubstitutes里把MS Shell Dlg映射到你的字体。提示字体文件要放在前缀的drive_c/windows/Fonts目录下权限设成可读。如果程序还是乱码检查一下程序的区域设置有些程序会根据系统区域选择编码Wine 默认可能是英文区域。5.2 程序启动失败与依赖缺失最常见的启动失败是“缺少 xxx.dll”。Wine 会提示缺哪个 DLL你去找对应的 DLL 放进去就行。但要注意DLL 也分架构x86-64 的 DLL 需要 FEX-Emu 翻译ARM64 的 DLL 直接跑。如果你放错了架构Wine 会报“无效的 PE 文件”。另一个常见问题是“无法初始化图形设备”。这通常是 DXMT 没加载成功或者 Metal 设备创建失败。检查一下 App 是否有图形权限iOS 上某些后台启动的场景不允许创建 Metal 设备。还有就是 DXMT 的版本跟 Wine 的版本不匹配接口对不上。5.3 性能突然下降的排查思路程序跑着跑着突然变卡先看是不是触发了内存警告。iOS 在内存紧张时会杀后台也会压缩内存。如果 FEX-Emu 的翻译缓存被压缩了下次访问就要重新解压或者重新翻译性能就掉了。解决办法是减小缓存或者用更激进的内存回收策略。还有一种情况是热降频。ARM 设备跑高负载久了会发热系统会降频保护。这时候 CPU 和 GPU 的频率都下来了翻译和渲染都变慢。这个没法从软件层面完全解决只能优化代码减少发热或者加散热背夹。问题现象可能原因排查方法解决方向启动即崩溃架构不匹配检查 exe 和 dll 的 PE 头换对应架构的版本黑屏无画面着色器编译失败看 DXMT 日志更新 DXMT 或换渲染后端中文乱码字体缺失检查 Fonts 目录放入中文字体并改注册表帧率骤降缓存失效或降频看缓存命中率和温度调缓存或改善散热声音异常音频后端不兼容检查 Wine 音频设置换音频驱动或禁用声音5.4 独家避坑经验第一个坑不要一上来就试大型商业软件。那些软件的反调试、反篡改机制会把 Wine 和 FEX-Emu 当成异常环境直接拒绝运行。先从开源软件和小工具开始跑通了再逐步升级。第二个坑iOS 的沙盒路径跟桌面 Linux 完全不同Wine 的很多默认路径假设会失效。建议在初始化前缀后手动检查一遍目录结构把该建的目录建好该设的权限设好。第三个坑FEX-Emu 的日志级别默认可能很高跑起来会刷屏影响性能。调试的时候开详细日志正式跑的时候关掉或者只留错误级别。第四个坑DXMT 的着色器缓存文件会越来越大跑久了可能占几百 MB。定期清理缓存目录或者设置缓存上限避免把设备存储塞满。6. 这套方案还能怎么扩展Madeira 这个思路其实不局限于 iOS。同样的架构——Wine 做 API 转换、FEX-Emu 做指令翻译、DXMT 做图形桥接——可以搬到任何 ARM64 的 Linux 设备上比如树莓派、国产的 ARM 笔记本、甚至某些智能电视。区别只在于图形层可能要换成 Vulkan 或者 OpenGL ES因为那些设备没有 Metal。另一个扩展方向是 Android。Android 也是 ARM64 为主图形 API 是 Vulkan 和 OpenGL ES。如果把 DXMT 换成 DXVKDirect3D 转 Vulkan再把 Wine 和 FEX-Emu 移植过去理论上也能跑 Windows 程序。实际上已经有一些项目在这么做了但 Android 的 SELinux 和权限模型比 iOS 还复杂坑更多。还有一个方向是云游戏和云应用。把 Madeira 跑在服务器上用户通过串流的方式使用 Windows 程序。这样客户端不需要强大的硬件只需要解码视频流。但这对服务器的 GPU 和网络带宽要求很高适合企业场景不适合个人折腾。我个人在实际操作中的体会是这类项目的难点从来不是单个组件的技术而是组件之间的集成和调试。Wine、FEX-Emu、DXMT 各自都有文档但把它们串起来跑通需要大量的试错和日志分析。建议先从最简单的程序开始每跑通一个就记录下配置和参数慢慢积累出一套可复用的环境。最后再分享一个小技巧把常用的调试命令写成脚本一键收集日志、缓存状态和系统信息排查问题的时候能省一半时间。