1. 从“Madeira”这个名字说起一个被低估的跨架构运行层项目第一次看到“Madeira”这个词大多数人会想到那个盛产葡萄酒的海岛但在系统兼容与二进制翻译的圈子里它指向的是另一件事——一个围绕FEX-Emu构建的、面向 x86-64 应用在 ARM 设备上运行的整合方案。项目正文和关键词几乎是空的但相关热搜词把方向暴露得很清楚FEX-Emu、Wine、DXMT、iOS、x86-64。这几个词凑在一起指向一个非常具体的技术命题——怎么让原本为 x86-64 Windows 或 Linux 编译的程序在 ARM 架构的设备上跑起来并且尽量少折腾。我自己接触这类需求是从一批老旧的行业软件开始的。这些软件只有 x86-64 的 Windows 版本没有源码厂商也早就不维护了但业务上又离不开。换设备、换系统都试过最后绕回到“能不能在 ARM 机器上把它跑起来”这个问题上。FEX-Emu 就是在这个场景下进入视野的。它的定位是用户态的 x86-64 到 ARM64 的指令翻译层和 QEMU 那种全系统模拟不是一回事——FEX 只翻译用户态指令系统调用直接透传给宿主内核所以性能损耗比全系统模拟小得多启动也快。Madeira 在这个基础上做的事情是把 FEX-Emu、Wine、以及图形翻译层比如 DXMT 这类把 DirectX 调用转到 Metal 或 Vulkan 的组件打包成一个相对完整的运行环境。你可以把它理解成一个“兼容层发行版”底层是 FEX 负责指令翻译中间是 Wine 负责 Windows API 的实现上层是 DXMT 之类的组件负责图形 API 的转换。三层各司其职缺一层很多带界面的 Windows 程序就跑不起来。这篇文章适合谁看如果你手上有必须在 ARM 设备上运行的 x86-64 程序尤其是 Windows 程序并且你愿意花时间配置而不是直接买一台 x86 机器那这套思路值得研究。如果你只是想了解 FEX-Emu 和 Wine 是怎么协作的文章里的原理拆解部分也能给你一个清晰的框架。我不会给你一个“一键脚本”因为这类环境的搭建高度依赖具体设备和具体程序但我可以把每一层的职责、配置的关键点、以及我踩过的坑讲清楚让你少走弯路。2. FEX-Emu 到底翻译了什么用户态指令翻译的边界2.1 为什么不是全系统模拟很多人第一次听到“在 ARM 上跑 x86 程序”第一反应是 QEMU。QEMU 的全系统模拟确实能跑但它模拟的是整台机器——CPU、内存、外设、中断控制器全都要软件模拟。这意味着每一条指令都要经过模拟器的解释或动态翻译系统调用也要被拦截再转发开销非常大。跑一个计算密集型的程序性能可能只有原生的十分之一甚至更低。FEX-Emu 走的是另一条路。它工作在用户态只翻译应用程序的指令系统调用直接由宿主内核处理。举个例子程序调用open()打开文件FEX 不会去模拟一个文件系统而是把 x86-64 的调用约定转换成 ARM64 的调用约定然后直接让宿主内核执行。这样就省掉了大量模拟开销。代价是 FEX 只能跑用户态程序不能跑内核模块也不能跑需要直接操作硬件的驱动。但对于绝大多数应用软件来说用户态翻译已经够用了。这个区别很关键因为它决定了 Madeira 这类方案的适用边界。如果你的程序依赖特定的内核驱动、依赖底层的硬件访问、或者依赖某些只有 x86 才有的指令集扩展比如某些 AVX-512 指令FEX 可能就跑不了或者跑得很别扭。但如果是普通的桌面应用、命令行工具、甚至一些游戏FEX 的兼容性和性能都是可以接受的。2.2 指令翻译的基本流程FEX 的工作流程可以粗略分成几个阶段。程序启动时FEX 加载 x86-64 的可执行文件解析它的 ELF 头或者 PE 头找到入口点。然后开始执行每遇到一段代码FEX 会把它翻译成 ARM64 指令。翻译不是逐条进行的而是以基本块为单位——一个基本块是一段没有跳转的连续指令翻译一次之后可以缓存起来下次执行到同一段代码就直接用缓存不用重新翻译。这个缓存机制是性能的关键。第一次执行某段代码时会有翻译开销但后续执行就很快了。对于循环密集的程序缓存命中率很高性能损失主要来自翻译后的代码和原生代码之间的差异而不是翻译过程本身。FEX 还做了一些优化比如寄存器映射、标志位惰性计算、以及针对常见指令模式的快速路径。但翻译层终究不是原生的。有些东西很难翻译得高效比如 x86 的复杂寻址模式、某些原子操作、以及依赖特定内存序的代码。这些地方往往是性能瓶颈也是兼容性问题的来源。我在实际使用中遇到过一些程序在 FEX 下跑起来功能正常但性能只有原生的三四成原因就是程序里有大量难以高效翻译的指令模式。2.3 和 Wine 的协作关系FEX 只负责指令翻译它不负责实现 Windows API。一个 Windows 程序在 FEX 下跑起来指令是翻译了但程序调用CreateWindow、MessageBox这些 API 的时候需要有东西来响应。这就是 Wine 的角色。Wine 实现了大量的 Windows API它把这些调用转换成宿主系统的调用。在 Linux 上Wine 把 Windows 的窗口、文件、注册表等概念映射到 Linux 的对应机制上。在 macOS 上Wine 需要处理更多的差异因为 macOS 的图形栈和 Linux 完全不同。FEX 和 Wine 的配合方式是FEX 翻译程序的指令当程序调用 Windows API 时FEX 把控制权交给 Wine 的 x86-64 版本Wine 本身也是 x86-64 程序也需要被 FEX 翻译Wine 执行 API 实现再调用宿主系统的接口。所以整个链条是x86-64 程序 → FEX 翻译 → Wine 的 x86-64 代码 → FEX 翻译 → 宿主系统调用。每一层都有开销但每一层也都做了优化。这里有一个容易忽略的点Wine 本身也需要被翻译。这意味着 Wine 的性能也会影响整体体验。如果 Wine 的某个 API 实现很复杂翻译开销就会叠加。所以选择 Wine 的版本和配置很重要不是越新越好而是要和 FEX 的兼容性匹配。3. 图形层为什么是最大的坑DXMT 与 DirectX 转换3.1 DirectX 到 Metal 的转换逻辑Windows 程序跑起来之后下一个问题就是图形。很多程序依赖 DirectX而宿主系统比如 macOS用的是 MetalLinux 用的是 Vulkan 或 OpenGL。这中间需要一个转换层DXMT 就是做这件事的——把 DirectX 的调用转换成 Metal 的调用。这个转换不是简单的 API 映射。DirectX 和 Metal 在概念模型上有差异比如资源管理、同步机制、着色器编译模型都不一样。DXMT 需要维护一个状态机跟踪 DirectX 的资源状态然后在合适的时机转换成 Metal 的命令。着色器需要从 DXIL 或 DXBC 转换成 Metal 的 AIR这个转换过程可能引入兼容性问题。我在测试一些老游戏时发现有些游戏在 DXMT 下能启动但画面有瑕疵比如纹理错位、光照异常、或者某些特效不显示。这些问题往往不是 FEX 的锅而是图形转换层的兼容性问题。排查这类问题需要看 DXMT 的日志确认是哪个 DirectX 调用没有被正确转换。3.2 图形层的性能瓶颈在哪里图形转换的性能瓶颈通常不在转换本身而在同步和状态切换。DirectX 允许程序频繁地切换渲染状态Metal 对状态切换的开销更敏感。如果程序的状态切换很频繁转换层就需要做批处理或者状态缓存否则性能会急剧下降。另一个瓶颈是着色器编译。DirectX 的着色器在运行时编译Metal 的着色器也需要编译。如果转换层在每次遇到新着色器时都重新编译首次运行的卡顿会非常明显。好的实现会做着色器缓存把编译结果存下来下次直接加载。DXMT 在这方面做了不少工作但缓存的有效性取决于程序是否稳定地使用同一套着色器。还有一个容易被忽略的点显存管理。DirectX 和 Metal 对显存的管理策略不同转换层需要在两者之间做映射。如果程序频繁地创建和销毁资源转换层的开销就会很大。我在一个视频处理程序上遇到过这个问题程序在原生 Windows 上跑得很流畅在转换层下每隔几秒就卡一下最后发现是资源创建和销毁的频率太高转换层来不及回收。3.3 不同宿主系统的图形栈差异Madeira 这类方案如果要在不同系统上跑图形层的配置差异很大。在 macOS 上Metal 是唯一的选择DXMT 是主要的转换路径。在 Linux 上可以选择 Vulkan 或 OpenGLDXVK 和 VKD3D 是常见的方案。不同方案对 DirectX 版本的支持程度不同DXVK 对 DirectX 9 到 11 的支持比较成熟VKD3D 对 DirectX 12 的支持还在完善中。选择哪个方案取决于你的程序用的是什么版本的 DirectX以及宿主系统支持什么。如果程序用的是 DirectX 9DXVK 在 Linux 上通常是最稳的。如果程序用的是 DirectX 12VKD3D 可能是唯一的选择但兼容性风险更高。在 macOS 上DXMT 是主要路径但它对 DirectX 12 的支持有限很多新游戏跑不起来。我的建议是先确认程序用的 DirectX 版本再确认宿主系统支持的图形 API然后选择匹配的转换层。不要指望一个转换层能通吃所有情况不同版本的 DirectX 差异很大转换层的成熟度也不同。4. 从零搭建一套可用的运行环境关键步骤与配置要点4.1 环境准备宿主系统与依赖搭建之前先确认宿主系统的基本条件。如果是 macOS需要确认系统版本和芯片型号Apple Silicon 和 Intel 的配置方式不同。如果是 Linux需要确认内核版本和图形驱动尤其是 Vulkan 驱动的支持情况。依赖方面FEX-Emu 需要一些基础的开发库比如 CMake、Ninja、以及 ARM64 的交叉编译工具链如果要从源码构建。Wine 需要 X11 或 Wayland 的开发库、字体配置、以及音频后端。DXMT 需要 Metal 或 Vulkan 的开发库。这些依赖在不同系统上的安装方式不同建议先看官方文档的依赖列表不要凭经验猜。我踩过的一个坑是在 macOS 上构建 FEX 时系统自带的 Python 版本和构建脚本要求的版本不一致导致构建失败。后来用虚拟环境固定了 Python 版本才解决。这类问题很琐碎但很耗时建议在开始之前就把构建环境隔离好。4.2 FEX-Emu 的配置根文件系统与库路径FEX 需要一个 x86-64 的根文件系统里面包含程序运行所需的库。这个根文件系统可以是一个目录也可以是一个镜像文件。配置的关键是让 FEX 知道去哪里找这些库以及如何把宿主系统的库和 x86-64 的库隔离开。FEX 的配置文件通常包含几个关键项根文件系统的路径、库搜索路径、以及一些翻译选项。翻译选项里比较重要的有是否启用 JIT 缓存、缓存的大小、以及是否启用某些优化。JIT 缓存建议开启并且给足够的大小否则每次启动都要重新翻译启动会很慢。还有一个容易忽略的点环境变量。FEX 会读取一些环境变量来控制行为比如FEX_ROOTFS指定根文件系统FEX_APP_CONFIG指定应用配置。这些变量如果设置不当FEX 可能找不到库或者加载了错误的库。我在配置时习惯先把环境变量打印出来确认再启动程序。4.3 Wine 的配置前缀与 Windows 版本Wine 的配置核心是“前缀”prefix也就是一个模拟的 Windows 环境目录。每个前缀有自己的注册表、文件系统映射、以及已安装的程序。建议为每个程序单独建一个前缀避免不同程序之间的配置冲突。创建前缀时需要指定 Windows 版本。Wine 支持模拟不同版本的 Windows比如 Windows 7、Windows 10。选择哪个版本取决于程序的要求。有些老程序在 Windows 10 模式下会出问题需要切到 Windows 7 模式。这个设置可以在创建前缀时指定也可以后续用winecfg修改。Wine 的另一个关键配置是 DLL 覆盖。有些程序依赖特定的 DLL而 Wine 自带的实现可能不完整。这时候可以用原生的 DLL 覆盖 Wine 的实现。但要注意原生 DLL 也是 x86-64 的也需要被 FEX 翻译所以性能会有影响。覆盖之前先确认 Wine 自带的实现是否真的不行不要一上来就覆盖。4.4 图形层的配置DXMT 与着色器缓存DXMT 的配置通常涉及几个方面选择图形后端、配置着色器缓存、以及调整同步选项。图形后端在 macOS 上就是 Metal在 Linux 上可能是 Vulkan。着色器缓存建议开启并且给足够的大小否则每次启动都要重新编译着色器。同步选项比较微妙。有些程序依赖严格的同步如果转换层做了异步优化可能会导致画面撕裂或者逻辑错误。有些程序则可以从异步优化中受益帧率更稳定。这个需要针对具体程序调整没有通用答案。我在配置一个老游戏时发现默认配置下画面正常但帧率很低后来调整了同步选项帧率上去了但偶尔有画面瑕疵。最后找到一个平衡点瑕疵很少出现帧率也可以接受。这个过程需要耐心建议一次只改一个选项改完测试确认效果后再改下一个。5. 实测中遇到的典型问题与排查思路5.1 程序启动即崩溃从日志定位第一现场程序启动就崩溃是最常见的问题也是最容易排查的因为崩溃点通常在启动阶段涉及的代码路径比较短。第一步是看日志。FEX 和 Wine 都会输出日志日志里通常有崩溃时的指令地址、调用栈、以及最后执行的系统调用。如果日志里显示的是 FEX 的翻译错误比如“无法翻译某条指令”那问题就在指令翻译层。这时候需要确认这条指令是什么是不是 FEX 不支持的指令。有些指令 FEX 支持但需要开启特定的选项有些指令则完全不支持只能等 FEX 更新。如果日志里显示的是 Wine 的 API 错误比如“找不到某个 DLL”或者“某个 API 未实现”那问题就在 Wine 层。这时候需要确认这个 DLL 或 API 是否真的需要能不能用替代方案。有些程序会检查某些 API 的返回值如果返回值不对就崩溃这种问题比较难排查需要看程序的代码或者反汇编。5.2 界面能出来但操作无响应输入与焦点问题界面能出来说明图形层基本正常但操作无响应通常是输入处理的问题。Wine 需要把宿主系统的输入事件转换成 Windows 的输入消息这个转换过程可能出问题。比如鼠标点击的位置不对、键盘按键映射错误、或者焦点没有正确设置。排查这类问题先确认宿主系统的输入是否正常。可以在 Wine 的配置工具里测试输入看事件是否被正确捕获。如果宿主系统层面正常那就是 Wine 的转换问题。检查 Wine 的输入配置确认键盘布局和鼠标设置是否正确。还有一个常见原因是焦点问题。有些程序启动后没有获得焦点导致输入事件被发送到错误的窗口。这时候可以尝试手动点击窗口或者用窗口管理器的快捷键切换焦点。如果焦点问题频繁出现可能需要在 Wine 的配置里调整窗口管理选项。5.3 性能远低于预期定位瓶颈在翻译层还是图形层性能问题最难排查因为涉及多个层。第一步是确认瓶颈在哪一层。可以用性能分析工具看 CPU 时间花在 FEX 的翻译上还是花在 Wine 的 API 实现上还是花在图形转换上。如果 CPU 时间主要花在 FEX 上那瓶颈在指令翻译。可能的原因包括程序里有大量难以翻译的指令、JIT 缓存太小导致频繁重新翻译、或者 FEX 的优化选项没有开启。可以尝试调整 FEX 的配置比如增大缓存、开启更多优化。如果 CPU 时间主要花在图形转换上那瓶颈在图形层。可能的原因包括状态切换太频繁、着色器编译太慢、或者显存管理效率低。可以尝试调整图形层的配置比如开启着色器缓存、调整同步选项、或者换一个图形后端。如果 CPU 时间花在 Wine 上那瓶颈在 API 实现。可能的原因包括某个 API 的实现效率低、或者程序频繁调用某个开销大的 API。这种情况比较难优化因为 Wine 的实现不是你能改的。可以尝试换一个 Wine 版本或者看有没有社区补丁。5.4 图形渲染异常纹理、着色器与同步的排查顺序图形渲染异常的表现很多纹理错位、颜色不对、模型缺失、画面闪烁。排查顺序建议从简单到复杂先确认是不是着色器问题再确认是不是纹理问题最后确认是不是同步问题。着色器问题的特征是某些物体渲染不出来或者渲染出来的颜色不对。可以看 DXMT 的日志确认着色器是否编译成功有没有编译警告或错误。如果着色器编译失败可能需要换一个转换层或者等 DXMT 更新。纹理问题的特征是纹理错位、拉伸、或者显示成纯色。这通常是纹理格式转换的问题DirectX 和 Metal 支持的纹理格式不完全一样转换层需要做映射。如果映射不对纹理就会显示异常。可以尝试调整纹理格式的配置或者看有没有相关的兼容性选项。同步问题的特征是画面撕裂、闪烁、或者偶尔出现一帧异常。这通常是同步机制不匹配导致的。可以尝试调整同步选项比如开启或关闭垂直同步、调整帧队列大小。这类问题往往需要反复试验才能找到合适的配置。6. 这套方案适合谁以及我在实际使用中的几点体会Madeira 这类基于 FEX-Emu 和 Wine 的方案适合的场景其实比较明确你有一个必须在 ARM 设备上运行的 x86-64 程序这个程序没有 ARM 版本也没有其他替代方案并且你愿意花时间配置和调试。如果程序有 ARM 版本或者有功能等价的替代品那直接用原生方案更省事。不适合的场景也很明确对性能要求极高的程序、依赖特定硬件或驱动的程序、以及需要长期稳定运行的生产环境。翻译层的性能损失是客观存在的兼容性问题也可能随时出现。如果程序跑不起来会影响业务那还是老老实实买一台 x86 机器更稳妥。我在实际使用中的体会是这套方案的成熟度在不断提高但离“开箱即用”还有距离。FEX 的指令翻译已经相当稳定大部分常见指令都能正确处理。Wine 的 API 覆盖也很广很多程序不需要额外配置就能跑。图形层是最薄弱的一环尤其是 DirectX 12 和较新的图形特性兼容性问题比较多。另一个体会是社区很重要。FEX、Wine、DXMT 都是开源项目社区里有大量的配置示例和问题讨论。遇到问题时先搜一下有没有人遇到过类似的情况往往能省很多时间。如果搜不到再自己排查排查的过程也要记录下来方便以后参考。最后分享一个小技巧在配置新程序时先用最简单的配置跑一遍确认基本功能正常再逐步添加优化选项。不要一上来就把所有优化都打开否则出了问题很难定位是哪个选项导致的。每次只改一个选项改完测试确认效果后再改下一个。这个习惯能帮你省下大量排查时间。