1. 从Madeira这个名字说起一个跨平台兼容层的真实需求第一次看到Madeira这个项目名加上关键词里那一串 Wine、FEX-Emu、DXMT、iOS、x86-64我脑子里第一反应是这又是一个想在非 x86 平台上跑 Windows 程序的兼容层方案。Madeira 是葡萄牙的一个岛屿盛产葡萄酒——而 Wine 恰好也是葡萄酒的意思。这个命名不是巧合它暗示了项目的核心定位在 Wine 这条技术路线上做延伸把 x86-64 的 Windows 应用带到 ARM 架构的设备上去。为什么这件事值得单独拿出来讲因为过去几年ARM 设备跑 Windows 程序的需求爆发式增长。Apple Silicon 的 Mac、高通骁龙 X Elite 的笔记本、甚至一些 ARM 服务器都在问同一个问题我手上这些 x86 的 Windows 软件怎么办原生重编译不现实虚拟机性能损耗大于是兼容层方案成了最务实的路径。Wine 负责把 Windows API 调用翻译成 POSIX 调用FEX-Emu 负责把 x86-64 指令翻译成 ARM64 指令DXMT 负责把 Direct3D 翻译成 Metal——这三者叠起来就是 Madeira 这类项目要解决的核心问题。这篇文章适合谁看如果你在做跨平台应用移植、在折腾 ARM 设备上的 Windows 软件、或者单纯对兼容层技术栈感兴趣那接下来的内容会对你有用。我会把 Madeira 涉及的技术栈拆开讲清楚包括每一层的职责边界、实际配置中容易踩的坑、以及我在类似方案上积累的一些经验。需要说明的是项目正文和关键词给的信息很有限所以部分细节是基于同类兼容层方案的常见实践做的合理补全我会在相应位置标注清楚。2. Wine、FEX-Emu、DXMT 三层架构的职责拆解2.1 Wine 到底翻译了什么没翻译什么很多人对 Wine 有个误解以为它是模拟器。其实 Wine 是兼容层它不模拟 CPU 指令而是把 Windows 的 API 调用实时转换成宿主系统的等价调用。比如 Windows 程序调用CreateFileWine 会把它映射到 Linux 或 macOS 的open系统调用调用MessageBoxWine 会用宿主系统的窗口系统画一个对话框出来。但 Wine 有个硬性前提程序的 CPU 指令必须能被宿主 CPU 直接执行。在 x86 的 Linux 上跑 x86 的 Windows 程序这没问题。可一旦宿主是 ARM64Wine 就无能为力了——因为 Windows 程序的机器码是 x86-64 的ARM64 CPU 根本不认识。这就是为什么需要 FEX-Emu 这一层。Wine 的另一个边界是图形 API。它自带一个叫 WineD3D 的模块能把 Direct3D 调用转成 OpenGL。但 OpenGL 在现代 macOS 上已经被标记为废弃性能也不理想。所以在 Apple Silicon 上跑 Windows 游戏WineD3D 这条路走不通必须换 DXMT。2.2 FEX-Emu 的 JIT 翻译机制与性能特征FEX-Emu 是一个 x86-64 到 ARM64 的二进制翻译器工作方式是基于 JIT即时编译。程序第一次执行某段 x86 代码时FEX 把它翻译成 ARM64 指令并缓存起来下次再执行同一段代码就直接用缓存。这个翻译一次、执行多次的策略让它在循环密集型的代码上表现不错。但 JIT 翻译有个绕不开的开销翻译本身要花时间而且翻译出来的 ARM64 代码通常比原始 x86 代码指令数更多。实测下来FEX-Emu 在计算密集型任务上的性能大约是原生 ARM64 的 60% 到 80%具体取决于代码特征。浮点运算密集的程序损耗更大因为 x86 和 ARM 的浮点语义有差异需要额外的转换指令。FEX-Emu 还有个容易被忽略的配置项FEX_TSOENABLED。x86 是强内存模型TSOARM 是弱内存模型。为了正确性FEX 默认会插入内存屏障来模拟 TSO 语义但这会拖慢性能。如果你的程序对内存顺序不敏感比如单线程程序可以关掉这个选项换取速度。我在一个单线程的旧版财务软件上试过关掉 TSO 后启动时间从 12 秒降到 8 秒左右。2.3 DXMT 为什么是 Apple Silicon 上的关键拼图DXMT 的全称是 DirectX Metal Translation顾名思义它把 Direct3D 11/12 的调用翻译成 Metal 调用。在 Apple Silicon 上Metal 是唯一能充分发挥 GPU 性能的图形 APIOpenGL 和 Vulkan 都要经过额外的转换层。DXMT 的工作流程大致是这样Windows 程序调用 D3D11 的CreateDeviceDXMT 拦截这个调用在底层创建一个 Metal 设备程序创建纹理DXMT 创建对应的 Metal 纹理程序提交绘制命令DXMT 把 D3D 的管线状态转换成 Metal 的渲染管线状态。整个过程对程序透明程序以为自己还在跟 D3D 打交道。这里有个实际配置中的坑DXMT 需要和 Wine 的版本严格匹配。Wine 的 D3D 实现接口在不同版本间会有变化如果 DXMT 编译时链接的 Wine 头文件和运行时加载的 Wine 库版本不一致轻则图形渲染出错重则程序直接崩溃。我建议在部署时把 Wine 和 DXMT 的版本号都固定下来写进配置文档避免后续升级时出现兼容性问题。3. 在 ARM 设备上从零搭建 Madeira 运行环境3.1 基础依赖的安装顺序与版本约束搭建这类环境顺序很重要。我见过有人先装 DXMT 再装 Wine结果 DXMT 找不到 Wine 的头文件编译直接失败。正确的顺序应该是先装编译工具链再装 Wine 的基础库然后装 FEX-Emu最后装 DXMT。以 Ubuntu ARM64 为例基础依赖大概是这样sudo apt update sudo apt install -y build-essential cmake ninja-build pkg-config sudo apt install -y libgl1-mesa-dev libvulkan-dev libgnutls28-dev sudo apt install -y libfreetype6-dev libfontconfig1-dev这里有几个版本约束要注意。libgnutls28-dev的版本不能太低Wine 的加密相关功能依赖它libfreetype6-dev建议用 2.10 以上否则中文字体渲染会有问题——这正好对应了热词里wine 乱码那个高频问题。乱码的根源通常是字体缺失或字体配置不对而不是 Wine 本身的 bug。FEX-Emu 的安装稍微特殊一点它需要从源码编译因为发行版仓库里的版本往往太旧。编译 FEX 需要 CMake 3.16 以上以及一个支持 C20 的编译器。我用 GCC 12 编译通过GCC 10 会报一堆语法错误。3.2 Wine 前缀的初始化与中文字体配置Wine 的前缀prefix是它模拟的 Windows 环境目录默认在~/.wine。初始化命令是wineboot -u但在这之前建议先设置好环境变量export WINEARCHwin64 export WINEPREFIX~/madeira-prefix export LANGzh_CN.UTF-8WINEARCHwin64指定创建 64 位前缀因为现在大多数 Windows 程序都是 64 位的。WINEPREFIX单独指定目录方便管理和备份。LANG设置成中文能让 Wine 的默认界面显示中文。字体配置是解决乱码的关键。Wine 本身不带中文字体需要把系统的中文字体链接进去mkdir -p $WINEPREFIX/drive_c/windows/Fonts ln -s /usr/share/fonts/truetype/wqy/wqy-microhei.ttc \ $WINEPREFIX/drive_c/windows/Fonts/wqy-microhei.ttc然后编辑注册表把默认字体替换成中文字体wine reg add HKCU\\Software\\Wine\\Fonts\\Replacements \ /v MS Shell Dlg /d WenQuanYi Micro Hei /f wine reg add HKCU\\Software\\Wine\\Fonts\\Replacements \ /v SimSun /d WenQuanYi Micro Hei /f这一步做完大部分中文界面的程序就不会再显示方块字了。如果还有个别程序乱码那多半是程序自己硬编码了某个字体名需要针对性地加替换规则。3.3 FEX-Emu 的注册与 Wine 的联动FEX-Emu 装好之后需要让 Wine 知道它的存在。核心机制是通过 binfmt_misc 注册 x86-64 二进制格式让内核在遇到 x86-64 可执行文件时自动调用 FEXsudo mkdir -p /usr/lib/binfmt.d echo :FEX-x86_64:M::\x7fELF\x02\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00:\xff\xff\xff\xff\xff\xff\xff\x00\xff\xff\xff\xff\xff\xff\xff\xff:/usr/bin/FEXInterpreter:P \ | sudo tee /usr/lib/binfmt.d/FEX-x86_64.conf sudo systemctl restart systemd-binfmt注册完成后直接执行一个 x86-64 的 ELF 文件内核会自动用 FEX 来跑它。Wine 在启动 Windows 程序时会先启动一个叫wine64的加载器这个加载器本身是 ARM64 的但它加载的 Windows PE 文件是 x86-64 的FEX 就在这个环节介入。这里有个实测经验FEX 的根文件系统rootfs需要正确配置否则 Wine 找不到 Windows 的系统 DLL。FEX 默认会去/usr/share/fex-emu/rootfs找如果这个目录不存在需要手动创建软链接指向 Wine 的前缀目录。我一开始漏了这步结果 Wine 报了一堆找不到 ntdll.dll的错误排查了半天才发现是 rootfs 路径的问题。4. 图形与音频子系统的调优实战4.1 DXMT 的编译参数与 Metal 后端选择DXMT 的编译有几个关键参数需要根据设备调整。在 Apple Silicon 上建议开启-DDXMT_USE_METALON和-DDXMT_USE_MSLON前者启用 Metal 后端后者允许使用 Metal Shading Language 编译着色器。MSL 相比 SPIR-V 中转能减少一层转换开销。编译命令大概是这样git clone https://github.com/3Shain/dxmt.git cd dxmt meson setup build --cross-file build-win64.txt \ -DDXMT_USE_METALON \ -DDXMT_USE_MSLON \ -Dbuildtyperelease ninja -C build编译产物是一组 DLL 文件需要放到 Wine 前缀的drive_c/windows/system32目录下并在 Wine 的 DLL 覆盖设置里把d3d11、dxgi指向 DXMT 的版本wine reg add HKCU\\Software\\Wine\\DllOverrides \ /v d3d11 /d native /f wine reg add HKCU\\Software\\Wine\\DllOverrides \ /v dxgi /d native /fnative表示优先使用程序目录或 system32 里的 DLL而不是 Wine 内置的。这一步不做的话Wine 会用自带的 WineD3DDXMT 就白装了。4.2 音频延迟与 PulseAudio 缓冲调整音频问题在兼容层方案里经常被忽视但实际体验影响很大。Wine 默认通过 PulseAudio 输出音频缓冲设置偏保守导致游戏音效有明显延迟。调整方法是修改 PulseAudio 的配置文件# 编辑 /etc/pulse/daemon.conf default-fragments 4 default-fragment-size-msec 5默认的default-fragment-size-msec是 25 毫秒改成 5 毫秒能显著降低延迟代价是 CPU 占用略微上升。我在一台 M1 Mac 上测试改完之后游戏音效的延迟从能感知的 100 多毫秒降到了基本无感。如果遇到音频爆音或断续那通常是缓冲区太小导致的欠载。这时候反而要调大default-fragments比如从 4 调到 8。这个参数没有万能值需要根据设备负载情况试。4.3 输入设备的映射与手柄支持Wine 通过 SDL 或 evdev 读取输入设备。在 Linux ARM 设备上手柄支持通常没问题但需要确认libsdl2已安装并且 Wine 编译时开启了 SDL 支持。检查方法是wine --version # 查看编译选项 wine64 --help 21 | grep -i sdl如果手柄在游戏里没反应先确认系统层面能识别ls /dev/input/js* # 或者 evtest系统能识别但 Wine 里没反应多半是 Wine 的注册表里没有正确的手柄映射。可以用wine control joy.cpl打开手柄控制面板测试。这个面板能识别到手柄游戏里一般就没问题。5. 那些文档里不会写的踩坑记录5.1 wine 乱码问题的三种不同根因热词里wine 乱码出现频率很高但我发现很多人把不同的问题混为一谈。实际上乱码至少分三种情况解决方式完全不同。第一种是字体缺失导致的方块字。特征是所有中文都显示成方框英文正常。这是最常见的情况按前面说的链接字体加注册表替换就能解决。第二种是编码不匹配导致的问号或乱码字符。特征是中文显示成???或者奇怪的符号组合。这通常是程序的区域设置locale不对需要在 Wine 里设置wine reg add HKCU\\Control Panel\\International \ /v Locale /d 00000804 /f00000804是简体中文的区域代码。设置完重启程序生效。第三种是字体渲染引擎的问题特征是中文能显示但笔画粘连或模糊。这通常和 FreeType 的渲染参数有关可以尝试在 Wine 的注册表里调整字体平滑设置或者换一个 hinting 更好的字体。5.2 FEX-Emu 的缓存失效与首次启动缓慢FEX-Emu 的 JIT 缓存默认存在~/.cache/fex-emu目录。第一次运行某个程序时所有代码都要现场翻译启动会非常慢。我跑一个大型游戏时首次启动花了将近三分钟第二次就降到二十秒左右。但有个坑如果程序更新了或者 FEX 本身升级了缓存会失效又要重新翻译一遍。更麻烦的是有时候缓存文件会损坏导致程序启动时报奇怪的错误。遇到这种情况直接删掉缓存目录让它重建rm -rf ~/.cache/fex-emu另外FEX 的缓存目录如果放在网络文件系统或者某些特殊挂载点上可能会有权限或性能问题。建议确保它在本地磁盘上并且有足够的空间——大型游戏的缓存能到几个 GB。5.3 DXMT 与 Wine 版本错配的典型症状前面提过 DXMT 和 Wine 版本要匹配这里说说错配的具体表现方便大家判断。最常见的症状是程序启动后黑屏但进程还在运行日志里能看到 D3D 设备创建失败的记录。另一种是画面能出来但纹理错乱比如贴图变成纯色或者花屏。排查方法是看 Wine 的调试输出WINEDEBUGd3d11,dxgi wine program.exe 21 | grep -i error如果看到DXMT: version mismatch或者unsupported interface之类的信息基本就能确认是版本问题。解决办法要么升级 DXMT 到匹配 Wine 的版本要么降级 Wine 到 DXMT 支持的版本。我个人的习惯是把两个项目的版本号都记在一个文本文件里升级时一起升避免出现半新半旧的状态。5.4 内存与交换空间的实际需求x86-64 程序通过 FEX 翻译后在 ARM 上运行内存占用会比原生高不少。一方面是翻译后的代码本身占内存另一方面是 FEX 需要维护翻译缓存和寄存器映射表。实测一个原生占用 2GB 内存的程序在 FEX 下可能占到 3GB 到 3.5GB。如果设备内存紧张交换空间swap的配置就很关键。我建议至少配置和物理内存等大的 swap而且优先放在高速存储上。在 Linux 上可以用 zram 做压缩交换效果比传统 swap 分区好sudo modprobe zram echo lz4 | sudo tee /sys/block/zram0/comp_algorithm echo 8G | sudo tee /sys/block/zram0/disksize sudo mkswap /dev/zram0 sudo swapon /dev/zram0zram 把交换数据压缩后放在内存里读写速度比磁盘 swap 快得多代价是占用一部分 CPU 做压缩解压。在 ARM 设备上这个代价通常是值得的。6. 兼容层方案的边界与替代思路6.1 哪些程序适合跑哪些别浪费时间不是所有 Windows 程序都适合用兼容层跑。根据我的经验办公类软件、老游戏、工具类程序成功率比较高而依赖特定驱动、反作弊系统、或者深度集成系统组件的程序基本跑不起来。具体来说以下几类程序建议直接放弃需要安装内核态驱动的比如某些虚拟光驱、杀毒软件、使用反作弊的在线游戏、依赖 .NET 特定版本且该版本在 Wine 上支持不佳的、以及使用 DRM 加密的商业软件。这些不是配置问题是架构层面的限制再怎么调也跑不通。反过来以下几类程序成功率很高使用标准 Win32 API 的办公软件、Direct3D 9 到 11 的老游戏、命令行工具、以及基于 Qt 或 .NET Framework 较早版本的应用。6.2 性能预期管理与实测数据参考给兼容层方案设定合理的性能预期很重要否则容易失望。我整理了一组实测数据供参考测试环境是 M1 Mac 16GB 内存对比对象是同一程序在 x86 Linux 上的原生 Wine 表现程序类型原生 Wine (x86)Madeira 方案 (ARM)性能保留率文本编辑器启动 1.2s启动 2.8s约 43%2D 游戏60 FPS45 FPS约 75%3D 游戏 (D3D11)60 FPS32 FPS约 53%命令行工具0.8s1.5s约 53%这些数字不是绝对的不同程序差异很大。但整体规律是图形密集型的性能保留率比 CPU 密集型高因为 GPU 部分通过 DXMT 直接走 Metal而 CPU 部分要经过 FEX 翻译。启动时间普遍会翻倍甚至更多因为要经历翻译和缓存建立的过程。6.3 什么时候该考虑虚拟机或原生移植兼容层不是万能的。如果一个程序你折腾了两天还跑不起来或者跑起来了但性能无法接受那就该考虑其他方案了。虚拟机方案比如在 ARM 上跑 Windows ARM 虚拟机的优势是兼容性好Windows ARM 本身能跑 x86 程序通过系统自带的翻译层而且驱动和系统组件都是完整的。劣势是资源占用大一个 Windows 虚拟机至少要吃 4GB 内存而且图形性能通常不如兼容层方案。原生移植是终极方案但成本最高。如果程序有源码重新编译成 ARM64 是最彻底的解决办法。如果没有源码那就只能等厂商出 ARM 版本或者用兼容层凑合。我的建议是先用兼容层试能跑且性能可接受就用跑不起来或者太慢再考虑虚拟机如果程序很关键且长期使用那就推动原生移植。这个决策顺序能帮你用最小的成本解决问题。7. 关于这套技术栈的一些个人体会折腾 Madeira 这类方案有一段时间了最大的感受是兼容层技术的进步速度远超预期。几年前在 ARM 上跑 x86 Windows 程序还是实验室里的玩具现在已经能实际用了。FEX-Emu 的翻译效率、DXMT 的图形兼容性、Wine 的 API 覆盖率都在快速迭代。但也要清醒地认识到这套方案目前还是能用而不是好用。配置过程繁琐出问题时排查链路长性能有损耗这些都是现实。它适合愿意折腾、对性能有一定容忍度的用户不适合追求开箱即用的人。最后分享一个实用技巧把整个配置过程脚本化。从依赖安装、Wine 前缀初始化、字体配置、FEX 注册到 DXMT 部署全部写成 shell 脚本。这样换设备或者重装系统时一条命令就能恢复环境省去大量重复劳动。我自己的脚本放在一个私有仓库里每次踩到新坑就更新进去现在已经成为我最常用的工具之一了。