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

第一次接触 Madeira 这个项目，是在给一台老旧的 ThinkPad 装完某个国产 Linux 发行版之后。那台机器配置不高，但日常办公、写代码、看文档都够用，唯独有几个 Windows 下用惯了的工具找不到替代品。当时试过虚拟机方案，资源占用太高，风扇呼呼转；也试过一些商业兼容软件，授权费用不便宜，而且对老硬件的支持并不理想。后来在社区里看到有人提到 Madeira，说是把 Wine 和 FEX-Emu 这两套东西整合到了一起，专门解决 x86-64 Windows 应用在 ARM 架构 Linux 上的运行问题，这才算找到了方向。

Madeira 这个名字本身挺有意思，它不是一个从零开始造轮子的项目，而是一个“胶水层”或者说“整合方案”。它的核心思路很直接：底层用 FEX-Emu 做指令集翻译，把 x86-64 的机器码转换成 ARM64 能执行的指令；中间用 Wine 提供 Windows API 的兼容实现；上层再通过 DXMT 把 Direct3D 调用转译成 Metal 或者 Vulkan，让图形应用和游戏能跑起来。这三者单独拿出来都不算新东西，但把它们串成一条可用的链路，并且针对特定场景做调优，这就是 Madeira 的价值所在。

适合关注这个项目的人其实挺明确的。一类是使用 ARM 架构设备（比如某些国产笔记本、开发板、甚至手机平板）但又有 Windows 应用刚需的用户；另一类是对系统兼容层技术感兴趣，想研究指令翻译、API 转译、图形栈适配的开发者；还有一类就是像我这样，手头有老设备不想扔，想榨干最后一点剩余价值的人。不管你属于哪一类，理解 Madeira 的架构和实操细节，都能帮你少走很多弯路。

2. 核心架构拆解：FEX-Emu、Wine、DXMT 各自扮演什么角色

2.1 FEX-Emu：把 x86-64 指令“翻译”成 ARM64 能听懂的话

FEX-Emu 是整个链路里最底层的一环，它解决的是 CPU 指令集不兼容的问题。ARM 设备跑的是 AArch64 指令，而 Windows 应用编译出来的是 x86-64 指令，两者根本不在一个频道上。FEX-Emu 的做法是动态二进制翻译，也就是在程序运行时，把 x86-64 指令块实时转换成 ARM64 指令块，然后交给 CPU 执行。这个过程听起来开销很大，但 FEX-Emu 做了大量优化，比如指令块缓存、寄存器映射、条件码优化等等，实际用下来，对于办公类应用和轻度游戏，性能损失在可接受范围内。

这里有个关键点需要说清楚：FEX-Emu 不是模拟器，它不模拟硬件环境，而是做指令翻译。模拟器比如 QEMU 那种，会完整模拟一套 x86 硬件，包括 CPU、内存控制器、外设等等，开销巨大。FEX-Emu 只翻译指令，系统调用和硬件访问还是走原生 Linux 内核，所以效率高很多。你可以把它理解成一个“同声传译”，而不是“重新演一遍”。

在实际配置中，FEX-Emu 有几个参数值得关注。FEX_APP_CONFIG环境变量可以指定配置文件路径，里面能调整 JIT 缓存大小、线程数、日志级别等。对于内存较小的设备，建议把 JIT 缓存调小一点，比如 64MB 到 128MB，避免占用过多内存导致系统卡顿。另外FEX_SILENTLOG可以关闭冗余日志输出，提升一点性能。这些细节在官方文档里不一定写得很显眼，但实测下来对体验影响不小。

2.2 Wine：提供 Windows API 的“翻译字典”

Wine 大家应该都不陌生，它的全称是“Wine Is Not an Emulator”，虽然名字里有 Emulator，但它确实不是模拟器。Wine 实现了一套 Windows API 的兼容层，把 Windows 程序调用的CreateWindow、MessageBox、RegOpenKey这些函数，映射到 Linux 对应的 X11、Wayland、文件系统、注册表模拟等机制上。程序以为自己是在跟 Windows 内核打交道，实际上是在跟 Wine 的库函数打交道。

在 Madeira 的架构里，Wine 跑在 FEX-Emu 之上。也就是说，Windows 应用的 x86-64 指令先被 FEX-Emu 翻译成 ARM64 指令，然后这些指令里对 Windows API 的调用，再被 Wine 拦截并转换成 Linux 系统调用。这个链路是：Windows 应用 -> FEX-Emu 指令翻译 -> Wine API 转换 -> Linux 内核。每一层都有开销，但每一层也都有优化空间。

Wine 的配置是个细活。WINEPREFIX环境变量决定了 Wine 的“虚拟 C 盘”放在哪里，建议每个应用单独一个 prefix，避免不同应用之间的注册表和 DLL 冲突。WINEARCH一般设成win64，因为现在大多数 Windows 应用都是 64 位的。还有WINEDLLOVERRIDES可以用来禁用或替换某些 DLL，比如mscoree=d可以禁用 .NET 相关的 DLL，避免一些安装程序卡死。这些参数在调试阶段非常有用。

2.3 DXMT：把 Direct3D 调用转译成 Metal 或 Vulkan

DXMT 是 Madeira 里负责图形的那一环。Windows 应用和游戏通常调用 Direct3D 来渲染画面，而 Linux 上主流图形 API 是 Vulkan 和 OpenGL，苹果生态里是 Metal。DXMT 的作用就是把 D3D 调用转换成这些原生 API 能理解的命令。它跟 DXVK 和 VKD3D 是同类东西，但 DXMT 更侧重于 Metal 后端，这在某些 ARM 设备上更有优势，因为那些设备的图形驱动对 Metal 的支持往往比 Vulkan 更成熟。

DXMT 的配置主要在 Wine 的注册表里。你可以通过wine regedit添加键值来调整 DXMT 的行为，比如HKEY_CURRENT_USER\Software\Wine\DXMT下面可以设置d3d11的maxFeatureLevel，强制指定 D3D 特性等级。有些老游戏只支持 D3D9，那就需要确保 DXMT 的 D3D9 转译路径是启用的。另外DXMT_SHADER_CACHE环境变量可以指定着色器缓存目录，第一次运行游戏时会编译着色器，之后就能直接加载缓存，启动速度会快很多。

注意：DXMT 的版本要和 Wine 版本匹配，版本错配可能导致图形初始化失败，表现为黑屏或者闪退。建议从 Madeira 的官方仓库统一安装，不要自己混搭不同来源的包。

3. 实操部署：从零搭建 Madeira 运行环境

3.1 系统准备与依赖安装

在开始之前，先确认你的系统架构是 ARM64。可以用uname -m查看，输出aarch64就对了。如果是 x86-64 系统，其实不需要 FEX-Emu，直接装 Wine 就行，Madeira 的意义就不大了。确认架构之后，更新系统包管理器缓存，然后安装基础依赖。以 Debian 系为例，需要装build-essential、cmake、ninja-build、python3、pkg-config、libgl1-mesa-dev、libvulkan-dev、libsdl2-dev、libgnutls28-dev这些。不同发行版包名可能略有差异，但大体差不多。

接下来是获取 Madeira 的源码或预编译包。如果追求省事，可以直接用社区维护的预编译包，但要注意版本和系统匹配。如果追求可控性，就从源码编译。源码编译的大致流程是：先编译 FEX-Emu，再编译 Wine（需要打上 Madeira 的补丁），最后编译 DXMT。每一步都要确保依赖完整，否则会在链接阶段报一堆找不到符号的错误。编译 FEX-Emu 时，cmake配置阶段可以加上-DENABLE_JIT=ON和-DENABLE_CACHE=ON，这两个选项对性能影响很大。

提示：编译过程比较吃内存，建议至少 8GB 内存，否则链接阶段容易 OOM。如果内存不够，可以临时增加 swap 分区，或者用-j2限制并行编译任务数。

3.2 Wine prefix 的创建与调优

装好之后，第一件事是创建 Wine prefix。命令是WINEPREFIX=~/.wine-madeira WINEARCH=win64 wineboot -u。这个命令会初始化一个 64 位的 Wine 环境，并安装一些基础组件。初始化完成后，可以用winecfg打开配置界面，调整 Windows 版本、驱动器映射、库覆盖等。建议把 Windows 版本设成 Windows 10，兼容性最好。

prefix 创建好之后，有几个调优项值得做。第一，关闭不必要的 Wine 服务，比如winebrowser、winefile，这些在后台跑着占资源。可以在winecfg的“服务”标签页里禁用。第二，调整注册表里的DirectInput和DirectSound设置，对于游戏应用，把DirectInput的emulate模式打开，可以兼容一些老游戏的手柄输入。第三，如果应用需要 .NET，可以用winetricks安装dotnet48或dotnet6，但要注意 .NET 在 FEX-Emu 下的性能损耗比较大，能不用就不用。

3.3 安装 Windows 应用与常见问题处理

安装 Windows 应用一般用wine setup.exe或者wine msiexec /i package.msi。安装过程中如果遇到乱码，通常是字体缺失或者编码设置不对。解决办法是安装winetricks corefonts和winetricks cjkfonts，把常用中文字体装进去。如果安装程序界面显示不全，可以试试winecfg里把屏幕分辨率调低一点，或者用虚拟桌面模式运行。

安装完成后，运行应用时可能会遇到 DLL 缺失的提示。这时候可以用winetricks安装对应的运行库，比如vcrun2019、dotnet48、xna40等。但要注意，不是所有运行库都能在 FEX-Emu 下正常工作，有些会直接崩溃。遇到这种情况，可以试试用WINEDLLOVERRIDES禁用相关 DLL，或者找绿色版应用，避免安装过程。

注意：在 ARM 设备上跑 Windows 应用，性能瓶颈往往不在 CPU 翻译，而在图形驱动和内存带宽。如果应用界面卡顿，先检查是不是 DXMT 没有正确启用，或者着色器缓存没有生效。

4. 性能调优与兼容性排查实战

4.1 性能调优：从 JIT 缓存到着色器编译

性能调优是个系统工程，不能指望改一个参数就起飞。先说 FEX-Emu 这边，JIT 缓存大小对性能影响很明显。缓存太小，指令块频繁被淘汰，翻译开销就上去了；缓存太大，内存占用高，可能触发系统 swap，反而更慢。我的经验是，4GB 内存的设备设 64MB，8GB 设 128MB，16GB 以上设 256MB，这个范围比较稳妥。另外FEX_TSO_ENABLED这个环境变量控制是否启用 x86 的内存一致性模型模拟，对于多线程应用，开启它能避免一些诡异的同步问题，但会带来性能损失。如果应用对内存一致性要求不高，可以关掉试试。

Wine 这边的调优主要是减少不必要的系统调用和 DLL 加载。可以用WINEDEBUG=-all关闭所有调试输出，减少日志开销。WINEDLLOVERRIDES里把不用的 DLL 设成d（disabled），能加快启动速度。还有winecfg里的“图形”标签页，把“允许窗口管理器装饰窗口”关掉，能减少一点合成开销。

DXMT 这边的调优重点是着色器缓存。第一次运行应用时，DXMT 会编译着色器，这个过程可能很慢，但编译结果会缓存下来。确保DXMT_SHADER_CACHE指向一个可写目录，并且不要频繁清理这个目录。如果应用更新了图形内容，缓存可能会失效，需要重新编译，这是正常现象。

4.2 兼容性排查：常见错误与解决思路

兼容性问题千奇百怪，但有一些是高频出现的。下面这个表格整理了我遇到过的一些典型问题，以及对应的排查思路和解决办法。

排查的时候，日志是最好的朋友。WINEDEBUG可以组合多个通道，比如WINEDEBUG=+loaddll,+d3d,+dxmt，这样能同时看到 DLL 加载、D3D 调用和 DXMT 转译的详细信息。但日志量会很大，建议重定向到文件再慢慢看。另外FEX_LOG_LEVEL可以控制 FEX-Emu 的日志级别，调试阶段设成info或debug，生产环境设成error或silent。

4.3 实操心得：那些文档里不会写的坑

第一个坑是文件系统大小写敏感。Linux 文件系统默认区分大小写，而 Windows 应用经常不区分。Wine 默认会做大小写不敏感映射，但有些应用会绕过 Wine 的映射直接访问文件，导致找不到文件。解决办法是在winecfg的“驱动器”标签页里，把驱动器类型设成“自动检测”，或者手动指定为“CD-ROM”来强制大小写不敏感。

第二个坑是线程调度。FEX-Emu 翻译后的代码在 ARM 上跑，线程调度策略跟原生 x86 不一样。有些应用对线程优先级很敏感，在 ARM 上可能表现异常。可以试试用taskset把应用绑定到特定核心，或者用nice调整优先级。我遇到过某个应用在默认调度下卡顿，绑定到大核之后流畅很多。

第三个坑是内存对齐。x86 和 ARM 对内存对齐的要求不同，有些应用在 x86 上能跑，在 ARM 上就段错误。这种问题很难排查，通常需要看 FEX-Emu 的日志里有没有对齐相关的警告。如果确认是对齐问题，可以试试在 FEX-Emu 配置里开启对齐检查模拟，但性能会下降。

提示：遇到诡异问题时，先试试更新 FEX-Emu 和 Wine 到最新版本。很多兼容性问题在新版本里已经修复了，没必要自己硬啃。

5. 应用场景与扩展玩法

5.1 办公与生产力工具的运行体验

办公类应用是 Madeira 最典型的应用场景之一。我实测过几个常用的办公软件，整体体验可以用“能用”来形容，但离“好用”还有距离。文字处理类应用启动速度尚可，打字延迟不明显，但复杂排版和大型文档滚动时会有轻微卡顿。表格类应用在公式计算密集的场景下，CPU 占用会飙升，因为 FEX-Emu 翻译浮点运算指令的开销比较大。演示文稿类应用在播放动画时，如果 DXMT 没有正确启用，会掉帧严重。

对于生产力工具，我的建议是尽量找 Linux 原生替代品。如果实在找不到，再用 Madeira 跑 Windows 版。跑的时候，把不用的功能关掉，比如自动更新、云同步、插件市场，这些都会在后台消耗资源。另外把应用的缓存目录映射到 tmpfs 上，能减少磁盘 I/O，提升响应速度。

5.2 游戏与图形应用的兼容性现状

游戏是另一个热门场景，但也是挑战最大的场景。轻量级 2D 游戏和老款 3D 游戏，在 Madeira 下通常能跑，帧率取决于设备性能。我在一台 ARM 开发板上试过几个经典游戏，DXMT 转译 D3D9 的效果不错，基本能稳定 30 帧。但 D3D11 和 D3D12 的游戏就吃力很多，着色器编译慢，复杂场景掉帧明显。

图形应用方面，一些基于 OpenGL 的老版本软件能跑，但基于 Vulkan 的新版本往往有问题，因为 DXMT 对 Vulkan 后端的支持还在完善中。如果你主要用图形应用，建议优先考虑 Linux 原生版本，或者用 Web 版替代。Madeira 跑图形应用，更适合作为临时方案，而不是长期主力。

5.3 在 ARM 设备上的部署注意事项

ARM 设备种类繁多，从单板计算机到笔记本到平板，硬件差异很大。部署 Madeira 之前，先确认几个关键点。第一，内核版本要足够新，建议 5.15 以上，否则 FEX-Emu 的一些特性可能不支持。第二，图形驱动要完整，特别是 Vulkan 驱动，很多 ARM 设备的 Vulkan 驱动不完整，会导致 DXMT 初始化失败。第三，内存要足够，建议至少 4GB，2GB 的设备跑起来会很吃力。

另外，ARM 设备的散热往往不如 x86 设备，长时间跑 Windows 应用会导致降频。可以试试限制 CPU 频率，或者加个散热底座。电源管理也很重要，有些设备在电池模式下会限制性能，插电才能跑满。这些细节看起来不起眼，但实际体验差别很大。

6. 常见问题速查与避坑指南

6.1 安装与配置阶段的高频问题

安装阶段最常见的问题是依赖缺失。编译 FEX-Emu 时如果提示找不到libcap或libglib，说明对应的开发包没装。不同发行版的包名不一样，Debian 系是libcap-dev、libglib2.0-dev，Red Hat 系是libcap-devel、glib2-devel。建议先把官方文档里的依赖列表过一遍，确保一个不漏。

配置阶段最常见的问题是 prefix 冲突。如果你之前装过 Wine，~/.wine目录可能已经存在，直接覆盖会导致旧应用出问题。建议给 Madeira 单独建一个 prefix，比如~/.wine-madeira，并且用环境变量WINEPREFIX显式指定。另外WINEARCH一旦设定就不要改，改了之后 prefix 里的 32 位和 64 位组件会混乱。

6.2 运行阶段的性能与稳定性问题

运行阶段的问题主要集中在性能和稳定性上。性能问题前面已经说了不少，这里补充一点：如果应用突然变慢，先检查是不是后台有 Wine 的wineserver进程卡住了。可以用wineserver -k强制结束，然后重新启动应用。稳定性问题方面，如果应用频繁崩溃，可以试试关闭 FEX-Emu 的 JIT 优化，用解释模式跑，虽然慢但稳定。解释模式通过FEX_INTERPRETER=1环境变量启用。

还有一个容易被忽略的问题是时区和区域设置。Wine 默认会读取系统时区，但有些应用对时区敏感，如果系统时区设置不对，应用可能显示错误的时间或者直接崩溃。可以在winecfg里手动指定时区，或者在环境变量里设置TZ。区域设置同理，LANG和LC_ALL要设成应用支持的语言，否则界面可能乱码。

6.3 独家避坑技巧汇总

第一个技巧是善用快照。在安装大型应用之前，先给 Wine prefix 打个快照，比如用tar打包整个目录。如果安装失败或者装完出问题，直接恢复快照，比卸载重装快得多。这个习惯能省下大量时间。

第二个技巧是分离配置。不同的应用用不同的 prefix，不要混在一起。虽然这样占磁盘空间，但能避免 DLL 冲突和注册表污染。如果磁盘紧张，可以用wineboot -u创建最小 prefix，然后按需安装组件。

第三个技巧是关注社区。Madeira 的社区虽然不大，但活跃度还可以。遇到问题先搜社区历史帖，大概率有人遇到过类似情况。另外 FEX-Emu 和 Wine 的官方仓库里，issue 区也有很多有价值的讨论，值得花时间翻一翻。

注意：不要随意混用不同来源的 Wine 和 DXMT 包。版本不匹配是很多诡异问题的根源，统一从 Madeira 官方渠道获取，能避免大量麻烦。

7. 个人实操体会与后续折腾方向

折腾 Madeira 这段时间，最大的感受是：兼容层技术已经比几年前成熟太多了，但离“无感”还有距离。FEX-Emu 的指令翻译效率超出我预期，Wine 的 API 覆盖度也够用，DXMT 的图形转译在简单场景下表现不错。但三者叠加之后，调试复杂度是指数级上升的。一个问题可能出在 FEX-Emu 的翻译层，也可能出在 Wine 的 API 层，还可能出在 DXMT 的图形层，排查起来需要耐心和系统性的方法。

我个人的经验是，先把 FEX-Emu 单独调通，确保它能正确翻译简单的 x86-64 程序；然后再加 Wine，确保 Windows API 调用正常；最后再加 DXMT，确保图形能渲染。分层调试比一上来就全链路跑要高效得多。另外日志一定要开，虽然日志量大，但关键时刻能救命。

后续我打算试试把 Madeira 跑在更小的设备上，比如树莓派或者类似的单板计算机，看看极限在哪里。另外也想研究一下 FEX-Emu 的 JIT 优化策略，看看有没有办法针对特定应用做定制优化。这个方向坑肯定不少，但折腾本身就是乐趣所在。如果你也在玩类似的东西，欢迎交流踩坑经验，少走弯路总是好的。