1. 从Madeira这个名字说起一个跨平台兼容层的真实需求第一次看到Madeira这个项目名加上关键词里那一串 Wine、FEX-Emu、DXMT、x86-64、iOS我脑子里第一反应是这又是一个想在非 Windows 平台上跑 Windows 程序的兼容层项目。Wine 本身是Wine Is Not an Emulator的递归缩写而 Madeira 是葡萄牙的一座岛屿盛产葡萄酒——这个命名逻辑其实挺直白的就是围绕 Wine 生态做文章。但真正让我感兴趣的是关键词里同时出现了 FEX-Emu 和 DXMT。FEX-Emu 是一个用户态的 x86-64 到 ARM64 的指令翻译层DXMT 则是把 D3D 调用翻译成 Metal 的图形层。这两个东西加上 Wine组合起来指向一个非常明确的技术目标在 ARM 架构的设备上尤其是 Apple Silicon 的 Mac 和 iOS 设备运行原本为 x86-64 Windows 编译的应用程序和游戏。这个需求是真实存在的。Apple 从 M 系列芯片开始全面转向 ARMRosetta 2 虽然能翻译 x86-64 的 macOS 程序但它管不了 Windows 的 PE 可执行文件。而 Wine 在 macOS 上长期依赖 CrossOver 这类商业方案底层还是靠 Rosetta 2 做指令翻译。一旦你想在 iOS 或者纯 ARM 的 Linux 环境里跑 Windows 程序就需要自己搭一套完整的翻译链路PE 加载 → Windows API 实现 → x86-64 指令翻译 → 图形 API 转换 → 系统调用映射。Madeira 要解决的就是把这套链路整合成一个可用的整体。它不是一个从零开始的新轮子而是把 Wine、FEX-Emu、DXMT 这几个成熟组件粘合起来处理它们之间的接口对接、版本匹配、性能调优问题。这类胶水项目看起来不如底层组件光鲜但实际落地时踩的坑一点不少——组件之间的 ABI 兼容、线程模型的冲突、图形上下文的生命周期管理每一个都能让人调上好几天。这篇文章我会从实际搭建和调试的角度把这条技术链路拆开讲清楚。适合两类人看一是想在 ARM 设备上跑 Windows 程序、被各种兼容性问题折磨过的开发者二是对 Wine 生态、指令翻译、图形 API 转换这些底层机制感兴趣想搞明白它们怎么协同工作的技术爱好者。不管你是哪一类我都会尽量把为什么这么设计讲透而不是只丢一堆命令让你照抄。2. Wine 在 ARM 上的真实处境为什么光有 Wine 不够2.1 Wine 到底做了什么又没做什么很多人对 Wine 的理解停留在能在 Linux 上跑 exe这个层面但具体它负责哪一段、不负责哪一段往往说不清楚。我用一个类比来解释把 Windows 程序想象成一个只会说中文的人Linux/macOS 系统是一个只会说英文的环境。Wine 做的事情是当翻译把 Windows API 调用中文翻译成 POSIX 系统调用英文。它翻译的是语言不是口音。问题在于Windows 程序编译出来的是 x86 或 x86-64 的机器码这是口音层面的东西。Wine 本身不做指令翻译它假设你的 CPU 能直接执行这些机器码。在 x86 的 Linux 上这没问题CPU 原生就能跑。但到了 ARM 设备上CPU 根本听不懂 x86-64 的指令Wine 翻译出来的 API 调用再正确也没用因为程序本身的代码就跑不起来。这就是为什么在 Apple Silicon Mac 上Wine 必须依赖 Rosetta 2。Rosetta 2 负责把 x86-64 指令翻译成 ARM64 指令Wine 负责把 Windows API 映射到 macOS 的系统调用。两者配合程序才能跑起来。但 Rosetta 2 是 Apple 的私有技术只在 macOS 上可用iOS 上虽然底层有类似机制但苹果不开放给第三方应用调用。所以在 iOS 或者非 Apple 的 ARM Linux 设备上你需要一个开源的 x86-64 翻译层——这就是 FEX-Emu 登场的地方。2.2 FEX-Emu 的定位和它带来的新问题FEX-Emu 最初是为 Linux ARM 设备设计的目标是在 ARM64 Linux 上运行 x86-64 的 Linux 程序。它的工作方式是动态二进制翻译程序运行时FEX-Emu 把 x86-64 指令块翻译成 ARM64 指令块缓存起来下次执行到同一块代码时直接复用。这跟 QEMU 的用户态模拟类似但 FEX-Emu 针对游戏场景做了大量优化比如对 SSE/AVX 指令的高效模拟、对系统调用的直接透传。把 FEX-Emu 和 Wine 组合起来链路就变成了Windows PE 程序 → WineAPI 翻译→ FEX-Emu指令翻译→ ARM64 Linux 系统调用。听起来很清晰但实际组合时会遇到几个硬骨头。第一个是线程本地存储TLS的冲突。Wine 有自己的 TLS 机制来模拟 Windows 的线程环境FEX-Emu 也需要 TLS 来管理翻译缓存和 CPU 状态。两者如果对 TLS 的使用方式不兼容就会出现线程崩溃或者数据错乱。这个问题在单线程程序上可能不明显一旦程序开多线程现代游戏几乎没有单线程的就会频繁触发。第二个是信号处理的嵌套。Wine 用信号来实现 Windows 的异常处理机制比如 SEHFEX-Emu 也用信号来处理翻译过程中的异常和中断。当两层信号处理嵌套在一起时信号掩码的管理、栈的切换、上下文的保存恢复任何一个环节出问题都会导致程序莫名其妙地挂掉而且这种崩溃往往没有明确的错误信息调试起来非常痛苦。第三个是内存模型的差异。x86-64 是强内存模型ARM64 是弱内存模型。FEX-Emu 需要在翻译过程中插入适当的内存屏障指令来保证语义正确但这会带来性能开销。Wine 内部的一些同步原语如果假设了强内存模型在 ARM 上就可能出现竞态条件。这类问题在测试时不一定能复现但在实际使用中会偶发。2.3 版本匹配一个容易被低估的坑Wine、FEX-Emu、DXMT 这三个组件的版本兼容性是我踩过的最大的坑之一。它们各自独立开发发布节奏不同接口也在不断变化。Wine 的某个版本可能修改了底层的内存分配接口而 FEX-Emu 的对应适配还没跟上结果就是编译能过、启动就崩。我的经验是不要盲目追新。如果你看到某个组合能跑通先把这套版本号记下来不要随便升级其中任何一个组件。等社区确认新版本组合稳定了再整体升级。具体来说Wine 建议用 8.x 的稳定分支FEX-Emu 用最近半年内的 releaseDXMT 则要跟 Wine 的版本对应——DXMT 的 README 里通常会写明它适配的 Wine 版本范围这个信息一定要看。另外编译顺序也有讲究。FEX-Emu 需要先编译安装因为它提供了 RootFS 和工具链然后编译 Wine 时要指定使用 FEX-Emu 的编译器包装器最后编译 DXMT 时要链接 Wine 的开发库。顺序错了链接阶段就会报找不到符号。3. DXMT 的角色把 D3D 翻译成 Metal 的得与失3.1 为什么不用 DXVK 或 VKD3D在 Linux 上跑 Windows 游戏大家熟悉的方案是 DXVKD3D9/10/11 → Vulkan和 VKD3D-ProtonD3D12 → Vulkan。这两个项目非常成熟性能也很好。但在 macOS 和 iOS 上Vulkan 的支持是个问题。macOS 原生不支持 Vulkan只能通过 MoltenVK 把 Vulkan 转成 Metal多一层转换就多一层开销和兼容性问题。DXMT 的思路更直接跳过 Vulkan直接把 D3D 调用翻译成 Metal。这样做的好处是链路更短理论上延迟更低而且能更好地利用 Metal 的特性比如 Metal 的 argument buffer、heap 管理。坏处是 DXMT 的成熟度远不如 DXVK很多 D3D 的特性支持不完整遇到复杂的游戏就容易出问题。我实测下来DXMT 对 D3D11 的支持还算可用大部分独立游戏和部分 3A 游戏能跑起来但帧率波动比较大。D3D12 的支持就更初级了很多依赖高级特性的游戏直接黑屏或者崩溃。如果你主要想跑 D3D9 的老游戏DXMT 的表现反而比较稳因为 D3D9 的 API surface 小翻译起来简单。3.2 Metal 命令行队列的提交时机DXMT 里有一个设计细节值得单独说Metal 的命令队列提交时机。D3D 的 Present 调用和 Metal 的 presentDrawable 不是一一对应的。D3D 程序可能在一帧内多次调用 Present比如某些 UI 渲染逻辑而 Metal 的 drawable 数量有限如果每次 Present 都去获取新的 drawable很快就会耗尽导致卡顿。DXMT 的处理方式是维护一个命令缓冲队列把多次 D3D 的绘制调用合并到较少的 Metal 命令缓冲里在合适的时机统一提交。这个合适的时机的判断逻辑很关键提交太早合并效果差提交太晚输入延迟高。DXMT 默认的策略是基于帧边界和队列深度来触发提交但在实际使用中我发现对于快节奏的动作游戏手动调低队列深度阈值能明显改善操作手感代价是帧率可能略微下降。这个参数在 DXMT 的配置里通常叫maxFrameLatency或者类似的名称具体取决于版本。调的时候建议从默认值开始每次减 1观察手感和帧率的平衡点。我自己的经验是大部分游戏设在 2 到 3 之间比较合适再低就容易出现画面撕裂。3.3 着色器编译卡顿的缓解D3D 游戏的着色器是在运行时编译的DXMT 需要把 D3D 的 HLSL 字节码翻译成 Metal 的着色器语言再交给 Metal 编译器编译。这个过程的耗时在 ARM 设备上比 x86 桌面明显更长导致游戏首次遇到新场景时会出现严重的卡顿。缓解办法有几个。一是开启 DXMT 的着色器缓存把编译好的 Metal 着色器存到磁盘下次直接加载。这个功能默认可能是关的需要在配置里显式打开。二是预编译有些游戏支持在加载界面预编译所有着色器虽然加载时间变长但游戏过程更流畅。三是降低着色器复杂度比如关闭一些后处理效果减少需要编译的着色器变体数量。需要提醒的是着色器缓存和 Wine 的版本、DXMT 的版本是绑定的。升级任何一个组件后旧缓存可能失效甚至导致崩溃这时候要手动清掉缓存目录重新生成。缓存目录的位置通常在~/Library/Caches或者 Wine prefix 的drive_c下面具体路径看 DXMT 的文档。4. 从零搭建 Madeira 环境的完整链路4.1 基础依赖的安装顺序搭建这套环境顺序很重要。我推荐的顺序是先装 FEX-Emu再装 Wine最后装 DXMT。原因前面提过Wine 编译时需要 FEX-Emu 提供的工具链DXMT 编译时需要 Wine 的开发头文件和库。FEX-Emu 的安装有两种方式用预编译的二进制包或者从源码编译。预编译包省事但可能跟你的系统库版本不匹配源码编译耗时在 ARM 设备上可能要一两个小时但兼容性更好。如果你用的是比较新的 ARM Linux 发行版建议先试预编译包跑不通再自己编。编译 FEX-Emu 时有一个关键配置ENABLE_LTO。链接时优化能提升翻译后代码的性能但会显著增加编译时间和内存占用。在内存小于 8GB 的设备上建议关掉 LTO否则编译过程可能因为 OOM 被杀掉。另外CMAKE_BUILD_TYPE要设成ReleaseDebug 版本的性能差很多不适合实际使用。Wine 的编译配置里--enable-archs参数要包含i386,x86_64因为很多 Windows 程序还是 32 位的只编译 64 位会跑不了。--with-fex或者类似的参数用来指定 FEX-Emu 的路径具体名称看 Wine 的版本。编译 Wine 是个体力活在 ARM 设备上可能要三四个小时建议用make -j$(nproc)并行编译但要注意内存占用核心数多的机器可能反而因为内存不足而变慢。4.2 Wine prefix 的创建与配置Wine prefix 是 Wine 模拟的 Windows 环境每个 prefix 相当于一个独立的 Windows 安装。创建 prefix 用wineboot命令但直接跑wineboot可能会因为默认配置不适合 ARM 环境而失败。我建议先设置几个环境变量export WINEARCHwin64 export WINEPREFIX~/madeira-prefix export FEX_ROOTFS~/fex-rootfsWINEARCHwin64创建 64 位 prefix虽然也能跑 32 位程序通过 WoW64但配置更简单。FEX_ROOTFS指向 FEX-Emu 的根文件系统里面包含了 x86-64 的基础库Wine 在翻译指令时需要用到。创建完 prefix 后第一件事是装winetricks然后用它安装一些基础组件corefonts字体、vcrun2019Visual C 运行库、dotnet48.NET Framework很多游戏需要。这些组件在 ARM 上安装可能会失败因为它们的安装程序本身也是 x86 代码需要 FEX-Emu 正确翻译。如果安装失败可以试试用winetricks -q的静默模式或者手动下载组件的离线安装包放到 prefix 里安装。4.3 图形驱动的对接DXMT 编译出来后需要把它的 DLL 放到 Wine prefix 的对应目录里通常是drive_c/windows/system32。然后要用winecfg或者注册表把 D3D 的 DLL 重定向到 DXMT 的版本。这一步如果没做对Wine 会用自己的 D3D 实现WineD3D性能差很多而且很多游戏跑不起来。注册表的关键项是HKEY_CURRENT_USER\Software\Wine\DllOverrides把d3d11、dxgi、d3d10core这些键的值设成native表示优先使用 DXMT 提供的 DLL。改完注册表后要重启 Wine 才生效。Metal 的验证层在调试时很有用可以通过环境变量MTL_DEBUG_LAYER1开启。开启后Metal 的 API 调用会被检查不合法的调用会打印警告或直接报错。这个功能在排查黑屏、花屏问题时特别有用因为很多图形问题根源是 API 使用不当而不是翻译逻辑错误。但验证层会拖慢性能正式使用时记得关掉。5. 实测中遇到的典型问题与排查思路5.1 程序启动即崩溃没有任何错误信息这是最常见也最难查的问题。程序双击后闪一下就没了终端里也没有输出。遇到这种情况我的排查顺序是这样的第一步用WINEDEBUGall跑一遍把 Wine 的所有调试输出打到日志文件里。日志会非常大但能看出程序走到哪一步挂的。重点看最后几行通常是某个 DLL 加载失败或者某个 API 调用返回了错误。第二步如果 Wine 的日志看不出问题用 FEX-Emu 的调试模式跑。FEX-Emu 有FEX_LOG_LEVEL环境变量设成debug或者trace能看到指令翻译的详细过程。如果程序在翻译阶段就崩了日志会停在某条指令上那条指令就是嫌疑对象。第三步检查是不是缺少依赖。用ldd看 Wine 的二进制依赖是否都满足用wine的loaddll调试通道看程序加载了哪些 DLL有没有加载失败的。很多崩溃是因为某个 Windows 系统 DLL 在 Wine 里没有实现或者实现不完整程序调用到那个 DLL 的某个函数时就挂了。5.2 画面渲染异常黑屏、花屏、纹理错乱图形问题通常跟 DXMT 和 Metal 的对接有关。排查时先确认 DXMT 是否真的被加载了在终端里跑程序看有没有 DXMT 的初始化日志。如果没有说明 DLL 重定向没生效回去检查注册表。如果 DXMT 加载了但画面还是不对开启 Metal 验证层看有没有 API 错误。常见的错误包括纹理格式不支持Metal 对某些 D3D 的纹理格式没有直接对应DXMT 需要做转换、渲染目标尺寸不匹配D3D 允许渲染目标比窗口大Metal 的 drawable 尺寸是固定的、着色器编译失败HLSL 到 Metal 的翻译有 bug。纹理格式的问题比较隐蔽因为程序不会崩溃只是画面颜色不对或者纹理显示为纯色。这时候要对比 D3D 的纹理格式和 Metal 的纹理格式看 DXMT 的转换逻辑是否正确。如果某个格式转换有问题可以在 DXMT 的源码里找到对应的转换函数手动修正映射关系。5.3 音频断续或延迟音频问题往往跟线程调度有关。Wine 的音频实现通常是 PulseAudio 或者 CoreAudio 的后端在 ARM 上可能因为线程优先级设置不当而出现断续。FEX-Emu 翻译后的代码执行速度比原生慢如果音频线程的优先级不够高就会被其他线程抢占导致缓冲区欠载。解决办法是调整 Wine 的音频缓冲区大小。在winecfg的音频选项卡里把缓冲区调大一些比如从默认的 50ms 调到 100ms给音频线程更多的容错空间。代价是音频延迟增加但对于大部分游戏来说100ms 的延迟是可以接受的。如果游戏对音频延迟敏感比如音游那就需要在性能和延迟之间做取舍了。另一个可能的原因是采样率不匹配。Windows 程序可能请求 44.1kHz 的采样率而系统音频设备工作在 48kHzWine 需要做重采样。重采样算法如果质量不高会有杂音。可以在winecfg里强制指定采样率跟系统一致避免重采样。5.4 输入设备不响应或映射错误手柄和键盘的输入问题通常出在 Wine 的输入子系统上。Wine 在 Linux 上通过 evdev 或者 SDL 读取输入设备在 macOS 上通过 IOKit。如果设备被其他程序独占Wine 就读不到。排查时先用evtestLinux或者系统的输入设备查看工具确认设备是否正常工作。然后在 Wine 的注册表里检查输入设备的映射HKEY_CURRENT_USER\Software\Wine\DirectInput下面有相关配置。有些手柄需要手动指定为native模式才能被游戏识别。键盘映射错误比较少见但如果遇到通常是键盘布局的问题。Wine 默认使用系统的键盘布局如果系统布局跟游戏期望的不一致按键就会错位。可以在winecfg的驱动选项卡里手动指定键盘布局。6. 性能调优让翻译层跑得更快6.1 FEX-Emu 的翻译缓存策略FEX-Emu 的性能很大程度上取决于翻译缓存的命中率。翻译缓存分两级一级是内存中的缓存二级是磁盘上的缓存。内存缓存命中时指令直接执行没有翻译开销磁盘缓存命中时需要从磁盘加载翻译结果比重新翻译快但比内存缓存慢。增大内存缓存的大小能提升命中率但会占用更多内存。FEX-Emu 的配置里有MaxCacheSize之类的参数默认值通常比较保守。在内存充足的设备上8GB 以上可以适当调大。我一般设成 256MB 到 512MB再大收益就不明显了。磁盘缓存的位置建议放在 SSD 上机械硬盘的随机读取速度会成为瓶颈。如果设备支持 NVMe把缓存放在 NVMe 盘上能明显缩短加载时间。缓存文件会随着使用不断增大要定期清理旧的缓存否则磁盘空间会被占满。6.2 多线程程序的调度优化Wine 和 FEX-Emu 都对多线程程序有额外的开销。Wine 需要模拟 Windows 的线程模型FEX-Emu 需要为每个线程维护独立的翻译状态。线程数越多开销越大。对于多线程游戏可以尝试限制线程数。有些游戏会根据 CPU 核心数自动设置线程数在 ARM 设备上核心数可能很多比如 8 核或 10 核但翻译层的开销使得实际有效的并行度没那么高。手动把游戏的线程数限制在 4 到 6 个往往能减少线程切换的开销提升整体帧率。CPU 亲和性设置也有帮助。把 Wine 的进程绑定到特定的核心上减少跨核心的缓存失效。在 Linux 上用taskset在 macOS 上用taskpolicy。具体绑到哪些核心要看设备的拓扑结构一般建议绑到大核上小核留给系统后台任务。6.3 图形设置的取舍在 ARM 设备上跑 Windows 游戏图形设置要务实。分辨率不要追求原生适当降低能大幅提升帧率。抗锯齿关掉或者用最低档MSAA 在翻译层上的开销比原生大得多。阴影质量、后处理效果这些也建议调低。DXMT 有一些自己的性能选项比如是否启用异步着色器编译、是否启用管线缓存。异步编译能减少卡顿但可能导致画面短暂异常着色器还没编译完就渲染了。管线缓存能加速着色器的加载但会占用磁盘空间。这些选项的取舍要看具体游戏没有一刀切的最优解。垂直同步建议关掉。翻译层的帧率本来就不稳定开垂直同步会让帧率被锁在 30 或 60而且输入延迟增加。关掉垂直同步后虽然可能有画面撕裂但操作响应更快整体体验反而更好。如果撕裂严重可以在 Metal 层面开自适应同步如果设备支持。7. 这套方案适合谁不适合谁7.1 适合的场景Madeira 这套组合最适合的场景是在 ARM Linux 设备比如树莓派 5、各种 ARM 开发板、ARM 笔记本上运行轻量级的 Windows 程序和老游戏。这些程序对性能要求不高D3D 特性用得少Wine 和 DXMT 的兼容性足够覆盖。另一个适合的场景是技术研究和学习。如果你想理解二进制翻译、API 翻译、图形 API 转换这些底层机制自己搭一套 Madeira 环境从源码编译到调试运行整个过程能学到很多东西。这比看文档和论文直观得多因为你能亲眼看到每层翻译的实际效果和性能开销。对于 Apple Silicon Mac 用户如果你不想用 CrossOver 这类商业方案Madeira 也是一个选择。但要注意macOS 上的系统调用限制比 Linux 多Wine 的某些功能可能受限。而且 macOS 的 Metal 驱动跟 DXMT 的兼容性需要额外测试不是所有游戏都能跑。7.2 不适合的场景如果你追求开箱即用、稳定运行最新的 3A 游戏Madeira 不适合你。翻译层的性能损失是客观存在的x86-64 到 ARM64 的翻译开销通常在 20% 到 50% 之间具体取决于程序的指令特征。图形 API 的翻译也有开销DXMT 的效率目前还比不上原生的 D3D 驱动。如果你需要运行依赖内核态驱动的程序比如某些反作弊系统、虚拟机软件Wine 本身就跑不了加上 FEX-Emu 也没用。这类程序需要真正的 Windows 内核Wine 的用户态实现无法满足。如果你对稳定性要求极高不能接受偶发的崩溃和兼容性问题那还是用原生的 Windows 环境或者成熟的商业兼容方案。Madeira 这类开源组合的测试覆盖度有限遇到问题的概率比商业方案高。7.3 一些实际的预期管理我在实际使用中最大的体会是不要期待完美。翻译层能做到能跑但很难做到跑得好。帧率波动、偶发崩溃、某些功能不可用这些都是常态。你要有一定的调试能力和耐心遇到问题能自己查日志、看源码、试配置。另外社区的支持很重要。Wine、FEX-Emu、DXMT 都有自己的社区论坛和聊天群遇到问题先搜一下有没有人遇到过。很多坑别人已经踩过了解决方案可能就在某个 issue 或者讨论帖里。自己闷头调可能花好几天问一下可能几分钟就解决了。最后记录你的配置。每次调通一个游戏把 Wine 版本、FEX-Emu 版本、DXMT 版本、注册表修改、环境变量、游戏设置都记下来。下次遇到类似问题这些记录能帮你快速定位。我自己的记录已经攒了几十个游戏的配置新游戏上手时先翻记录能省很多时间。