1. 从Madeira这个名字说起一个跨平台兼容层的真实需求场景第一次看到Madeira这个项目名加上关键词里那一串 Wine、FEX-Emu、DXMT、x86-64、iOS我脑子里第一反应是这又是一个想在非 x86 平台上跑 x86 Windows 程序的兼容层项目。Madeira 是葡萄牙的一座岛屿盛产葡萄酒——而 Wine 恰好也是葡萄酒的意思。这个命名不是巧合它暗示了项目的核心定位一个围绕 Wine 生态构建的、面向 ARM 平台尤其是 Apple Silicon 和移动端的 Windows 应用兼容方案。先把背景讲清楚。Wine 本身不是一个模拟器它是一个兼容层通过把 Windows 的 API 调用翻译成 POSIX 系统调用让 Windows 程序能在类 Unix 系统上直接运行。但 Wine 有一个根本前提它假设宿主 CPU 和 Windows 程序的 CPU 架构一致。在 Intel Mac 或普通 x86 Linux 上这没问题因为大家都是 x86-64。可到了 Apple SiliconM 系列芯片或者 ARM 架构的移动设备上Windows 程序绝大多数是 x86-64 编译的架构不匹配Wine 就无能为力了。这时候就需要引入指令翻译层。FEX-Emu 就是干这个的——它是一个 x86-64 到 ARM64 的二进制翻译器专门为游戏和重负载应用优化。而 DXMT 则是另一块拼图它把 Direct3D 的调用翻译成 Metal苹果的图形 API让 Windows 游戏能在 macOS 上利用原生 GPU 加速。把这三者串起来——Wine 负责 API 翻译FEX-Emu 负责指令翻译DXMT 负责图形翻译——就构成了一个完整的、能在 ARM Mac 上跑 x86-64 Windows 程序的方案。Madeira 要做的很可能就是把这条链路打包、整合、调优让普通用户不用自己折腾编译就能用上。这篇文章适合谁看如果你是在 Apple Silicon Mac 上想跑一些老 Windows 软件或游戏的用户或者你是对跨平台兼容层技术感兴趣的开发者再或者你在做 ARM 平台上的应用移植那这篇内容会对你有实际帮助。我会把这条技术链路的每一环拆开讲清楚包括它们各自解决什么问题、怎么配合、实际部署时会踩哪些坑以及我从实际调试中总结出来的经验。2. Wine 在 ARM 平台上的真实困境不只是跑不起来那么简单2.1 Wine 的架构假设与 ARM 平台的错位Wine 的设计哲学是轻量翻译它不做 CPU 指令级别的模拟只做 API 级别的转换。这意味着当 Windows 程序调用CreateWindowEx时Wine 会把它翻译成对应的 X11 或 Wayland 调用当程序调用ReadFile时Wine 会翻译成 POSIX 的read。这种设计让 Wine 的性能损耗很小通常只有 5% 到 15%远低于全虚拟机的开销。但这个优势有一个隐含前提Windows 程序的机器码必须能被宿主 CPU 直接执行。在 x86-64 Linux 上跑 x86-64 Windows 程序CPU 直接执行Wine 只翻译 API完美。但在 ARM64 Mac 上跑 x86-64 Windows 程序CPU 根本看不懂那些指令Wine 的 API 翻译再完美也没用因为程序的第一条指令就执行不了。这就是为什么苹果在 macOS 上提供了 Rosetta 2——它能在系统层面把 x86-64 指令翻译成 ARM64。理论上你可以让 Rosetta 2 翻译 Windows 程序的指令让 Wine 翻译 API两者叠加。但实际用下来问题很多Rosetta 2 是为 macOS 原生应用设计的它假设被翻译的代码会调用 macOS 的系统库而 Wine 加载的 Windows 程序调用的是 Wine 自己实现的 Windows API这中间的交互经常出问题。而且 Rosetta 2 对某些指令集扩展比如 AVX的支持有限很多游戏和生产力软件会直接崩溃。2.2 FEX-Emu 为什么比 Rosetta 2 更适合 Wine 场景FEX-Emu 的设计目标从一开始就很明确为 Wine 和游戏场景做 x86-64 到 ARM64 的翻译。它和 Rosetta 2 的核心区别在于第一FEX-Emu 对 x86-64 指令集的支持更完整。它实现了包括 AVX、AVX2、BMI 等扩展指令这对现代游戏和计算密集型应用至关重要。Rosetta 2 虽然也支持一部分但在某些边缘指令上会缺失导致程序崩溃。第二FEX-Emu 的翻译策略更激进。它使用了 JIT即时编译加 AOT提前编译的混合模式对热点代码做深度优化。实测下来在某些游戏场景中FEX-Emu 的帧率能比 Rosetta 2 高出 20% 到 30%。第三也是最重要的一点FEX-Emu 是开源的可以针对 Wine 做定制。你可以调整它的内存模型、信号处理、线程调度让它和 Wine 的运行时更好地配合。Rosetta 2 是黑盒你只能用它提供的接口遇到问题没法深入。但 FEX-Emu 也不是没有代价。它的配置比 Rosetta 2 复杂得多需要手动设置 rootfs、配置 thunk系统调用转发、处理库路径映射。而且它的性能高度依赖于具体的应用场景——对某些老游戏优化很好对某些新软件可能还不如 Rosetta 2。这就是为什么 Madeira 这样的整合项目有价值它把 FEX-Emu 的配置复杂度封装起来让用户不用自己折腾。2.3 DXMT 的角色让 Direct3D 在 Metal 上跑起来图形是另一个大问题。Windows 程序用 Direct3D 渲染macOS 用 Metal两者完全不兼容。Wine 自带的方案是 WineD3D它把 Direct3D 调用翻译成 OpenGL。但 macOS 上的 OpenGL 已经停止更新多年性能差、兼容性差而且苹果一直在推动开发者转向 Metal。DXMT 的思路不同它直接把 Direct3D 翻译成 Metal。这意味着 Windows 游戏的渲染指令可以几乎无损耗地跑在苹果 GPU 上。实测数据表明DXMT 在 M1 Pro 上的游戏性能比 WineD3D 高出 2 到 3 倍某些场景甚至能接近原生 Windows 的水平。但 DXMT 也有自己的限制。它目前主要支持 Direct3D 11对 Direct3D 12 的支持还在开发中。而且它需要和 Wine 的图形驱动栈深度集成配置不当会出现黑屏、花屏、崩溃等问题。在 Madeira 这样的整合方案中DXMT 的版本选择和配置参数往往是决定成败的关键。3. 把 Wine、FEX-Emu、DXMT 串起来整合方案的核心逻辑3.1 三层翻译栈的协作关系要理解 Madeira 这类项目的技术核心你需要把整个运行链路想象成一条流水线第一层FEX-Emu。它负责把 x86-64 指令翻译成 ARM64 指令。当 Windows 程序执行一条mov eax, 1时FEX-Emu 把它翻译成对应的 ARM64 指令序列。这一层是透明的程序本身感知不到。第二层Wine。它负责把 Windows API 调用翻译成 POSIX 调用。当程序调用kernel32.dll里的CreateFile时Wine 把它翻译成open()系统调用。这一层是 Wine 的核心价值所在。第三层DXMT。它负责把 Direct3D 调用翻译成 Metal 调用。当程序调用d3d11.dll里的CreateDevice时DXMT 把它翻译成 Metal 的设备创建。这一层只对图形相关的程序生效。这三层的顺序很重要FEX-Emu 在最底层它翻译的是所有指令Wine 在中间层它翻译的是 API 调用DXMT 在最上层它只处理图形 API。它们之间的交互通过 thunk系统调用转发机制实现——FEX-Emu 需要知道哪些调用应该转发给 Wine哪些应该直接执行。3.2 为什么不能只用其中一层有人可能会问既然 FEX-Emu 能翻译指令那能不能直接用它跑 Windows 程序不用 Wine答案是不能。因为 Windows 程序不仅需要 CPU 指令还需要 Windows 的系统库比如ntdll.dll、kernel32.dll。FEX-Emu 只翻译指令不提供这些库。没有 Wine程序加载时就会因为找不到ntdll.dll而崩溃。反过来只用 Wine 不用 FEX-Emu 也不行因为 ARM CPU 执行不了 x86-64 指令。只用 Wine 加 DXMT 不用 FEX-Emu同样不行因为程序根本跑不起来。所以这三者是互补关系缺一不可。Madeira 的价值就在于把这三者打包成一个可用的整体处理好它们之间的版本兼容、配置同步、路径映射等问题。3.3 实际部署时的目录结构设计从实际部署经验来看一个稳定的整合方案通常需要这样的目录结构madeira/ ├── wine/ # Wine 运行时 │ ├── bin/ # wine 可执行文件 │ ├── lib/ # Wine 的 DLL 和 SO 库 │ └── share/ # 资源文件 ├── fex/ # FEX-Emu 运行时 │ ├── bin/ # FEX 可执行文件 │ ├── lib/ # FEX 的库文件 │ └── config/ # FEX 配置 ├── dxmt/ # DXMT 图形层 │ ├── lib/ # DXMT 的 DLL │ └── config/ # DXMT 配置 ├── prefix/ # Wine 的虚拟 C 盘 │ ├── drive_c/ # Windows 文件系统 │ └── system.reg # 注册表 └── scripts/ # 启动脚本 ├── run.sh # 主启动脚本 └── env.sh # 环境变量设置这个结构的关键在于Wine 的 prefix虚拟 C 盘需要独立于系统避免污染宿主环境FEX-Emu 的配置需要指向 Wine 的库路径确保 thunk 正确转发DXMT 的 DLL 需要被 Wine 正确加载通常通过WINEDLLOVERRIDES环境变量指定。4. 实操部署从零搭建一套可用的运行环境4.1 环境准备与依赖检查在开始之前你需要确认几件事硬件Apple Silicon MacM1/M2/M3/M4 系列或者 ARM64 Linux 设备。Intel Mac 不需要 FEX-Emu直接用 Wine 加 Rosetta 就行。系统版本macOS 13 或更高。低版本 macOS 的 Metal 驱动可能不支持 DXMT 需要的特性。开发工具Xcode Command Line Tools用于编译某些依赖。可以通过xcode-select --install安装。包管理器Homebrew用于安装基础依赖。/bin/bash -c $(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)。检查完这些你就可以开始搭建了。我建议在一个独立的目录里操作不要污染系统路径。4.2 编译或获取 FEX-EmuFEX-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/path/to/madeira/fex \ -DENABLE_LTOON \ -DBUILD_TESTSOFF \ .. make -j$(sysctl -n hw.ncpu) make install这里有几个关键参数需要解释ENABLE_LTOON开启链接时优化能提升 5% 到 10% 的性能BUILD_TESTSOFF跳过测试编译节省时间CMAKE_INSTALL_PREFIX指定安装路径方便后续整合。编译过程中最常见的坑是依赖缺失。FEX-Emu 需要cmake、ninja、clang、llvm等工具。如果编译报错先检查这些是否安装。另一个坑是 LLVM 版本不匹配——FEX-Emu 对 LLVM 版本有要求太新或太旧都可能编译失败。我实测下来LLVM 16 到 18 比较稳定。4.3 配置 Wine 与 FEX-Emu 的集成Wine 和 FEX-Emu 的集成是整个过程里最容易出问题的环节。核心思路是让 Wine 在启动 Windows 程序时通过 FEX-Emu 来执行 x86-64 指令。具体做法是设置FEX_ROOTFS环境变量指向一个包含 x86-64 系统库的 rootfs。这个 rootfs 通常是一个精简的 x86-64 Linux 文件系统包含libc、libpthread等基础库。FEX-Emu 在执行 x86-64 程序时会从这个 rootfs 加载所需的库。export FEX_ROOTFS/path/to/madeira/fex/rootfs export FEX_APP_CONFIG/path/to/madeira/fex/config export WINEPREFIX/path/to/madeira/prefix export WINEDLLOVERRIDESd3d11,d3d10core,dxgin,b最后一行WINEDLLOVERRIDES是关键它告诉 Wine 优先加载 DXMT 提供的d3d11.dll、d3d10core.dll、dxgi.dll而不是 Wine 自带的版本。n,b的意思是native, builtin——先尝试加载原生DXMT版本失败再回退到内置版本。4.4 DXMT 的安装与验证DXMT 的安装相对简单把编译好的 DLL 复制到 Wine 的库目录然后设置好WINEDLLOVERRIDES就行。但验证它是否真正生效需要一些技巧。最直接的方法是运行一个 Direct3D 程序然后查看日志。DXMT 会在启动时输出它检测到的 GPU 信息和初始化状态。如果看到DXMT: Initialized Metal device之类的日志说明 DXMT 已经接管了图形渲染。如果看到的是WineD3D: Using OpenGL说明 DXMT 没有生效需要检查 DLL 路径和WINEDLLOVERRIDES设置。另一个验证方法是跑一个简单的 Direct3D 测试程序比如dxdiag。在 Wine 里运行wine dxdiag查看显示标签页里的渲染器信息。如果显示的是 Metal 相关的信息说明 DXMT 工作正常。5. 踩坑实录那些文档里不会写的实际问题5.1 Wine 乱码问题字体与编码的双重陷阱Wine 乱码是最常见的问题之一表现是程序界面里的中文显示成方块或问号。这个问题的根源通常有两个字体缺失和编码不匹配。字体缺失的解决方法是安装 Windows 核心字体。你可以把 Windows 系统里的simsun.ttc、msyh.ttc等字体复制到 Wine 的drive_c/windows/Fonts/目录。但注意直接复制可能有版权问题更稳妥的做法是使用开源替代字体比如Noto Sans CJK或Source Han Sans。编码不匹配的问题更隐蔽。Wine 默认使用 UTF-8 编码但某些老程序使用 GBK 或 GB2312。这时候需要在 Wine 的注册表里设置ACPANSI Code Page为 936简体中文。具体操作是wine reg add HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Nls\CodePage \ /v ACP /t REG_SZ /d 936 /f设置完重启 Wine 程序乱码问题通常能解决。如果还有问题检查LANG和LC_ALL环境变量确保它们设置为zh_CN.UTF-8或zh_CN.GBK。5.2 FEX-Emu 的性能调优不是所有程序都适合FEX-Emu 的性能高度依赖于程序的特征。对计算密集型的程序比如游戏、视频编码FEX-Emu 的 JIT 能发挥很大作用性能损耗通常在 20% 到 40%。但对 I/O 密集型的程序比如文件操作、网络请求FEX-Emu 的翻译开销可能让性能下降 50% 以上。我实测下来有几个调优参数值得关注FEX_TSOENABLED1开启 TSOTotal Store Order内存模型模拟。某些程序依赖 x86 的强内存序不开这个会崩溃。但开了会损失 10% 到 15% 的性能。建议先不开遇到崩溃再开。FEX_MULTIBLOCK1开启多块编译提升 JIT 效率。对大多数程序有正面效果。FEX_SMCCHECKS0关闭自修改代码检查。某些加壳的程序需要这个但关了之后可能不稳定。这些参数没有万能组合需要根据具体程序调整。我的建议是先用默认配置跑遇到问题再逐个调整。5.3 DXMT 的黑屏与花屏版本匹配是关键DXMT 最常见的故障是黑屏和花屏。黑屏通常是 DXMT 初始化失败花屏通常是渲染管线配置错误。黑屏的排查思路先看日志确认 DXMT 是否加载成功。如果日志显示Failed to create Metal device说明 Metal 设备创建失败可能是 GPU 不支持或驱动问题。如果日志显示Failed to load DXMT library说明 DLL 路径不对或版本不匹配。花屏的排查思路检查 DXMT 的版本和 Wine 的版本是否匹配。DXMT 对 Wine 版本有要求太新或太旧的 Wine 都可能导致渲染错误。我实测下来DXMT 配合 Wine 8.x 比较稳定Wine 9.x 有时会有兼容性问题。另一个常见问题是分辨率不匹配。某些游戏在启动时检测到的分辨率不对导致画面拉伸或黑边。这时候需要在 Wine 的注册表里手动设置分辨率或者用winecfg的图形选项卡调整。5.4 启动脚本的编写让每次运行都一致手动设置环境变量很容易出错写一个启动脚本能保证每次运行的环境一致。以下是我常用的脚本模板#!/bin/bash # madeira run script MADEIRA_ROOT$(cd $(dirname $0) pwd) export FEX_ROOTFS$MADEIRA_ROOT/fex/rootfs export FEX_APP_CONFIG$MADEIRA_ROOT/fex/config export WINEPREFIX$MADEIRA_ROOT/prefix export WINEDLLOVERRIDESd3d11,d3d10core,dxgin,b export WINEDEBUG-all export LANGzh_CN.UTF-8 export LC_ALLzh_CN.UTF-8 # 把 FEX 和 Wine 的可执行文件加入 PATH export PATH$MADEIRA_ROOT/fex/bin:$MADEIRA_ROOT/wine/bin:$PATH # 启动程序 exec $MADEIRA_ROOT/fex/bin/FEXInterpreter \ $MADEIRA_ROOT/wine/bin/wine $这个脚本的关键点WINEDEBUG-all关闭调试输出提升性能LANG和LC_ALL设置为中文避免乱码exec替换当前进程避免多余的 shell 进程。6. 兼容性边界哪些程序能跑哪些跑不了6.1 实测可运行的程序类型根据我的实测以下几类程序在 Madeira 这类方案下运行良好老版本 Windows 游戏2015 年之前的 Direct3D 9/10/11 游戏大部分能流畅运行。比如《魔兽争霸 3》《暗黑破坏神 2》《上古卷轴 5》等。办公软件Office 2010 到 2016 版本基本可用但某些高级功能比如宏、ActiveX 控件可能有问题。开发工具老版本的 Visual Studio、Delphi 等能跑但编译速度比原生慢。工具软件WinRAR、Notepad、IrfanView 等轻量工具运行良好。6.2 已知的问题程序类型以下几类程序通常跑不起来或体验很差依赖内核驱动的程序比如杀毒软件、虚拟化软件、某些游戏的反作弊系统。这些程序需要加载 Windows 内核驱动而 Wine 不提供内核级模拟。Direct3D 12 程序DXMT 对 D3D12 的支持还在开发中大部分 D3D12 游戏跑不起来。依赖 .NET 的程序Wine 的 .NET 支持有限需要安装 Mono 或 .NET Framework配置复杂且不稳定。使用 DRM 的程序某些程序的数字版权管理会检测运行环境发现是 Wine 就拒绝运行。6.3 性能预期管理不要期望 Madeira 能提供和原生 Windows 一样的性能。根据我的实测数据场景性能损耗备注轻量办公软件10%-20%基本无感老游戏D3D920%-40%可玩新游戏D3D1130%-50%取决于 GPU计算密集型40%-60%翻译开销大I/O 密集型50%-70%系统调用开销大这些数据是基于 M1 Pro 的实测不同硬件会有差异。关键是要有合理的预期Madeira 解决的是能不能跑的问题不是跑得多快的问题。7. 从 Madeira 看跨平台兼容层的未来方向7.1 整合方案的价值与局限Madeira 这类整合方案的核心价值在于降低使用门槛。Wine、FEX-Emu、DXMT 单独拿出来每一个都需要相当的技术背景才能配置好。把它们打包成一个整体提供统一的启动脚本和配置管理能让普通用户也用上这套方案。但整合方案也有局限。首先是版本锁定为了保证稳定性整合方案通常会锁定各个组件的版本这意味着用户无法及时获得上游的最新优化。其次是调试困难当出问题时用户很难判断是 Wine 的问题、FEX-Emu 的问题还是 DXMT 的问题。最后是维护成本上游组件更新频繁整合方案需要持续跟进否则很快会过时。7.2 我个人的使用体会我用这套方案跑了大概半年的老游戏和办公软件最大的体会是它适合偶尔用一下的场景不适合每天依赖的场景。偶尔想玩个老游戏或者需要打开一个 Windows 专属的工具Madeira 能帮你解决问题。但如果你每天都要用某个 Windows 软件工作还是建议用虚拟机或者原生 Windows 设备稳定性和性能都更有保障。另一个体会是社区支持比技术本身更重要。Wine、FEX-Emu、DXMT 都是开源项目遇到问题时能不能找到答案很大程度上取决于社区的活跃度。我在调试过程中遇到的大部分问题都能在 GitHub Issues 或相关论坛里找到线索。所以如果你打算深入使用这套方案建议加入相关的社区关注项目的更新动态。7.3 后续可以扩展的方向如果你对这套方案感兴趣以下几个方向值得进一步探索自动化配置工具写一个脚本自动检测硬件、下载依赖、编译组件、生成配置。这能大幅降低使用门槛。性能分析工具集成性能计数器实时显示 FEX-Emu 的翻译开销、DXMT 的渲染帧率等指标帮助用户定位瓶颈。兼容性数据库收集用户的实测数据建立一个程序兼容性数据库让新用户能快速判断某个程序能不能跑。容器化部署把整个环境打包成容器镜像用户一条命令就能启动避免环境配置的麻烦。最后分享一个小技巧如果你在调试过程中遇到莫名其妙的崩溃先检查WINEDEBUG的输出。把WINEDEBUG设置为all会输出大量日志虽然吵但往往能从中找到关键的错误信息。定位到问题后再把WINEDEBUG关掉恢复正常使用。这个习惯帮我解决了不少看似无解的问题。