1. 项目缘起为什么我要折腾 Madeira 这套跨架构兼容方案第一次看到 Madeira 这个词很多人会以为是葡萄牙那个产葡萄酒的岛屿。但在我们这群折腾系统兼容层的人眼里它指向的是另一件事——一套围绕FEX-Emu、Wine、DXMT搭建起来的跨架构运行环境组合。简单说它的目标就是让 x86-64 平台的 Windows 应用和游戏能在 ARM 设备尤其是 Apple Silicon 的 Mac、以及部分 ARM Linux 设备上跑起来而且尽量跑得动、跑得顺。我接触这套东西的起因很朴素手里有一台 M 系列芯片的 Mac同时又有一堆只发 Windows 版的工具软件和老游戏。原生方案要么没有要么体验稀碎。于是我开始研究 FEX-Emu 做指令翻译、Wine 做 Windows API 转译、DXMT 把 DirectX 调用翻译到 Metal 这条链路。折腾了小半年踩的坑能写满一个笔记本今天就把这套 Madeira 组合的完整思路和实操细节摊开讲。这篇文章适合三类人看一是想在 ARM 设备上跑 Windows 程序、但被各种兼容层名词绕晕的新手二是已经用过 Wine 但卡在图形或性能瓶颈上的进阶玩家三是想理解 指令翻译 API 转译 图形翻译 三层架构到底怎么协作的技术爱好者。我会从整体设计讲到具体配置再到排查实录尽量让每个人都能抄到作业。需要先说明一点本文讨论的所有工具都是开源或公开可获取的兼容层项目用途是提升自有设备上的软件兼容性不涉及任何规避授权或违规使用的场景。下面进入正题。2. 整体架构拆解三层翻译到底各管什么2.1 从 CPU 指令 到 系统调用 再到 图形 API 的分工要理解 Madeira 这套组合得先建立一个分层模型。一台 ARM Mac 想运行 x86-64 的 Windows 游戏中间隔着三道鸿沟每一道都需要专门的翻译层来填。第一道鸿沟是CPU 指令集。ARM 和 x86-64 的机器码完全不兼容x86 程序在 ARM 上根本无法直接执行。这一层由FEX-Emu负责它做的是动态二进制翻译Dynamic Binary Translation把 x86-64 指令实时翻译成 ARM64 指令。你可以把它想象成一个同声传译程序每执行一条指令它就在旁边翻译一条。第二道鸿沟是操作系统 API。Windows 程序调用的是kernel32.dll、user32.dll这些 Windows 系统库而 macOS 或 Linux 根本没有这些。这一层由Wine负责它实现了 Windows API 的兼容层把CreateWindow、ReadFile这类调用映射到宿主系统的对应功能上。Wine 不是模拟器它不翻译指令只翻译 API 调用。第三道鸿沟是图形 API。Windows 游戏大量使用 DirectX尤其是 D3D11、D3D12而 Apple 平台只有 Metal。这一层由DXMT负责它把 Direct3D 的调用翻译成 Metal 调用。DXMT 是近年比较活跃的一个项目相比早期的 DXVK MoltenVK 组合它在 D3D11 上的兼容性和性能表现更直接。三层叠起来一个 x86-64 Windows 游戏的调用链大致是这样的游戏发出 x86 指令 → FEX-Emu 翻译成 ARM64 → 游戏调用 D3D → DXMT 翻译成 Metal → 游戏调用 Windows API → Wine 翻译成 macOS 调用 → 最终在屏幕上呈现画面。2.2 为什么是这三个组合而不是别的方案市面上做类似事情的方案不少我选这套组合是有具体理由的。先说 FEX-Emu。同类方案里还有 Box64、QEMU 用户态等。Box64 在 ARM Linux 上很成熟但在 macOS 上的支持相对弱一些QEMU 用户态通用性强但性能开销大。FEX-Emu 的优势在于它对 x86-64 的翻译做了大量针对性优化尤其是对 SSE、AVX 指令的处理而且它在 Apple Silicon 上的适配一直在跟进。实测下来同样的游戏FEX-Emu 的帧率通常比 QEMU 用户态高出一截。再说 Wine。这个没什么好纠结的Windows API 兼容层里 Wine 是事实标准生态最全社区最活跃。CrossOver 本质上是 Wine 的商业封装底层是同一套东西。选 Wine 就是选生态。最后说 DXMT。图形翻译这块早期大家用 DXVKD3D 转 Vulkan再套 MoltenVKVulkan 转 Metal链路长、损耗大。DXMT 直接把 D3D 翻译到 Metal少了一层理论上效率更高。实测在 D3D11 游戏上DXMT 的兼容性确实更好很多 DXVK 跑不起来的游戏它能跑。D3D12 方面 DXMT 还在完善中但进步很快。提示这套组合目前主要面向 Apple Silicon 的 macOS 环境ARM Linux 上也能用但配置路径差异较大本文以 macOS 为主线Linux 部分会单独说明差异点。2.3 性能预期别指望原生但可以期待 能玩在动手之前必须把预期摆正。三层翻译叠加性能损耗是必然的。我的经验是CPU 密集型任务比如编译、模拟器性能大约是原生的 50% 到 70%GPU 密集型任务游戏取决于图形翻译层的成熟度D3D11 游戏通常能到原生的 40% 到 60%D3D12 游戏波动更大。这个数字听起来不高但对于很多老游戏和轻量工具来说已经足够流畅了。比如一些 2015 年前后的独立游戏、2D 游戏、策略游戏跑起来基本无感。3A 大作就比较吃力能进游戏、能玩但帧率不会太好看。我个人的判断标准是如果你的目标软件是 能用就行这套方案完全值得折腾如果你追求 60 帧满特效那还是老老实实找原生版本或者用别的设备。3. 环境准备从零搭建 Madeira 运行环境3.1 基础依赖与工具链清单搭建之前先把需要的东西列清楚。我按 必需 和 可选 分开避免新手一上来就被一堆名词劝退。必需项一台 Apple Silicon MacM1 及以上系统版本建议 macOS 13 以上太老的系统对 Metal 特性支持不全。HomebrewmacOS 上的包管理器后面装依赖全靠它。Xcode Command Line Tools提供编译工具链xcode-select --install一条命令搞定。FEX-Emu指令翻译层可以从源码编译或使用预编译版本。Wine建议用社区维护的 macOS 版本比如 Wine-Crossover 或自己编译的 Wine。DXMT图形翻译层需要和 Wine 一起编译或作为插件加载。可选项Winetricks用来快速安装 Windows 运行库如 .NET、VC 运行库强烈建议装上能省很多事。一个 Windows 应用容器管理工具比如 Whisky 或自己写的脚本用来管理不同的 Wine prefix。性能监控工具比如活动监视器或asitop用来观察翻译层的 CPU 占用。这里要特别提醒Wine 的版本和 DXMT 的版本必须匹配。DXMT 是作为 Wine 的图形驱动插件工作的版本不匹配会导致加载失败或者崩溃。我踩过这个坑折腾了一下午才发现是版本对不上。3.2 安装 FEX-Emu 与 Wine 的实操步骤先装 FEX-Emu。如果你不想自己编译可以找社区提供的预编译包。自己编译的话大致流程是这样git clone https://github.com/FEX-Emu/FEX.git cd FEX git submodule update --init --recursive mkdir Build cd Build cmake -DCMAKE_BUILD_TYPERelease -DCMAKE_INSTALL_PREFIX/usr/local .. make -j$(sysctl -n hw.ncpu) sudo make install编译过程比较吃 CPUM1 上大概要十几分钟。编译完成后FEXInterpreter这个可执行文件就是核心。接下来装 Wine。macOS 上装 Wine 有几种路子用 Homebrew 装wine-stable或者用 CrossOver 的 Wine 版本或者自己编译。我推荐用社区维护的 macOS Wine 构建因为官方 Wine 在 macOS 上的适配经常滞后。brew install --cask --no-quarantine wine-stable装完之后验证一下wine --version能输出版本号就说明装好了。这时候 Wine 默认还是跑 x86 指令的通过 Rosetta 2要让它走 FEX-Emu需要设置环境变量或者用 FEX 的 loader 来启动。3.3 DXMT 的编译与加载配置DXMT 的编译相对复杂一些因为它需要和 Wine 的头文件配合。基本流程是git clone https://github.com/3Shain/dxmt.git cd dxmt # 根据 README 设置 Wine 源码路径 export WINE_SOURCE/path/to/wine/source make编译产物是一组.so或.dylib文件需要放到 Wine 的对应目录下。具体来说d3d11.dll、dxgi.dll这些要被替换成 DXMT 的版本。配置加载的关键是让 Wine 知道用 DXMT 而不是内置的 wined3d。通常通过设置注册表或者环境变量来实现export WINEDLLOVERRIDESd3d11,dxgin,b这行的意思是d3d11 和 dxgi 这两个 DLL 优先使用原生native版本也就是 DXMT 提供的版本而不是 Wine 内置的。注意WINEDLLOVERRIDES的语法是dllname加载顺序n表示 nativeb表示 builtin。n,b表示先试 native 再试 builtin。写反了会导致加载错误的 DLL。3.4 创建和管理 Wine Prefix 的正确姿势Wine prefix 是每个 Windows 应用的独立 虚拟 C 盘里面装着这个应用的注册表、DLL、配置文件。不同应用用不同的 prefix 是好习惯避免互相污染。创建 prefix 的命令export WINEPREFIX~/wineprefixes/mygame export WINEARCHwin64 wineboot -uwineboot -u会初始化 prefix第一次运行会弹出一堆安装提示耐心等它跑完。我个人的习惯是给每个游戏或工具单独建一个 prefix命名清晰比如~/wineprefixes/game_a、~/wineprefixes/tool_b。这样某个 prefix 玩坏了直接删掉重建不影响其他的。prefix 建好之后用winetricks装一些常用运行库winetricks corefonts vcrun2019 dotnet48corefonts解决字体乱码问题vcrun2019和dotnet48是很多程序的基础依赖。这一步能省掉后面一大堆 缺少 DLL 的报错。4. 核心环节实现让游戏真正跑起来4.1 启动流程与参数配置详解环境搭好之后启动一个 Windows 程序的完整命令大概长这样export WINEPREFIX~/wineprefixes/mygame export WINEDLLOVERRIDESd3d11,dxgin,b export FEX_ROOTFS/path/to/fex/rootfs FEXInterpreter wine /path/to/game.exe这里有几个关键点要解释。FEX_ROOTFS是 FEX-Emu 的根文件系统路径它里面装着 x86-64 的 Linux 库文件。因为 FEX 翻译的是 Linux 的 x86-64 程序而 Wine 在 macOS 上跑的是经过适配的版本所以这个路径要指向正确的 rootfs。FEXInterpreter wine ...这个写法是让 FEX 来加载 Wine而不是让系统直接加载。这样 Wine 本身以及它加载的所有 x86 代码都会经过 FEX 翻译。如果你用的是 Whisky 这类图形化管理工具它会在后台帮你拼好这些参数你只需要在界面里选好 prefix 和可执行文件就行。但理解底层命令对排查问题很有帮助出问题的时候能自己定位。4.2 图形层调试DXMT 日志与常见报错DXMT 跑不起来的时候第一件事是打开日志。设置环境变量export DXMT_LOG_LEVELdebug export DXMT_LOG_FILE~/dxmt.log然后启动程序看日志里报什么。常见的几类错误第一类是DLL 加载失败日志里会出现Failed to load d3d11.dll之类的字样。这通常是WINEDLLOVERRIDES没设对或者 DXMT 的 DLL 没放到正确目录。第二类是Metal 特性不支持比如MTLFeatureSet相关的报错。这通常是游戏用了比较新的 D3D 特性而当前 DXMT 版本还没实现。解决办法是升级 DXMT或者换用 DXVK MoltenVK 的组合试试。第三类是着色器编译失败日志里会有shader compilation error。这类问题比较棘手通常是游戏的着色器用了 DXMT 还没支持的语法。可以尝试在游戏设置里降低画质或者关闭某些特效。我整理了一个常见报错对照表报错关键词可能原因处理方向Failed to load d3d11DLL 覆盖设置错误检查 WINEDLLOVERRIDESMTLFeatureSet unsupportedMetal 特性不支持升级 DXMT 或降级游戏设置shader compilation error着色器语法不支持降低画质或换图形后端out of memory显存或内存不足降低分辨率或关闭后台程序device lostGPU 上下文丢失更新系统或降低负载4.3 性能调优从 能跑 到 跑得顺程序能启动只是第一步跑得顺才是目标。性能调优我总结了几个方向。CPU 侧FEX-Emu 的翻译缓存大小会影响性能。默认配置下翻译缓存可能不够大导致频繁重新翻译。可以在 FEX 的配置文件里调大缓存{ CacheSize: 512, Multiblock: true, SMCChecks: mtrack }Multiblock开启多块翻译能减少翻译次数SMCChecks设置成mtrack能优化自修改代码的检测。这两个选项对性能提升比较明显。GPU 侧DXMT 的性能和 Metal 命令缓冲的提交策略有关。可以尝试调整DXMT_MAX_FRAME_LATENCY这个环境变量默认是 3调低到 2 能减少延迟但可能增加卡顿调高到 4 更平滑但延迟增加。这个要根据具体游戏试。内存侧Wine prefix 里的user.reg可以调整一些 Windows 层面的内存参数。比如增大HeapSize对某些老游戏有帮助。分辨率这是最直接的性能杠杆。很多游戏在 1080p 下跑不动降到 720p 就流畅了。配合 Metal 的缩放画面观感不会差太多。4.4 输入与外设手柄、键盘映射的坑游戏能跑之后下一个问题是操作。Wine 对 Windows 手柄 APIXInput的支持是通过映射到宿主系统的游戏控制器框架实现的。macOS 上XInput 会被映射到 GameController 框架。大部分 Xbox 手柄即插即用但有些第三方手柄需要额外配置。如果手柄不识别可以试试export SDL_JOYSTICK_HIDAPI1这会让 SDL 走 HIDAPI 路径识别手柄兼容性更好。键盘映射方面Wine 默认的键位映射基本够用但有些游戏会用到特殊键比如 PrintScreen、ScrollLock这些在 Mac 键盘上可能没有对应键。解决办法是用 Karabiner 之类的工具做键位重映射或者在 Wine 的注册表里手动改键位映射表。提示如果你用的是蓝牙手柄连接稳定性很重要。我遇到过手柄玩着玩着断连的情况后来换成有线连接就稳了。无线手柄在翻译层下延迟也会略高竞技类游戏建议有线。5. 常见问题与排查技巧实录5.1 启动即崩溃从日志定位问题程序双击就闪退是最常见也最让人抓狂的问题。我的排查顺序是这样的。第一步看 Wine 的 stderr 输出。启动命令后面加21 | tee wine.log把所有输出存下来。崩溃原因通常就在最后几行。第二步看 DXMT 日志。如果崩溃发生在图形初始化阶段DXMT 日志里会有线索。第三步看系统日志。macOS 的Console.app里能查到进程崩溃的详细堆栈有时候能定位到具体是哪个 DLL 出的问题。我遇到过一个典型案例某游戏启动就崩Wine 日志显示Unhandled exception: page faultDXMT 日志正常。最后发现是游戏依赖的一个音频库在翻译层下有问题用winetricks装了个替代的音频库就好了。5.2 画面异常花屏、黑屏、贴图错误的处理画面问题分几种。黑屏但有声音通常是图形初始化失败但音频正常。检查 DXMT 是否加载成功WINEDLLOVERRIDES是否生效。花屏或贴图错乱通常是着色器翻译有问题。尝试在 DXMT 配置里关闭某些优化选项或者换用 DXVK 后端对比一下。画面撕裂这是垂直同步的问题。Wine 的 vsync 设置和 Metal 的呈现模式要配合。可以试试设置vblank_mode1环境变量。分辨率不对Wine 的虚拟桌面模式可以强制分辨率。在winecfg里开启 Emulate a virtual desktop设置成你想要的分辨率。5.3 字体乱码与中文显示问题Wine 下的中文乱码是老问题了。热词里 wine 乱码、wine 栏是乱码 出现频率很高说明这是普遍痛点。根本原因是 Wine 默认没有中文字体或者字体映射表不对。解决办法第一步装中文字体winetricks corefonts cjkfontscjkfonts会装一套中日韩字体覆盖大部分场景。第二步如果还有乱码手动把 macOS 的字体链接到 Wine 的字体目录ln -s /System/Library/Fonts/PingFang.ttc ~/wineprefixes/mygame/drive_c/windows/Fonts/第三步改注册表里的字体替换表。在winecfg的 Graphics 标签页里或者直接编辑user.reg把MS Shell Dlg、Tahoma这些默认字体映射到中文字体上。我实测下来cjkfonts加手动链接 PingFang 这套组合能解决 95% 以上的中文乱码问题。剩下的是某些程序自己带了字体文件那就得单独处理。5.4 性能突然下降的排查思路有时候程序一开始跑得好好的玩着玩着突然变卡。这种 性能衰减 问题排查起来比较麻烦。首先排除宿主系统的问题打开活动监视器看是不是有其他进程在抢资源。macOS 的后台索引、iCloud 同步、系统更新都可能突然吃满 CPU。其次看翻译层FEX-Emu 的翻译缓存如果被填满会触发清理和重新翻译导致卡顿。调大缓存能缓解。再看图形层DXMT 的着色器缓存如果没命中会实时编译着色器造成卡顿。第一次进新场景卡是正常的第二次还卡就有问题。可以检查 DXMT 的着色器缓存目录是否可写。最后看内存Wine prefix 下的程序如果内存泄漏会越跑越卡。这种情况只能重启程序。我整理了一个性能问题速查表现象优先排查次要排查启动就卡翻译缓存大小宿主 CPU 占用玩一会变卡内存泄漏着色器缓存特定场景卡着色器编译显存占用全局都卡分辨率设置后台进程5.5 我踩过的三个典型坑与解决方案第一个坑版本不匹配导致 DXMT 静默失败。DXMT 加载失败时不一定报错程序会用 Wine 内置的 wined3d 跑性能差一大截但你不一定发现。后来我养成了习惯每次配置完都看一遍 DXMT 日志确认它真的加载了。第二个坑prefix 混用导致注册表污染。我一开始图省事所有游戏共用一个 prefix结果装了某个游戏的运行库之后另一个游戏反而跑不起来了。后来改成每个游戏独立 prefix世界清净了。第三个坑环境变量没导出到子进程。Wine 启动游戏时会 fork 子进程如果环境变量只在当前 shell 设置而没 export子进程读不到。这个坑很隐蔽表现是 命令行里设置了但游戏里没生效。解决办法就是所有环境变量都用export。6. 扩展场景Madeira 思路还能用在哪6.1 ARM Linux 上的差异化配置同样的三层架构搬到 ARM Linux 上差异主要在宿主系统层。Linux 上 Wine 的成熟度其实比 macOS 更高因为 Wine 本来就是为 Linux 设计的。FEX-Emu 在 Linux 上也有原生支持。主要差异点Linux 上不需要 Rosetta 2 这层FEX 直接对接系统调用图形层可以用 DXMT 也可以用 DXVK 系统 Vulkan 驱动prefix 管理可以用WINEPREFIX环境变量也可以用 Bottles 这类图形工具。配置思路上Linux 上更推荐用 DXVK因为 Vulkan 驱动在 Linux 上更成熟。DXMT 主要优势在 macOS 的 Metal 上Linux 上优势不明显。6.2 从游戏扩展到生产力工具这套方案不只用来玩游戏。我实际用它跑过一些只有 Windows 版的工具软件比如某些硬件调试工具、老版本的 CAD 软件、特定的数据采集程序。生产力工具和游戏的区别在于对图形性能要求低但对稳定性和数据准确性要求高。这类场景下我建议关闭所有图形优化选项优先保证稳定。DXMT 的调试模式虽然慢一点但更不容易出问题。另外生产力工具往往依赖特定的运行库比如 .NET Framework 的某个版本、特定的 VC 运行库用winetricks提前装好能省很多事。6.3 移动端与嵌入式设备的可能性热词里出现了 ios、ios 游戏、ios 设备模拟 这些词说明有人关心移动端。说实话iOS 上跑这套方案目前不现实因为 iOS 不允许加载外部可执行代码Wine 和 FEX 都没法在未越狱的设备上运行。但 ARM 嵌入式设备比如树莓派、各种 ARM 开发板上是有可能的。这些设备跑 ARM Linux理论上可以套用 FEX Wine DXVK 的组合。性能取决于设备本身的算力高端开发板跑一些轻量 Windows 程序是可行的。这个方向我还在探索目前的体会是嵌入式设备的内存和存储往往是瓶颈prefix 要尽量精简不必要的运行库别装。7. 一些实操心得与后续折腾方向折腾 Madeira 这套组合小半年最大的体会是兼容层的问题80% 出在配置而不是代码。同样的工具配置对了流畅运行配置错了各种玄学崩溃。所以我的建议是每次改动只改一个变量改完立刻验证出问题能快速定位是哪个改动导致的。另一个心得是日志是你的朋友。Wine 的 stderr、DXMT 的日志、macOS 的 Console这三个地方能解决绝大多数问题。养成看日志的习惯比在网上到处搜 XX 游戏怎么跑 效率高得多。后续我打算继续折腾的方向有两个一是把 DXMT 的 D3D12 支持摸透目前这块还在快速迭代值得跟进二是研究怎么把这套环境做成可复用的脚本或容器让配置过程标准化减少重复劳动。最后分享一个小技巧如果你不确定某个游戏能不能跑先去社区查一下别人的测试结果。很多兼容层项目都有用户提交的兼容性数据库比如 Wine 的 AppDB、ProtonDB 这类。花五分钟查一下能省掉两小时的瞎折腾。