在ARM Linux上运行Windows应用：FEX-Emu、Wine与DXMT兼容层实战指南

1. 项目缘起：为什么要在 Linux 上折腾 Windows 应用

第一次看到 "Madeira" 这个代号，很多人会以为是某个旅游项目或者饮料品牌。但在我们这群长期混迹于 Linux 桌面兼容层圈子里的人看来，它指向的是一类非常具体的东西：在非 Windows 系统上运行 Windows 应用的一整套兼容方案。围绕它出现的 FEX-Emu、Wine、DXMT 这几个关键词，基本就把技术路线图给画出来了。

先说清楚这个项目要解决什么问题。你手头可能有一台 ARM 架构的笔记本，或者一台跑着国产 Linux 发行版的工作机，日常办公、写代码都没问题，但总有那么几个 Windows 软件绕不过去——可能是某个行业专用的客户端，可能是某个只有 exe 安装包的开发工具，也可能就是你想玩的一款老游戏。重装系统不现实，开虚拟机又太重，这时候兼容层就是最务实的答案。

"Madeira" 这套组合的核心价值在于：它不是一个单点工具，而是一条从指令集翻译到系统调用转换再到图形 API 转译的完整链路。FEX-Emu 负责把 x86-64 指令翻译成 ARM 能执行的指令，Wine 负责把 Windows 的 API 调用映射成 Linux 的对应实现，DXMT 则专门处理 Direct3D 到 Metal 的转换。三者叠加，才能让一个原本为 Windows on x86 编译的程序，在 ARM Linux 上跑起来。

适合看这篇内容的人大概分三类。第一类是 Linux 桌面用户，尤其是用 ARM 设备或者国产发行版的朋友，想搞清楚兼容层到底怎么配。第二类是开发者，需要在自己的软件里集成 Windows 应用运行能力，或者做跨平台适配。第三类是纯粹的技术爱好者，对指令翻译、API 转译这些底层机制感兴趣。不管你是哪一类，我都会尽量把每一步的"为什么"讲透，而不是只丢一堆命令让你抄。

需要提前说明的是，这类方案的配置过程确实有一定门槛，涉及不少参数调整和依赖处理。但好消息是，经过这几年的迭代，主流发行版的软件源里基本都能找到现成的包，不用再从源码一点点编译。下面我会按照实际操作的顺序，把整条链路拆开讲。

2. 技术栈拆解：FEX-Emu、Wine、DXMT 各自扮演什么角色

2.1 FEX-Emu：x86-64 到 ARM 的指令翻译层

FEX-Emu 是这个体系里最底层的一环。它的工作说白了就是实时翻译：程序里原本是给 x86-64 处理器执行的机器码，FEX-Emu 把它翻译成 ARM64 能懂的指令，然后再交给 CPU 执行。这个过程叫动态二进制翻译，简称 DBT。

为什么需要它？因为 ARM 和 x86 的指令集完全不同。x86 是变长指令，复杂但紧凑；ARM 是定长指令，规整但编码方式不一样。一个 Windows 程序编译出来就是 x86-64 的机器码，ARM CPU 根本不认识。FEX-Emu 在中间做了一层"同声传译"，让程序以为自己还在 x86 环境里跑。

这里有个关键点：FEX-Emu 不是模拟器，它不做完整的硬件仿真。模拟器会虚拟出一整套 x86 硬件环境，速度慢但兼容性好；FEX-Emu 走的是翻译路线，把指令直接转成宿主 CPU 能执行的代码，性能损失小得多。实测下来，CPU 密集型任务大概能跑到原生性能的 60% 到 80%，具体取决于程序的指令特征。

配置 FEX-Emu 的时候，有几个参数值得注意。FEX_TSOENABLED控制是否启用 x86 的内存序模型，开了兼容性更好但性能会降；FEX_ROOTFS指定根文件系统路径，一般指向你准备好的 x86 环境目录。还有一个FEX_MULTIBLOCK选项，开启后会对多个基本块做联合优化，对循环密集的程序提升明显。

提示：FEX-Emu 对 AVX 指令的支持是逐步完善的，如果你的程序大量使用 AVX2 或 AVX-512，建议先查一下当前版本的指令覆盖情况，必要时在配置里禁用相关扩展。

2.2 Wine：Windows API 到 Linux 的映射桥梁

Wine 的名字是 "Wine Is Not an Emulator" 的递归缩写，这个命名本身就说明了它的定位——它不做指令翻译，而是直接实现 Windows 的 API。当程序调用CreateWindowEx的时候，Wine 把它转成 X11 或 Wayland 的对应调用；当程序读写注册表的时候，Wine 把它映射到 Linux 文件系统里的一个目录结构。

Wine 的架构可以粗略分成几层。最上面是 DLL 层，每个 Windows 系统 DLL 都有一个对应的 Wine 实现，比如kernel32.dll、user32.dll、gdi32.dll。中间是 NT 内核层，处理进程、线程、内存管理这些核心功能。最下面是驱动层，对接 Linux 的系统调用和图形接口。

在实际使用中，Wine 的版本选择很关键。稳定版（Stable）适合日常使用，兼容性经过充分测试；开发版（Devel）更新快，新功能多，但偶尔会有回归问题；暂存版（Staging）包含一些还没合并进主线的补丁，比如对某些游戏反作弊的绕过、对特定 API 的增强实现。我个人的建议是，如果只是跑办公软件，稳定版足够；如果要跑游戏或者专业软件，优先试 Staging 版。

Wine 的前缀（prefix）机制也值得说一下。每个前缀就是一个独立的 Windows 环境，有自己的注册表、文件系统和 DLL 配置。你可以给不同的软件建不同的前缀，避免依赖冲突。创建前缀用WINEPREFIX=/path/to/prefix winecfg，这个命令会初始化目录结构并打开配置界面。

2.3 DXMT：Direct3D 到 Metal 的图形转译

DXMT 是这三个组件里最年轻的一个，但它的作用不可替代。在 ARM Linux 上，图形栈通常是 Vulkan 或 OpenGL，而 Windows 程序用的是 Direct3D。DXMT 的工作就是把 D3D 的调用翻译成 Metal 的调用——注意，是 Metal，不是 Vulkan。

为什么是 Metal？因为 DXMT 最初是为 Apple Silicon 上的游戏兼容方案设计的，那里只有 Metal 可用。后来这套方案被移植到其他 ARM Linux 环境，虽然宿主图形 API 可能不是 Metal，但 DXMT 的架构设计让它能适配不同的后端。它的核心是一个 D3D 到 Metal 的转译层，中间经过 SPIR-V 做着色器转换。

DXMT 支持 D3D 11 和部分 D3D 12 功能。对于 D3D 9 的老游戏，一般用 DXVK 或者 Wine 自带的 WineD3D 就够了。DXMT 的优势在于对现代图形特性的支持更完整，比如计算着色器、多线程渲染这些。配置的时候，把d3d11.dll和dxgi.dll替换成 DXMT 提供的版本，然后在环境变量里指定DXMT_ENABLE=1就能启用。

注意：DXMT 和 DXVK 不要同时启用，两者会争抢同一个 DLL 的加载权。切换的时候记得清理旧的前缀或者手动替换 DLL 文件。

2.4 三者如何协同工作

把这三个组件串起来看，一个 Windows 程序的执行流程是这样的：程序启动，FEX-Emu 接管 x86-64 指令的翻译；程序调用 Windows API，Wine 把这些调用转成 Linux 系统调用；程序渲染图形，DXMT 把 D3D 调用转成 Metal 或 Vulkan 调用。三层各司其职，缺一不可。

这套架构的优势在于模块化。你可以单独升级 FEX-Emu 来获得更好的指令翻译性能，也可以单独换 Wine 版本来解决某个 API 的兼容问题，还可以单独调 DXMT 的参数来优化图形表现。每个组件都有自己的配置文件和日志系统，排查问题的时候可以逐层定位。

3. 环境准备：从零搭建 Madeira 运行环境

3.1 系统要求与依赖检查

在动手之前，先确认你的系统满足基本要求。架构必须是 ARM64（aarch64），这是 FEX-Emu 的前提。内核版本建议 5.15 以上，因为需要一些较新的系统调用支持。内存至少 8GB，跑图形应用的话 16GB 更稳妥。磁盘空间方面，一个完整的 Wine 前缀加上依赖库，大概需要 2 到 4GB。

依赖包这块，不同发行版的包名不太一样。以 Debian/Ubuntu 系为例，需要装libgl1-mesa-dri、libvulkan1、mesa-vulkan-drivers、libgnutls30、libasound2这些。Fedora 系则是mesa-dri-drivers、vulkan-loader、gnutls、alsa-lib。国产发行版如统信 UOS、麒麟，软件源里一般也有对应的包，名字可能略有差异。

检查命令很简单：

uname -m # 应该输出 aarch64 ldd --version # 确认 glibc 版本，建议 2.31 以上

如果uname -m输出的是x86_64，那说明你的设备本身就是 x86 架构，不需要 FEX-Emu，直接用 Wine 就行。这种情况下 DXMT 也不是必须的，可以用 DXVK 替代。

3.2 FEX-Emu 的安装与配置

FEX-Emu 的安装方式取决于发行版。Arch Linux 的 AUR 里有fex-emu包，直接yay -S fex-emu就行。Debian/Ubuntu 需要添加第三方源或者从源码编译。源码编译的话，依赖比较多，建议预留半小时以上的时间。

编译流程大致是这样：

git clone https://github.com/FEX-Emu/FEX.git cd FEX git submodule update --init --recursive mkdir build && cd build cmake -DCMAKE_BUILD_TYPE=Release -DENABLE_ASSERTIONS=OFF .. make -j$(nproc) sudo make install

编译完成后，需要准备一个 x86-64 的根文件系统。FEX-Emu 官方提供了一个脚本FEXRootFSFetcher，可以自动下载并配置。运行FEXRootFSFetcher，选择适合你需求的发行版镜像，它会处理好目录结构和基本配置。

配置 FEX-Emu 的核心文件是~/.fex-emu/Config.json。几个关键配置项：

{ "Config": { "RootFS": "/home/user/.fex-emu/RootFS/Ubuntu_22_04", "TSOEnabled": true, "Multiblock": true, "SMCChecks": "MTrack", "X87ReducedPrecision": false } }

TSOEnabled建议开启，虽然会损失一点性能，但能避免很多内存序相关的诡异 bug。Multiblock对循环多的程序提升明显。SMCChecks控制自修改代码的检测策略，MTrack是平衡性能和兼容性的选择。

3.3 Wine 的版本选择与安装

Wine 的安装相对简单，但版本选择有讲究。如果你用的是 Ubuntu，官方源里的 Wine 版本通常比较旧，建议添加 WineHQ 的官方源：

sudo dpkg --add-architecture arm64 wget -O- https://dl.winehq.org/wine-builds/winehq.key | sudo apt-key add - sudo add-apt-repository 'deb https://dl.winehq.org/wine-builds/ubuntu/ jammy main' sudo apt update sudo apt install --install-recommends winehq-staging

Staging 版包含了一些对游戏和特殊软件很重要的补丁，比如对ntdll的优化、对某些 DRM 的兼容处理。如果你只是跑普通办公软件，winehq-stable也够用。

安装完成后，用wine --version确认版本。然后初始化默认前缀：

WINEPREFIX=~/.wine-madeira winecfg

这个命令会创建前缀目录并弹出配置窗口。在配置窗口里，建议把 Windows 版本设为 Windows 10，图形驱动选 Vulkan 或 Metal（取决于你的后端），音频驱动选 PulseAudio 或 ALSA。

3.4 DXMT 的获取与部署

DXMT 目前主要通过 GitHub 发布预编译的二进制包。下载对应架构的压缩包，解压后你会看到d3d11.dll、dxgi.dll、d3d10core.dll这几个文件。把它们复制到 Wine 前缀的drive_c/windows/system32目录下，覆盖原有文件。

cp d3d11.dll dxgi.dll d3d10core.dll ~/.wine-madeira/drive_c/windows/system32/

然后在 Wine 的 DLL 覆盖设置里，把d3d11和dxgi设为 "Native"（原生），确保 Wine 加载的是 DXMT 的版本而不是自带的 WineD3D。

DXMT 的配置文件是dxmt.conf，放在前缀根目录下。常用配置项包括：

[DXMT] EnableD3D12 = true MaxFrameLatency = 2 ShaderCache = true ShaderCachePath = ./dxmt_cache

MaxFrameLatency控制预渲染帧数，设成 1 或 2 能降低输入延迟，但可能影响帧率稳定性。ShaderCache建议开启，能显著减少二次启动的着色器编译时间。

4. 实操全流程：跑通第一个 Windows 应用

4.1 创建独立前缀并初始化

不要用默认的~/.wine前缀来跑 Madeira 方案，因为默认前缀可能已经被其他软件污染了。新建一个专用前缀：

export WINEPREFIX=~/.wine-madeira export WINEARCH=win64 wineboot --init

WINEARCH=win64指定创建 64 位前缀，这对现代应用是必须的。wineboot --init会初始化目录结构、注册表、字体等基础组件。这个过程可能需要几分钟，期间会弹出几个安装 Mono 和 Gecko 的提示，建议都装上，很多程序依赖 .NET 或内嵌浏览器。

初始化完成后，检查一下前缀结构：

ls ~/.wine-madeira/drive_c/ # 应该看到 Program Files, windows, users 等目录

4.2 配置 FEX-Emu 与 Wine 的对接

这一步是让 FEX-Emu 和 Wine 协同工作的关键。FEX-Emu 提供了一个FEXInterpreter命令，可以直接运行 x86-64 的 Linux 程序。但 Wine 本身是 ARM64 原生的，它需要调用 x86-64 的 Windows 程序时，就要通过 FEX-Emu 来翻译。

配置方式是在 Wine 的环境变量里指定 FEX-Emu 的路径：

export FEX_INTERPRETER=/usr/bin/FEXInterpreter export FEX_ROOTFS=~/.fex-emu/RootFS/Ubuntu_22_04

然后在 Wine 的注册表里，把HKEY_LOCAL_MACHINE\Software\Wine\WineDbg下的Interpreter值设为 FEX-Emu 的路径。这样 Wine 启动 Windows 程序时，会自动通过 FEX-Emu 来执行。

提示：如果你的 Wine 是 ARM64 原生版本，它本身就能处理 ARM64 的 Windows 程序（虽然很少见）。对于 x86-64 的 Windows 程序，Wine 会调用 FEX-Emu 来翻译。这个链路是自动的，不需要手动干预。

4.3 安装并运行一个测试程序

找一个简单的 Windows 程序来测试，比如 Notepad++ 或者 7-Zip。下载安装包，然后用 Wine 运行：

wine ~/Downloads/npp.8.6.Installer.exe

安装过程应该和 Windows 上差不多。如果遇到界面乱码，检查一下字体配置。Wine 默认使用系统字体，如果系统没有安装中文字体，界面就会显示方块。安装fonts-wqy-microhei或fonts-noto-cjk可以解决。

安装完成后，在~/.wine-madeira/drive_c/Program Files/Notepad++/下找到notepad++.exe，运行：

wine "~/.wine-madeira/drive_c/Program Files/Notepad++/notepad++.exe"

如果程序能正常启动、菜单能点、文字能输入，说明基础环境已经通了。接下来可以测试图形性能，跑一个 3D 程序看看 DXMT 是否正常工作。

4.4 图形应用的调试与优化

跑 3D 应用的时候，建议开启 Wine 的调试输出，方便定位问题：

WINEDEBUG=+d3d11,+dxgi wine game.exe 2>&1 | tee wine_log.txt

日志里会显示 D3D 调用、着色器编译、纹理加载等信息。如果看到DXMT相关的输出，说明 DXMT 已经接管了渲染。如果看到wined3d的输出，说明 DXMT 没生效，需要检查 DLL 覆盖设置。

性能优化方面，几个实用的环境变量：

export DXVK_HUD=fps,frame-time export DXMT_FRAME_STATS=1 export MESA_GL_VERSION_OVERRIDE=4.6

DXVK_HUD会在屏幕上显示帧率和帧时间，方便实时监控。DXMT_FRAME_STATS输出 DXMT 内部的统计信息。MESA_GL_VERSION_OVERRIDE强制指定 OpenGL 版本，有些程序会检查这个。

5. 常见问题排查与避坑指南

5.1 Wine 中文乱码的根因与修复

Wine 中文乱码是最常见的问题，表现是界面上的中文变成方块或者问号。根本原因是 Wine 找不到合适的中文字体，或者字体映射配置不对。

修复方法分两步。第一步，安装中文字体：

sudo apt install fonts-wqy-microhei fonts-wqy-zenhei fonts-noto-cjk

第二步，在 Wine 注册表里配置字体替换。打开wine regedit，定位到HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\FontSubstitutes，添加以下键值：

这样 Wine 在请求这些字体时，会自动替换成文泉驿微米黑。如果还是乱码，检查一下~/.wine-madeira/drive_c/windows/Fonts/目录下有没有字体文件，没有的话从系统字体目录复制一份过去。

5.2 FEX-Emu 启动失败的排查思路

FEX-Emu 启动失败通常有几个原因。一是根文件系统没配置好，FEX_ROOTFS指向的目录不存在或者不完整。二是内核不支持某些特性，比如userfaultfd或者memfd_create。三是权限问题，FEX-Emu 需要访问/proc/sys/vm/mmap_min_addr等系统文件。

排查步骤：

# 检查根文件系统 ls $FEX_ROOTFS # 应该看到 bin, lib, usr 等目录 # 检查内核特性 cat /proc/sys/vm/mmap_min_addr # 应该是 0 或 65536 # 运行 FEX-Emu 的测试程序 FEXInterpreter /usr/bin/true # 如果没有输出且返回 0，说明基本功能正常

如果FEXInterpreter报错 "Failed to map rootfs"，检查根文件系统的权限，确保当前用户有读取权限。如果报错 "Unsupported instruction"，说明程序用到了 FEX-Emu 还没实现的指令，可以尝试更新到最新版本，或者在配置里启用X87ReducedPrecision来绕过一些浮点指令问题。

5.3 DXMT 渲染异常的典型场景

DXMT 渲染异常的表现包括黑屏、花屏、纹理错乱、帧率骤降。黑屏通常是因为着色器编译失败，检查日志里有没有 "Shader compilation failed" 的字样。花屏往往是纹理格式不匹配，尝试在配置里禁用EnableD3D12或者调整MaxFrameLatency。

帧率骤降可能是着色器缓存没生效。确认ShaderCache设为 true，并且ShaderCachePath指向的目录有写入权限。第一次运行程序时，着色器需要实时编译，帧率会偏低；第二次运行如果缓存生效，帧率应该明显回升。

还有一个容易被忽略的问题：DXMT 和某些 overlay 软件冲突。比如 MangoHud、Steam Overlay 这些，它们会 hook 图形 API，和 DXMT 的 hook 机制打架。如果遇到奇怪的渲染问题，先禁用所有 overlay 再试。

5.4 常见问题速查表

6. 性能调优与进阶技巧

6.1 FEX-Emu 的调优参数详解

FEX-Emu 的性能调优空间比想象中大。除了前面提到的TSOEnabled和Multiblock，还有几个参数值得细说。

SMCChecks控制自修改代码的检测策略。自修改代码是一些老程序（尤其是加壳的软件）常用的技术，FEX-Emu 需要检测代码是否被修改，以便重新翻译。MTrack模式用内存跟踪来实现，性能较好；Full模式做完整校验，兼容性最好但慢；None模式完全不检查，最快但可能出错。建议先用MTrack，遇到问题再切Full。

X87ReducedPrecision控制 x87 浮点运算的精度。x87 是 x86 的浮点协处理器指令集，现代程序很少用，但一些老游戏和科学计算软件还在用。开启这个选项会用较低的精度来模拟，速度更快，但可能导致计算结果有微小偏差。对精度敏感的场景不要开。

VectorTSOEnabled是专门针对 SIMD 指令的内存序优化。如果你的程序大量使用 SSE/AVX 做向量计算，开启这个能提升不少性能。但和TSOEnabled一样，可能会引入内存序相关的 bug，需要测试验证。

6.2 Wine 的注册表优化项

Wine 的注册表里藏着不少性能相关的开关。以下几个是我实测有效的：

HKEY_CURRENT_USER\Software\Wine\Direct3D下的MaxVersionGL设为0x40006，强制使用 OpenGL 4.6，能解锁一些现代图形特性。VideoMemorySize设为你的显存大小（单位 MB），帮助 Wine 更准确地管理显存。

HKEY_CURRENT_USER\Software\Wine\X11 Driver下的UseXVidMode设为N，禁用 X11 的视频模式切换，避免一些全屏切换的问题。GrabFullscreen设为Y，让全屏程序能正确抓取输入。

HKEY_CURRENT_USER\Control Panel\Desktop下的FontSmoothing设为2，启用字体抗锯齿，中文显示会舒服很多。FontSmoothingGamma设为1400，调整伽马值，让字体粗细更合适。

6.3 DXMT 的高级配置

DXMT 的配置文件支持不少高级选项。ShaderCache开启后，着色器编译结果会缓存到磁盘，二次启动快很多。ShaderCachePath建议指向一个 SSD 上的目录，机械硬盘的随机读写会拖慢缓存加载。

MaxFrameLatency控制 CPU 预渲染的帧数。设成 1 延迟最低但可能卡顿，设成 3 帧率最稳但延迟高。一般设 2 是平衡点。如果游戏有垂直同步选项，建议在游戏里开垂直同步，DXMT 的MaxFrameLatency设 1。

EnableD3D12控制是否启用 D3D12 支持。D3D12 的开销比 D3D11 低，但兼容性还在完善中。如果程序支持 D3D12 且运行稳定，开启能提升性能；如果遇到崩溃或渲染错误，关掉回退到 D3D11。

6.4 多前缀管理与软件隔离

随着你跑的 Windows 软件越来越多，依赖冲突会成为一个问题。解决办法是给每个软件或每类软件建独立的前缀。

# 办公软件前缀 export WINEPREFIX=~/.wine-office wineboot --init # 游戏前缀 export WINEPREFIX=~/.wine-games wineboot --init # 开发工具前缀 export WINEPREFIX=~/.wine-dev wineboot --init

每个前缀可以装不同的 Wine 组件、不同的 DLL 覆盖、不同的注册表配置。切换的时候只需要改WINEPREFIX环境变量。为了方便，可以写几个 shell 函数：

wine-office() { WINEPREFIX=~/.wine-office wine "$@" } wine-games() { WINEPREFIX=~/.wine-games \ DXVK_HUD=fps \ wine "$@" }

这样用wine-office notepad.exe就能在办公前缀里跑记事本，用wine-games game.exe就能在游戏前缀里跑游戏，互不干扰。

7. 实际使用中的经验与体会

跑通 Madeira 这套方案之后，我陆续在上面跑了不少软件，从办公套件到老游戏都有。有几个体会比较深。

第一是不要追求一次配好所有东西。兼容层这东西，配置是迭代出来的。先跑通一个最简单的程序，确认基础链路没问题，再逐步加复杂度。我见过不少人一上来就装一堆组件、改一堆注册表，结果出了问题根本不知道是哪一步导致的。

第二是日志是你的朋友。Wine 的WINEDEBUG环境变量能输出非常详细的调试信息，FEX-Emu 和 DXMT 也都有各自的日志。遇到问题先看日志，比盲目搜索效率高得多。日志里看不懂的术语，查一下官方文档或者社区讨论，慢慢就熟悉了。

第三是版本管理很重要。Wine、FEX-Emu、DXMT 都在快速迭代，新版本可能修复了旧问题，也可能引入新问题。建议保留一个已知稳定的版本组合，升级之前先备份前缀。我一般会在升级前把整个~/.wine-madeira目录打包，出问题能快速回滚。

第四是社区资源要善用。Wine 的 AppDB 数据库里有很多软件的兼容性报告和配置建议，FEX-Emu 和 DXMT 的 GitHub Issues 里也能找到不少解决方案。遇到问题先搜一下，大概率有人已经踩过同样的坑。

最后分享一个小技巧：如果你不确定某个程序能不能跑，先用winecfg里的 "Add Application" 功能，针对这个程序单独设置 Windows 版本和 DLL 覆盖，不要改全局配置。这样即使这个程序跑不起来，也不会影响其他已经配好的软件。