1. 从“Madeira”这个名字说起它到底想解决什么问题第一次看到“Madeira”这个项目标题加上旁边那一串热搜词——FEX-Emu、Wine、DXMT、iOS、x86-64——我脑子里第一反应是这又是一个在“跨架构运行 Windows 程序”这条老路上折腾的新玩家。为什么这么说因为把这几个词摆在一起指向性其实非常明确在非 x86 的硬件平台上把 x86-64 的 Windows 应用跑起来而且还要跑得尽量顺。先把这个链条捋清楚。FEX-Emu 是一个用户态的 x86-64 指令翻译层它的活儿是把 x86-64 的机器码实时翻译成 ARM64 能执行的指令Wine 负责把 Windows 的 API 调用翻译成 POSIX 调用DXMT 则是把 Direct3D 的调用转译到 Metal 上。这三者叠起来理论上就能让一台 ARM 设备比如 Apple Silicon 的 Mac或者某些 ARM 服务器、ARM 掌机去运行原本只认 Windows x86 的游戏和软件。Madeira 这个名字从项目定位看大概率就是把这套组合拳打包、调优、做成一个相对开箱即用的方案。那它解决的是谁的痛点我接触过不少这类需求的人大致分三类。第一类是手里有 ARM 设备但被某个 Windows 独占软件卡住的比如某些行业工具、老游戏、特定版本的办公套件第二类是想在 Mac 上玩 Windows 游戏但不想装双系统、不想开虚拟机的第三类是做兼容层、模拟器相关开发的想找一个已经调好的参考实现来研究。这三类人的共同诉求就一个字省事。他们不想自己去编译 FEX-Emu、配 Wine 前缀、调 DXMT 的 dll他们想要的是一个能直接跑起来的东西。Madeira 的价值就在这儿。它不是从零发明了什么新技术而是把已有的几块拼图——FEX-Emu 的 CPU 翻译、Wine 的 API 兼容、DXMT 的图形转译——用一套配置和脚本粘起来并且针对常见的坑做了预设。这种“整合型项目”往往比单个技术组件更贴近实际使用因为真正让人崩溃的从来不是某个组件不行而是组件之间的衔接。提示这类跨架构兼容方案性能损耗是绕不开的。x86-64 到 ARM64 的指令翻译本身就有开销再叠加 Wine 的 API 转换和 DXMT 的图形转译最终帧率能到原生的一半就算不错。心里要有预期别指望它和原生一样快。适合谁来参考这篇内容如果你只是想“用”那关注它的安装和配置流程就够了如果你想“改”或者“学”那得把 FEX-Emu、Wine、DXMT 各自的原理都过一遍。我下面会两条线都讲但重点放在实操和踩坑上因为这才是真正花时间的地方。2. 整体架构拆解三层翻译是怎么叠起来的2.1 为什么是 FEX-Emu 而不是 QEMU很多人一提“在 ARM 上跑 x86 程序”第一反应是 QEMU。QEMU 确实能做全系统模拟但它的问题是重——它模拟的是整台机器包括 CPU、内存、外设开销非常大。而 FEX-Emu 走的是另一条路用户态翻译。它不模拟整台机器只翻译应用程序的指令流系统调用直接透传给宿主系统。这就好比你要翻译一本书QEMU 是把整本书连同出版社、印刷厂一起搬过来FEX-Emu 只翻译正文纸张和装订直接用现成的。FEX-Emu 的核心机制是JIT 翻译 块缓存。它把 x86-64 的指令按基本块切分翻译成 ARM64 指令后缓存起来下次执行到同一块就直接用缓存。这个设计对游戏这种有大量循环的场景特别友好因为热点代码翻译一次就能反复用。实测下来FEX-Emu 在跑一些老游戏时性能能到原生的 60% 到 80%比 QEMU 的全系统模拟高出一大截。但 FEX-Emu 也有它的局限。它依赖宿主系统的内核支持对某些特殊的 x86 指令比如某些 SIMD 扩展支持不完整遇到用了这些指令的程序就会崩。而且它的翻译是“按需”的第一次执行某段代码时会有明显的卡顿这就是所谓的“着色器编译卡顿”的 CPU 版本。Madeira 在这块通常会做一些预翻译或者缓存预热的工作减少首次运行的卡顿。2.2 Wine 在中间扮演什么角色FEX-Emu 解决了“指令能跑”的问题但 Windows 程序不是光有指令就能跑的它还要调用 Windows 的 API——CreateFile、RegOpenKey、Direct3DCreate9 这些。这些 API 在 Linux 或 macOS 上根本不存在Wine 的活儿就是把这些调用翻译成宿主系统能理解的调用。Wine 的实现方式很有意思。它不模拟 Windows 内核而是自己实现了一套 Windows API 的兼容层。比如 Windows 程序调用 CreateFile 想打开一个文件Wine 会把它转成 Linux 的 open 或者 macOS 的 fopen。注册表呢Wine 用一个普通的文件来模拟存在用户目录下的 .wine 文件夹里。这种“翻译而非模拟”的思路让 Wine 的性能比虚拟机好得多但也带来了兼容性问题——有些程序依赖 Windows 内核的特定行为Wine 模拟得不够像就会出问题。Madeira 里 Wine 的配置有几个关键点。第一是Wine 前缀prefix的架构必须是 win64 才能跑 64 位程序但很多老程序需要 32 位支持所以通常要配一个 WoW64 的环境。第二是Windows 版本号的伪装有些程序会检查系统版本你得在 Wine 配置里把它设成 Windows 10 或 11。第三是DLL 覆盖override某些程序自带的 dll 比 Wine 内置的好用或者反过来这需要逐个调试。2.3 DXMT把 Direct3D 接到 Metal 上图形这块是最容易出问题的。Windows 游戏大多用 Direct3D而 macOS 用的是 MetalLinux 用的是 Vulkan 或 OpenGL。DXMT 的作用就是把 D3D 的调用转译成 Metal。为什么是 Metal 而不是 Vulkan因为在 Apple Silicon 的 Mac 上Metal 是原生图形 API性能最好而且 Apple 的 GPU 驱动对 Metal 的优化最到位。DXMT 的工作方式和 DXVK 类似都是把 D3D 的接口实现一遍底层接到另一个图形 API。区别在于 DXVK 接的是 VulkanDXMT 接的是 Metal。这个转译过程涉及大量的状态映射、着色器转换、资源管理复杂度很高。DXMT 目前对 D3D11 的支持比较成熟D3D12 还在完善中D3D9 则通常交给 Wine 自带的 wined3d 或者 DXVK 的 D3D9 分支来处理。在 Madeira 的架构里DXMT 的 dll 需要被正确注册到 Wine 的前缀里并且要设置好环境变量告诉 Wine 用 DXMT 而不是内置的 wined3d。这一步如果配错游戏要么黑屏要么直接崩。我见过最常见的错误就是 dll 没覆盖对结果 Wine 用了自带的 wined3d性能差一大截不说还各种渲染错误。组件职责输入输出FEX-EmuCPU 指令翻译x86-64 机器码ARM64 机器码WineWindows API 翻译Windows API 调用POSIX 调用DXMT图形 API 翻译Direct3D 调用Metal 调用这三层是串联的FEX-Emu 翻译出来的 ARM64 代码里会调用 Wine 提供的 APIWine 再调用 DXMT 处理图形。任何一层出问题整个链条就断了。所以调试的时候要有条理先确认 FEX-Emu 能跑简单的 x86 程序再确认 Wine 能跑简单的 Windows 程序最后才上图形。3. 实操部署从零把 Madeira 跑起来3.1 环境准备与依赖检查在动手之前先把环境确认清楚。Madeira 这套方案对宿主系统有要求不是随便什么机器都能跑。首先是 CPU 架构必须是 ARM64因为 FEX-Emu 是给 ARM 用的。如果你是在 x86 机器上那根本不需要 FEX-Emu直接跑 Wine 就行。其次是操作系统macOS 上要 Apple SiliconM 系列芯片Linux 上要 ARM64 发行版比如 Asahi Linux 或者某些 ARM 服务器系统。依赖这块核心是几个FEX-Emu 的运行时库、Wine 的编译产物、DXMT 的 dll 文件。Madeira 通常会把这些打包好但你还是得确认系统里有基础的开发库和图形驱动。在 macOS 上Xcode Command Line Tools 是必须的因为 Metal 的编译需要它。在 Linux 上Mesa 或者厂商的 GPU 驱动要装好否则 DXMT 没法工作。注意如果你用的是 macOS系统版本不要太老。DXMT 依赖较新的 Metal 特性macOS 12 以下可能会遇到兼容性问题。另外Apple Silicon 的机型里M1 和 M2 的 GPU 驱动有些差异某些游戏在 M1 上能跑在 M2 上反而有问题这个要有心理准备。检查依赖的命令我习惯用这几个# 确认 CPU 架构 uname -m # 应该输出 arm64 或 aarch64 # 确认系统版本macOS sw_vers # 确认 Metal 支持macOS system_profiler SPDisplaysDataType | grep Metal在 Linux 上还要确认内核版本和 binfmt_misc 的支持因为 FEX-Emu 需要注册一个 binfmt 处理器让内核知道遇到 x86-64 的可执行文件时交给 FEX-Emu 处理。这个注册通常由安装脚本完成但如果你是自己编译的得手动配。3.2 FEX-Emu 的安装与配置FEX-Emu 的安装有两种方式用预编译的包或者从源码编译。预编译的包省事但可能不带最新的优化源码编译麻烦但能针对你的 CPU 做优化。我一般推荐先用预编译的跑通了再考虑编译。在 macOS 上FEX-Emu 通常通过 Homebrew 或者项目提供的脚本安装。安装完之后关键的一步是注册 binfmt。macOS 没有 Linux 的 binfmt_misc所以 FEX-Emu 在 macOS 上是通过一个 wrapper 来工作的——你运行一个 x86-64 程序时实际上是在运行 FEX-Emu然后把程序路径作为参数传进去。# 典型的 FEX-Emu 调用方式 FEXLoader /path/to/x86_64/program在 Linux 上binfmt 注册之后就可以直接运行 x86-64 程序了内核会自动调用 FEX-Emu。注册的命令大概是这样的# 注册 binfmt需要 root echo :FEXEmu:M::\x7fELF\x02\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x3e\x00:\xff\xff\xff\xff\xff\xff\xff\x00\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff\xff:/usr/bin/FEXLoader:PF /proc/sys/fs/binfmt_misc/register这串东西看着吓人其实就是在告诉内核如果文件开头是 ELF 格式且机器类型是 x86-64就交给 /usr/bin/FEXLoader 处理。配好之后你直接运行 x86-64 的二进制系统就会自动用 FEX-Emu 跑。FEX-Emu 的配置项里有几个值得调的。RootFS是它的根文件系统里面放了 x86-64 的系统库因为有些程序会去加载 /lib 下的库FEX-Emu 需要提供一个 x86-64 的版本。Thunking是它和宿主系统交互的机制比如图形调用怎么从 FEX-Emu 传到宿主这个配不好图形就出不来。JIT 缓存大小也值得调缓存太小会导致频繁重新翻译太大又占内存一般设个几百 MB 比较合适。3.3 Wine 前缀的创建与调优Wine 的前缀是个独立的目录里面模拟了一个 Windows 的 C 盘。创建前缀的命令是wineboot但 Madeira 通常会提供一个脚本帮你配好。创建的时候要注意架构WINEARCHwin64创建 64 位前缀但为了兼容 32 位程序通常还要装 WoW64 支持。# 创建 64 位前缀 WINEARCHwin64 WINEPREFIX~/.madeira/wineprefix wineboot -u # 安装必要的组件 WINEPREFIX~/.madeira/wineprefix winetricks corefonts vcrun2019 dotnet48winetricks 是个好东西它能帮你装一些 Windows 程序运行必需的组件比如 .NET Framework、Visual C 运行库、字体等。很多游戏跑不起来就是因为缺这些。但 winetricks 也不是万能的有些组件在 ARM 上装不了因为它们是 x86 的安装程序得靠 FEX-Emu 翻译而 FEX-Emu 对某些安装程序的兼容性不好。Wine 的配置里Windows 版本要设对。有些游戏检查到 Windows 7 就不让跑你得设成 Windows 10。DLL 覆盖也很关键比如 d3d11.dll 要覆盖成 DXMT 的版本不然 Wine 会用自带的 wined3d。注册表里有些键值需要改比如显卡的显存大小、驱动的版本号这些会影响游戏的画质设置。提示Wine 前缀一旦创建里面的配置就固定了。如果你改错了什么最省事的办法是删掉前缀重建而不是去修。重建前记得把存档和配置备份出来不然哭都来不及。3.4 DXMT 的集成与图形调试DXMT 的集成是最后一步也是最容易翻车的一步。你需要把 DXMT 编译出来的 dll 放到 Wine 前缀的 system32 目录下然后在 Wine 的配置里把这些 dll 设为“原生”优先。具体来说d3d11.dll、dxgi.dll、d3d10core.dll 这几个都要覆盖。# 把 DXMT 的 dll 复制到前缀里 cp dxmt/build/bin/d3d11.dll ~/.madeira/wineprefix/drive_c/windows/system32/ cp dxmt/build/bin/dxgi.dll ~/.madeira/wineprefix/drive_c/windows/system32/ # 设置 dll 覆盖 WINEPREFIX~/.madeira/wineprefix winecfg # 在 Libraries 标签页里把 d3d11 和 dxgi 设为 native环境变量这块DXMT 需要知道用哪个 GPU、开不开调试输出。常用的有DXMT_LOG_LEVEL控制日志详细程度DXMT_SHADER_CACHE指定着色器缓存路径。着色器缓存很重要第一次跑游戏时会编译着色器很慢但缓存之后第二次就快了。如果你换驱动或者换游戏版本缓存可能要清掉重建。图形调试是最耗时间的。常见的问题包括黑屏可能是 dll 没覆盖对或者 Metal 设备创建失败、花屏着色器转换有问题、闪退某个 D3D 特性不支持。排查的时候先看日志DXMT 的日志会告诉你哪一步失败了。如果日志看不出问题可以用MTL_DEBUG_LAYER1打开 Metal 的调试层它会报一些 API 使用错误。4. 常见问题与排查技巧实录4.1 启动就崩先查 FEX-Emu 还是 Wine程序启动就崩是最常见也最难查的问题。我的经验是先分层排查。第一步确认 FEX-Emu 本身能工作。找一个简单的 x86-64 Linux 程序比如hello world用 FEXLoader 跑一下能输出就说明 FEX-Emu 没问题。第二步确认 Wine 能工作。跑一个简单的 Windows 程序比如 notepad能起来就说明 Wine 的基本配置没问题。第三步才是跑目标程序。如果 FEX-Emu 跑简单程序就崩那可能是 binfmt 没注册对或者 RootFS 缺库。用FEXLoader的时候加-v参数能看到详细的日志它会告诉你加载了哪些库、翻译了哪些指令。如果 Wine 跑 notepad 就崩那可能是前缀创建有问题或者缺字体、缺运行库。winetricks 装一遍 corefonts 和 vcrun 通常能解决大部分问题。目标程序崩的时候要看崩在哪一步。如果是在加载 dll 的时候崩可能是 dll 覆盖配错了如果是在创建窗口的时候崩可能是图形初始化失败如果是在读存档的时候崩可能是文件路径或者权限问题。Wine 的日志用WINEDEBUGall能打得很详细但信息量太大一般用WINEDEBUGloaddll,d3d这种针对性的就够了。4.2 图形问题黑屏、花屏、帧率低图形问题分三种黑屏、花屏、帧率低。黑屏最常见的原因是 DXMT 没生效Wine 用了自带的 wined3d。确认方法是看日志里有没有 DXMT 的输出如果没有那就是 dll 没覆盖对。另一个原因是 Metal 设备创建失败这在 macOS 上可能是权限问题或者 GPU 被其他程序独占了。花屏通常是着色器转换的问题。DXMT 把 D3D 的着色器转成 Metal 的着色器时某些指令映射不对就会导致渲染错误。这种情况一般只能等 DXMT 更新或者换一个游戏版本试试。有时候降低画质设置能绕过比如关掉某些特效。帧率低的原因就多了。FEX-Emu 的翻译开销、Wine 的 API 转换开销、DXMT 的图形转译开销三者叠加。优化的话FEX-Emu 那边可以开 JIT 缓存、调翻译块大小Wine 那边可以关掉不必要的调试输出、用更快的文件系统DXMT 那边可以开着色器缓存、降低画质。实测下来把画质从高降到中帧率能提升 30% 到 50%因为 GPU 的压力小了CPU 的翻译压力也小了。问题可能原因排查方法解决方向启动崩溃dll 覆盖错误查 Wine 日志的 loaddll重新配置 dll 覆盖黑屏DXMT 未生效查日志有无 DXMT 输出确认 d3d11.dll 被覆盖花屏着色器转换错误查 DXMT 日志的 shader 部分降低画质或等更新帧率低多层翻译开销分别测 CPU 和 GPU 占用降画质、开缓存音频卡顿音频后端延迟查 Wine 的 audio 日志换音频后端或调缓冲区4.3 音频与输入容易被忽略的细节音频问题经常被忽略但体验影响很大。Wine 的音频后端有几个选择PulseAudio、ALSA、CoreAudiomacOS。在 macOS 上CoreAudio 是原生的延迟最低但有时候会有爆音。在 Linux 上PulseAudio 兼容性最好但延迟高一点。如果游戏对音频延迟敏感比如音游那得调缓冲区大小但调太小又会卡顿得找个平衡。输入这块手柄的支持是个坑。Wine 通过 SDL 或者 evdev 来读手柄但 FEX-Emu 翻译之后的程序能不能正确读到手柄取决于 Wine 的配置。有些游戏需要 XInputWine 内置了 xinput 的实现但版本可能对不上。用 winetricks 装 xinput 有时候能解决。键盘鼠标一般没问题但某些游戏会锁鼠标指针在 Wine 里可能锁不住需要开“捕获鼠标”的选项。注意如果你在 macOS 上跑手柄的权限需要在系统设置里给终端或者 Madeira 的启动器授权不然读不到输入。这个坑我踩过查了半天以为是 Wine 的问题结果是系统权限没给。4.4 性能调优的几条实战经验性能调优这块我总结了几条经验。第一FEX-Emu 的 JIT 缓存一定要开而且缓存目录要放在 SSD 上放机械硬盘上加载缓存会很慢。第二Wine 的调试输出一定要关WINEDEBUG-all能省不少 CPU。第三DXMT 的着色器缓存要开而且不要频繁清清一次就要重新编译所有着色器。第四画质设置要务实别想着在 ARM 上跑 4K 全高1080p 中画质能稳 30 帧就是胜利。还有一个容易被忽略的点是内存。FEX-Emu 翻译后的代码、Wine 的前缀、DXMT 的缓存都占内存。如果内存不够系统会频繁换页性能断崖式下跌。16GB 是起步32GB 会更从容。在 macOS 上还要注意统一内存的分配GPU 和 CPU 共享内存如果 GPU 占用太多CPU 那边就不够了。5. 这套方案还能怎么扩展Madeira 这套组合拳本质上是一个“跨架构 Windows 兼容层”的参考实现。它的思路可以扩展到很多场景。比如在 ARM 服务器上跑 Windows 的 CI/CD 任务用 FEX-Emu Wine 就能省掉一台 x86 机器。再比如在 ARM 掌机上跑老游戏这套方案也能用只是要针对掌机的屏幕和手柄做适配。从技术演进的角度看FEX-Emu 在持续优化它的翻译器未来对 AVX、AVX2 这些指令集的支持会更完整Wine 在往 WoW64 统一架构走以后 32 位和 64 位的界限会模糊DXMT 在补 D3D12 的支持未来能跑的游戏会更多。这三个组件都在活跃开发中Madeira 作为整合方需要持续跟进上游的更新。如果你是想自己搭一套类似的方案我的建议是先把单个组件跑通再考虑整合。很多人一上来就搞全套结果出了问题不知道是哪一层的。先跑 FEX-Emu 跑 Linux 程序再跑 Wine 跑 Windows 程序最后上 DXMT 跑图形程序每一步都确认没问题了再往下走。这样虽然慢但稳。最后分享一个小技巧日志是你的朋友。FEX-Emu、Wine、DXMT 都有详细的日志遇到问题先看日志比瞎猜快得多。日志里看不懂的地方去搜对应的错误码或者函数名通常能找到别人踩过的坑。这个领域变化快文档往往跟不上社区里的讨论反而更有用。
1. 从“Madeira”这个名字说起它到底想解决什么问题第一次看到“Madeira”这个项目标题加上旁边那一串热搜词——FEX-Emu、Wine、DXMT、iOS、x86-64——我脑子里第一反应是这又是一个在“跨架构运行 Windows 程序”这条老路上折腾的新玩家。为什么这么说因为把这几个词摆在一起指向性其实非常明确在非 x86 的硬件平台上把 x86-64 的 Windows 应用跑起来而且还要跑得尽量顺。先把这个链条捋清楚。FEX-Emu 是一个用户态的 x86-64 指令翻译层它的活儿是把 x86-64 的机器码实时翻译成 ARM64 能执行的指令Wine 负责把 Windows 的 API 调用翻译成 POSIX 调用DXMT 则是把 Direct3D 的调用转译到 Metal 上。这三者叠起来理论上就能让一台 ARM 设备比如 Apple Silicon 的 Mac或者某些 ARM 服务器、ARM 掌机去运行原本只认 Windows x86 的游戏和软件。Madeira 这个名字从项目定位看大概率就是把这套组合拳打包、调优、做成一个相对开箱即用的方案。那它解决的是谁的痛点我接触过不少这类需求的人大致分三类。第一类是手里有 ARM 设备但被某个 Windows 独占软件卡住的比如某些行业工具、老游戏、特定版本的办公套件第二类是想在 Mac 上玩 Windows 游戏但不想装双系统、不想开虚拟机的第三类是做兼容层、模拟器相关开发的想找一个已经调好的参考实现来研究。这三类人的共同诉求就一个字省事。他们不想自己去编译 FEX-Emu、配 Wine 前缀、调 DXMT 的 dll他们想要的是一个能直接跑起来的东西。Madeira 的价值就在这儿。它不是从零发明了什么新技术而是把已有的几块拼图——FEX-Emu 的 CPU 翻译、Wine 的 API 兼容、DXMT 的图形转译——用一套配置和脚本粘起来并且针对常见的坑做了预设。这种“整合型项目”往往比单个技术组件更贴近实际使用因为真正让人崩溃的从来不是某个组件不行而是组件之间的衔接。提示这类跨架构兼容方案性能损耗是绕不开的。x86-64 到 ARM64 的指令翻译本身就有开销再叠加 Wine 的 API 转换和 DXMT 的图形转译最终帧率能到原生的一半就算不错。心里要有预期别指望它和原生一样快。适合谁来参考这篇内容如果你只是想“用”那关注它的安装和配置流程就够了如果你想“改”或者“学”那得把 FEX-Emu、Wine、DXMT 各自的原理都过一遍。我下面会两条线都讲但重点放在实操和踩坑上因为这才是真正花时间的地方。2. 整体架构拆解三层翻译是怎么叠起来的2.1 为什么是 FEX-Emu 而不是 QEMU很多人一提“在 ARM 上跑 x86 程序”第一反应是 QEMU。QEMU 确实能做全系统模拟但它的问题是重——它模拟的是整台机器包括 CPU、内存、外设开销非常大。而 FEX-Emu 走的是另一条路用户态翻译。它不模拟整台机器只翻译应用程序的指令流系统调用直接透传给宿主系统。这就好比你要翻译一本书QEMU 是把整本书连同出版社、印刷厂一起搬过来FEX-Emu 只翻译正文纸张和装订直接用现成的。FEX-Emu 的核心机制是JIT 翻译 块缓存。它把 x86-64 的指令按基本块切分翻译成 ARM64 指令后缓存起来下次执行到同一块就直接用缓存。这个设计对游戏这种有大量循环的场景特别友好因为热点代码翻译一次就能反复用。实测下来FEX-Emu 在跑一些老游戏时性能能到原生的 60% 到 80%比 QEMU 的全系统模拟高出一大截。但 FEX-Emu 也有它的局限。它依赖宿主系统的内核支持对某些特殊的 x86 指令比如某些 SIMD 扩展支持不完整遇到用了这些指令的程序就会崩。而且它的翻译是“按需”的第一次执行某段代码时会有明显的卡顿这就是所谓的“着色器编译卡顿”的 CPU 版本。Madeira 在这块通常会做一些预翻译或者缓存预热的工作减少首次运行的卡顿。2.2 Wine 在中间扮演什么角色FEX-Emu 解决了“指令能跑”的问题但 Windows 程序不是光有指令就能跑的它还要调用 Windows 的 API——CreateFile、RegOpenKey、Direct3DCreate9 这些。这些 API 在 Linux 或 macOS 上根本不存在Wine 的活儿就是把这些调用翻译成宿主系统能理解的调用。Wine 的实现方式很有意思。它不模拟 Windows 内核而是自己实现了一套 Windows API 的兼容层。比如 Windows 程序调用 CreateFile 想打开一个文件Wine 会把它转成 Linux 的 open 或者 macOS 的 fopen。注册表呢Wine 用一个普通的文件来模拟存在用户目录下的 .wine 文件夹里。这种“翻译而非模拟”的思路让 Wine 的性能比虚拟机好得多但也带来了兼容性问题——有些程序依赖 Windows 内核的特定行为Wine 模拟得不够像就会出问题。Madeira 里 Wine 的配置有几个关键点。第一是Wine 前缀prefix的架构必须是 win64 才能跑 64 位程序但很多老程序需要 32 位支持所以通常要配一个 WoW64 的环境。第二是Windows 版本号的伪装有些程序会检查系统版本你得在 Wine 配置里把它设成 Windows 10 或 11。第三是DLL 覆盖override某些程序自带的 dll 比 Wine 内置的好用或者反过来这需要逐个调试。2.3 DXMT把 Direct3D 接到 Metal 上图形这块是最容易出问题的。Windows 游戏大多用 Direct3D而 macOS 用的是 MetalLinux 用的是 Vulkan 或 OpenGL。DXMT 的作用就是把 D3D 的调用转译成 Metal。为什么是 Metal 而不是 Vulkan因为在 Apple Silicon 的 Mac 上Metal 是原生图形 API性能最好而且 Apple 的 GPU 驱动对 Metal 的优化最到位。DXMT 的工作方式和 DXVK 类似都是把 D3D 的接口实现一遍底层接到另一个图形 API。区别在于 DXVK 接的是 VulkanDXMT 接的是 Metal。这个转译过程涉及大量的状态映射、着色器转换、资源管理复杂度很高。DXMT 目前对 D3D11 的支持比较成熟D3D12 还在完善中D3D9 则通常交给 Wine 自带的 wined3d 或者 DXVK 的 D3D9 分支来处理。在 Madeira 的架构里DXMT 的 dll 需要被正确注册到 Wine 的前缀里并且要设置好环境变量告诉 Wine 用 DXMT 而不是内置的 wined3d。这一步如果配错游戏要么黑屏要么直接崩。我见过最常见的错误就是 dll 没覆盖对结果 Wine 用了自带的 wined3d性能差一大截不说还各种渲染错误。组件职责输入输出FEX-EmuCPU 指令翻译x86-64 机器码ARM64 机器码WineWindows API 翻译Windows API 调用POSIX 调用DXMT图形 API 翻译Direct3D 调用Metal 调用这三层是串联的FEX-Emu 翻译出来的 ARM64 代码里会调用 Wine 提供的 APIWine 再调用 DXMT 处理图形。任何一层出问题整个链条就断了。所以调试的时候要有条理先确认 FEX-Emu 能跑简单的 x86 程序再确认 Wine 能跑简单的 Windows 程序最后才上图形。3. 实操部署从零把 Madeira 跑起来3.1 环境准备与依赖检查在动手之前先把环境确认清楚。Madeira 这套方案对宿主系统有要求不是随便什么机器都能跑。首先是 CPU 架构必须是 ARM64因为 FEX-Emu 是给 ARM 用的。如果你是在 x86 机器上那根本不需要 FEX-Emu直接跑 Wine 就行。其次是操作系统macOS 上要 Apple SiliconM 系列芯片Linux 上要 ARM64 发行版比如 Asahi Linux 或者某些 ARM 服务器系统。依赖这块核心是几个FEX-Emu 的运行时库、Wine 的编译产物、DXMT 的 dll 文件。Madeira 通常会把这些打包好但你还是得确认系统里有基础的开发库和图形驱动。在 macOS 上Xcode Command Line Tools 是必须的因为 Metal 的编译需要它。在 Linux 上Mesa 或者厂商的 GPU 驱动要装好否则 DXMT 没法工作。注意如果你用的是 macOS系统版本不要太老。DXMT 依赖较新的 Metal 特性macOS 12 以下可能会遇到兼容性问题。另外Apple Silicon 的机型里M1 和 M2 的 GPU 驱动有些差异某些游戏在 M1 上能跑在 M2 上反而有问题这个要有心理准备。检查依赖的命令我习惯用这几个# 确认 CPU 架构 uname -m # 应该输出 arm64 或 aarch64 # 确认系统版本macOS sw_vers # 确认 Metal 支持macOS system_profiler SPDisplaysDataType | grep Metal在 Linux 上还要确认内核版本和 binfmt_misc 的支持因为 FEX-Emu 需要注册一个 binfmt 处理器让内核知道遇到 x86-64 的可执行文件时交给 FEX-Emu 处理。这个注册通常由安装脚本完成但如果你是自己编译的得手动配。3.2 FEX-Emu 的安装与配置FEX-Emu 的安装有两种方式用预编译的包或者从源码编译。预编译的包省事但可能不带最新的优化源码编译麻烦但能针对你的 CPU 做优化。我一般推荐先用预编译的跑通了再考虑编译。在 macOS 上FEX-Emu 通常通过 Homebrew 或者项目提供的脚本安装。安装完之后关键的一步是注册 binfmt。macOS 没有 Linux 的 binfmt_misc所以 FEX-Emu 在 macOS 上是通过一个 wrapper 来工作的——你运行一个 x86-64 程序时实际上是在运行 FEX-Emu然后把程序路径作为参数传进去。# 典型的 FEX-Emu 调用方式 FEXLoader /path/to/x86_64/program在 Linux 上binfmt 注册之后就可以直接运行 x86-64 程序了内核会自动调用 FEX-Emu。注册的命令大概是这样的# 注册 binfmt需要 root echo :FEXEmu:M::\x7fELF\x02\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x3e\x00:\xff\xff\xff\xff\xff\xff\xff\x00\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff\xff:/usr/bin/FEXLoader:PF /proc/sys/fs/binfmt_misc/register这串东西看着吓人其实就是在告诉内核如果文件开头是 ELF 格式且机器类型是 x86-64就交给 /usr/bin/FEXLoader 处理。配好之后你直接运行 x86-64 的二进制系统就会自动用 FEX-Emu 跑。FEX-Emu 的配置项里有几个值得调的。RootFS是它的根文件系统里面放了 x86-64 的系统库因为有些程序会去加载 /lib 下的库FEX-Emu 需要提供一个 x86-64 的版本。Thunking是它和宿主系统交互的机制比如图形调用怎么从 FEX-Emu 传到宿主这个配不好图形就出不来。JIT 缓存大小也值得调缓存太小会导致频繁重新翻译太大又占内存一般设个几百 MB 比较合适。3.3 Wine 前缀的创建与调优Wine 的前缀是个独立的目录里面模拟了一个 Windows 的 C 盘。创建前缀的命令是wineboot但 Madeira 通常会提供一个脚本帮你配好。创建的时候要注意架构WINEARCHwin64创建 64 位前缀但为了兼容 32 位程序通常还要装 WoW64 支持。# 创建 64 位前缀 WINEARCHwin64 WINEPREFIX~/.madeira/wineprefix wineboot -u # 安装必要的组件 WINEPREFIX~/.madeira/wineprefix winetricks corefonts vcrun2019 dotnet48winetricks 是个好东西它能帮你装一些 Windows 程序运行必需的组件比如 .NET Framework、Visual C 运行库、字体等。很多游戏跑不起来就是因为缺这些。但 winetricks 也不是万能的有些组件在 ARM 上装不了因为它们是 x86 的安装程序得靠 FEX-Emu 翻译而 FEX-Emu 对某些安装程序的兼容性不好。Wine 的配置里Windows 版本要设对。有些游戏检查到 Windows 7 就不让跑你得设成 Windows 10。DLL 覆盖也很关键比如 d3d11.dll 要覆盖成 DXMT 的版本不然 Wine 会用自带的 wined3d。注册表里有些键值需要改比如显卡的显存大小、驱动的版本号这些会影响游戏的画质设置。提示Wine 前缀一旦创建里面的配置就固定了。如果你改错了什么最省事的办法是删掉前缀重建而不是去修。重建前记得把存档和配置备份出来不然哭都来不及。3.4 DXMT 的集成与图形调试DXMT 的集成是最后一步也是最容易翻车的一步。你需要把 DXMT 编译出来的 dll 放到 Wine 前缀的 system32 目录下然后在 Wine 的配置里把这些 dll 设为“原生”优先。具体来说d3d11.dll、dxgi.dll、d3d10core.dll 这几个都要覆盖。# 把 DXMT 的 dll 复制到前缀里 cp dxmt/build/bin/d3d11.dll ~/.madeira/wineprefix/drive_c/windows/system32/ cp dxmt/build/bin/dxgi.dll ~/.madeira/wineprefix/drive_c/windows/system32/ # 设置 dll 覆盖 WINEPREFIX~/.madeira/wineprefix winecfg # 在 Libraries 标签页里把 d3d11 和 dxgi 设为 native环境变量这块DXMT 需要知道用哪个 GPU、开不开调试输出。常用的有DXMT_LOG_LEVEL控制日志详细程度DXMT_SHADER_CACHE指定着色器缓存路径。着色器缓存很重要第一次跑游戏时会编译着色器很慢但缓存之后第二次就快了。如果你换驱动或者换游戏版本缓存可能要清掉重建。图形调试是最耗时间的。常见的问题包括黑屏可能是 dll 没覆盖对或者 Metal 设备创建失败、花屏着色器转换有问题、闪退某个 D3D 特性不支持。排查的时候先看日志DXMT 的日志会告诉你哪一步失败了。如果日志看不出问题可以用MTL_DEBUG_LAYER1打开 Metal 的调试层它会报一些 API 使用错误。4. 常见问题与排查技巧实录4.1 启动就崩先查 FEX-Emu 还是 Wine程序启动就崩是最常见也最难查的问题。我的经验是先分层排查。第一步确认 FEX-Emu 本身能工作。找一个简单的 x86-64 Linux 程序比如hello world用 FEXLoader 跑一下能输出就说明 FEX-Emu 没问题。第二步确认 Wine 能工作。跑一个简单的 Windows 程序比如 notepad能起来就说明 Wine 的基本配置没问题。第三步才是跑目标程序。如果 FEX-Emu 跑简单程序就崩那可能是 binfmt 没注册对或者 RootFS 缺库。用FEXLoader的时候加-v参数能看到详细的日志它会告诉你加载了哪些库、翻译了哪些指令。如果 Wine 跑 notepad 就崩那可能是前缀创建有问题或者缺字体、缺运行库。winetricks 装一遍 corefonts 和 vcrun 通常能解决大部分问题。目标程序崩的时候要看崩在哪一步。如果是在加载 dll 的时候崩可能是 dll 覆盖配错了如果是在创建窗口的时候崩可能是图形初始化失败如果是在读存档的时候崩可能是文件路径或者权限问题。Wine 的日志用WINEDEBUGall能打得很详细但信息量太大一般用WINEDEBUGloaddll,d3d这种针对性的就够了。4.2 图形问题黑屏、花屏、帧率低图形问题分三种黑屏、花屏、帧率低。黑屏最常见的原因是 DXMT 没生效Wine 用了自带的 wined3d。确认方法是看日志里有没有 DXMT 的输出如果没有那就是 dll 没覆盖对。另一个原因是 Metal 设备创建失败这在 macOS 上可能是权限问题或者 GPU 被其他程序独占了。花屏通常是着色器转换的问题。DXMT 把 D3D 的着色器转成 Metal 的着色器时某些指令映射不对就会导致渲染错误。这种情况一般只能等 DXMT 更新或者换一个游戏版本试试。有时候降低画质设置能绕过比如关掉某些特效。帧率低的原因就多了。FEX-Emu 的翻译开销、Wine 的 API 转换开销、DXMT 的图形转译开销三者叠加。优化的话FEX-Emu 那边可以开 JIT 缓存、调翻译块大小Wine 那边可以关掉不必要的调试输出、用更快的文件系统DXMT 那边可以开着色器缓存、降低画质。实测下来把画质从高降到中帧率能提升 30% 到 50%因为 GPU 的压力小了CPU 的翻译压力也小了。问题可能原因排查方法解决方向启动崩溃dll 覆盖错误查 Wine 日志的 loaddll重新配置 dll 覆盖黑屏DXMT 未生效查日志有无 DXMT 输出确认 d3d11.dll 被覆盖花屏着色器转换错误查 DXMT 日志的 shader 部分降低画质或等更新帧率低多层翻译开销分别测 CPU 和 GPU 占用降画质、开缓存音频卡顿音频后端延迟查 Wine 的 audio 日志换音频后端或调缓冲区4.3 音频与输入容易被忽略的细节音频问题经常被忽略但体验影响很大。Wine 的音频后端有几个选择PulseAudio、ALSA、CoreAudiomacOS。在 macOS 上CoreAudio 是原生的延迟最低但有时候会有爆音。在 Linux 上PulseAudio 兼容性最好但延迟高一点。如果游戏对音频延迟敏感比如音游那得调缓冲区大小但调太小又会卡顿得找个平衡。输入这块手柄的支持是个坑。Wine 通过 SDL 或者 evdev 来读手柄但 FEX-Emu 翻译之后的程序能不能正确读到手柄取决于 Wine 的配置。有些游戏需要 XInputWine 内置了 xinput 的实现但版本可能对不上。用 winetricks 装 xinput 有时候能解决。键盘鼠标一般没问题但某些游戏会锁鼠标指针在 Wine 里可能锁不住需要开“捕获鼠标”的选项。注意如果你在 macOS 上跑手柄的权限需要在系统设置里给终端或者 Madeira 的启动器授权不然读不到输入。这个坑我踩过查了半天以为是 Wine 的问题结果是系统权限没给。4.4 性能调优的几条实战经验性能调优这块我总结了几条经验。第一FEX-Emu 的 JIT 缓存一定要开而且缓存目录要放在 SSD 上放机械硬盘上加载缓存会很慢。第二Wine 的调试输出一定要关WINEDEBUG-all能省不少 CPU。第三DXMT 的着色器缓存要开而且不要频繁清清一次就要重新编译所有着色器。第四画质设置要务实别想着在 ARM 上跑 4K 全高1080p 中画质能稳 30 帧就是胜利。还有一个容易被忽略的点是内存。FEX-Emu 翻译后的代码、Wine 的前缀、DXMT 的缓存都占内存。如果内存不够系统会频繁换页性能断崖式下跌。16GB 是起步32GB 会更从容。在 macOS 上还要注意统一内存的分配GPU 和 CPU 共享内存如果 GPU 占用太多CPU 那边就不够了。5. 这套方案还能怎么扩展Madeira 这套组合拳本质上是一个“跨架构 Windows 兼容层”的参考实现。它的思路可以扩展到很多场景。比如在 ARM 服务器上跑 Windows 的 CI/CD 任务用 FEX-Emu Wine 就能省掉一台 x86 机器。再比如在 ARM 掌机上跑老游戏这套方案也能用只是要针对掌机的屏幕和手柄做适配。从技术演进的角度看FEX-Emu 在持续优化它的翻译器未来对 AVX、AVX2 这些指令集的支持会更完整Wine 在往 WoW64 统一架构走以后 32 位和 64 位的界限会模糊DXMT 在补 D3D12 的支持未来能跑的游戏会更多。这三个组件都在活跃开发中Madeira 作为整合方需要持续跟进上游的更新。如果你是想自己搭一套类似的方案我的建议是先把单个组件跑通再考虑整合。很多人一上来就搞全套结果出了问题不知道是哪一层的。先跑 FEX-Emu 跑 Linux 程序再跑 Wine 跑 Windows 程序最后上 DXMT 跑图形程序每一步都确认没问题了再往下走。这样虽然慢但稳。最后分享一个小技巧日志是你的朋友。FEX-Emu、Wine、DXMT 都有详细的日志遇到问题先看日志比瞎猜快得多。日志里看不懂的地方去搜对应的错误码或者函数名通常能找到别人踩过的坑。这个领域变化快文档往往跟不上社区里的讨论反而更有用。
