基于Wine、FEX-Emu与DXMT的跨平台Windows应用兼容方案

1. 从“Madeira”这个名字说起：它到底是什么

第一次看到“Madeira”这个词，很多人第一反应是葡萄牙那个盛产葡萄酒的海岛，或者是一块叫马德拉的蛋糕。但在折腾跨平台兼容层和模拟器这个圈子里，Madeira 指的是一套围绕 Wine 生态构建的、面向移动端和桌面端的 Windows 应用兼容方案。它要解决的问题很直接：让原本只能在 Windows 上跑的 x86-64 程序，在别的系统上也能跑起来，尤其是 iOS 这类封闭环境。

我接触这个方向是因为手头有一批老旧的 Windows 工具和游戏，想在移动设备上复用。传统做法要么是远程桌面，要么是找替代品，体验都不理想。Madeira 这类方案的核心价值在于，它把 Wine、FEX-Emu、DXMT 这几个组件串成了一条链路，让指令集翻译、系统调用转换、图形接口映射各司其职。适合谁来参考？如果你在做跨平台兼容、模拟器开发、或者单纯想把 Windows 程序搬到非 Windows 环境，这套思路值得完整走一遍。

需要先说明的是，本文涉及的组件都是开源社区长期维护的项目，具体版本和可用性会随时间变化，我下面讲的是基于常见实践的逻辑补全和实操思路，不是某个特定版本的官方文档。

2. 整体架构设计：为什么是 Wine + FEX-Emu + DXMT 这套组合

2.1 三个组件各自解决什么问题

要理解 Madeira 的设计，得先把这三个核心组件拆开看。它们不是随便凑在一起的，而是各自负责兼容链条上的一段。

Wine负责的是 Windows API 的转换。Windows 程序调用的是kernel32.dll、user32.dll这些系统库，Wine 用自己实现的同名库去接管这些调用，把它们翻译成宿主系统能理解的操作。它不模拟硬件，只翻译接口，所以效率比完整虚拟机高得多。但 Wine 有个前提：它假设程序的指令集和宿主一致。也就是说，x86 的 Wine 只能跑 x86 程序，ARM 上的 Wine 跑不了 x86 程序。

FEX-Emu就是来补这个缺口的。它是一个 x86-64 到 ARM64 的动态二进制翻译器。当你在 ARM 设备上跑 x86-64 程序时，FEX-Emu 把 x86-64 指令实时翻译成 ARM64 指令。它的特点是支持 JIT 编译和缓存，翻译过的代码块会被缓存下来，第二次执行就不用重新翻译。这比逐条解释执行快一个数量级。

DXMT处理的是图形接口。Windows 程序大量使用 Direct3D 渲染，而宿主系统可能是 Vulkan、Metal 或者 OpenGL。DXMT 的作用是把 D3D 调用翻译成宿主原生的图形 API。在 iOS 上，最终落地通常是 Metal，因为那是苹果生态里性能最好的图形接口。

三者串起来就是：程序发出 x86-64 指令和 Windows API 调用，FEX-Emu 翻译指令，Wine 翻译 API，DXMT 翻译图形调用，最终在宿主系统上执行。

2.2 为什么不用完整虚拟机

有人会问，既然要跑 Windows 程序，为什么不直接上虚拟机？答案在性能和资源占用上。完整虚拟机要模拟整套硬件，包括 CPU、内存控制器、磁盘控制器，开销巨大。在移动设备上，这种开销直接导致发热和续航崩溃。而 Wine 这套方案是“翻译层”而非“模拟层”，它直接复用宿主的内核和硬件，只在接口层面做转换，性能损耗小得多。

另一个原因是 iOS 的限制。iOS 不允许应用动态加载和执行外部代码，也不允许 JIT 编译任意代码。这意味着完整虚拟机在 iOS 上基本走不通。而 Wine 方案里，FEX-Emu 的 JIT 需要特殊处理才能合规，这也是为什么 iOS 上的实现往往比桌面端复杂。

2.3 方案选型的取舍

在实际搭建时，有几个关键取舍点。第一是翻译粒度：FEX-Emu 可以选择块级翻译还是函数级翻译。块级翻译吞吐高但内存占用大，函数级翻译内存友好但切换开销大。移动设备内存紧张，通常倾向函数级或者混合策略。

第二是图形后端选择。DXMT 支持多种后端，在 iOS 上 Metal 是唯一现实选择，因为 Vulkan 在 iOS 上没有原生支持，MoltenVK 又多一层转换。直接走 Metal 能省掉一次翻译。

第三是 Wine 的版本选择。Wine 有稳定版和开发版，开发版对新 API 支持更好但可能有回归。做兼容层通常选一个较新的稳定分支，然后针对目标程序打补丁。

提示：这三个组件的版本必须匹配。FEX-Emu 的 rootfs 里带的 Wine 版本、DXMT 的编译目标、宿主系统的图形驱动，任何一环版本错位都可能导致程序启动失败或者渲染异常。

3. 核心细节解析：从指令翻译到图形映射的关键环节

3.1 FEX-Emu 的指令翻译机制

FEX-Emu 的工作流程可以拆成几个阶段。程序启动时，FEX-Emu 加载 x86-64 的 ELF 或者 PE 文件，解析出代码段。执行到某段代码时，如果这段代码还没被翻译过，FEX-Emu 就把它送进翻译器，生成对应的 ARM64 代码，存进代码缓存，然后跳过去执行。下次再执行到同一段代码，直接从缓存取。

这里有个关键参数是代码缓存的大小。缓存太小，频繁翻译导致性能抖动；缓存太大，内存占用高。在移动设备上，我一般把缓存限制在 64MB 到 128MB 之间，具体看目标程序的大小。对于大型游戏，可能需要放宽到 256MB，但要监控内存压力。

另一个关键是自修改代码的处理。有些程序会在运行时修改自己的代码段，这在翻译器里是个难题，因为翻译后的代码和原始代码已经不一致了。FEX-Emu 的做法是检测写操作，如果发现代码段被修改，就失效对应的翻译缓存，重新翻译。这个检测有开销，所以对性能敏感的场景要留意。

3.2 Wine 的系统调用转换

Wine 的转换层比想象中复杂。Windows 的系统调用号和 Linux 或 iOS 的完全不同，Wine 需要维护一张映射表。比如 Windows 的NtCreateFile要映射到宿主系统的文件打开操作，NtReadFile映射到读操作。这张表覆盖了成千上万个 API。

在实际操作中，最容易出问题的是路径处理。Windows 用反斜杠和盘符，宿主系统用正斜杠和挂载点。Wine 会把C:\映射到某个目录，通常是~/.wine/drive_c。如果程序硬编码了路径，或者用了 Windows 特有的路径 API，就可能找不到文件。

还有一个坑是注册表。Windows 程序大量依赖注册表存储配置，Wine 用文本文件模拟注册表。如果程序写注册表的方式比较特殊，比如直接操作 hive 文件，Wine 可能处理不了。遇到这种情况，通常需要在 Wine 的注册表编辑器里手动补条目。

3.3 DXMT 的图形翻译路径

DXMT 把 D3D 调用翻译成 Metal 的过程，核心是资源映射和命令转换。D3D 的纹理、缓冲区、着色器，都要映射到 Metal 对应的资源类型。着色器是最麻烦的，D3D 用 HLSL，Metal 用 MSL，中间需要一次编译转换。

这个转换不是无损的。有些 HLSL 特性在 MSL 里没有直接对应，比如某些纹理采样模式、某些原子操作。DXMT 会用近似实现或者软件模拟来兜底，但性能和效果可能有差异。实测下来，大部分 D3D11 程序能跑，但 D3D12 的支持还在完善中。

注意：图形翻译对精度敏感。如果发现渲染出来颜色不对、纹理错位、或者某些特效消失，先检查 DXMT 的日志，看是不是某个着色器转换失败了。日志里通常会标明是哪个 shader 出的问题。

3.4 iOS 环境的特殊约束

iOS 和桌面 Linux 最大的区别在于沙盒和代码签名。Wine 需要加载 Windows 的 PE 文件，这在 iOS 上属于动态代码加载，默认是不允许的。要绕过这个限制，通常的做法是把 Wine 和 FEX-Emu 编译成静态库，和主应用一起签名，然后通过解释执行或者受限的 JIT 来跑。

iOS 的 JIT 限制更麻烦。从 iOS 14 开始，应用要使用 JIT 必须申请特定的 entitlement，而且这个 entitlement 只对特定类型的应用开放。对于兼容层这类应用，通常只能走解释执行，性能损失很大。这也是为什么 iOS 上的 Windows 兼容方案体验普遍不如桌面端。

另一个约束是内存。iOS 对单个应用的内存占用有硬限制，超过就会被系统杀掉。FEX-Emu 的代码缓存、Wine 的堆、DXMT 的图形资源，加起来很容易触顶。实际调优时，要严格控制缓存大小，及时释放不用的资源。

4. 实操过程：从零搭建一套可运行的兼容环境

4.1 环境准备与依赖安装

先说明，下面的步骤是基于桌面 Linux 环境的，因为 iOS 端的搭建涉及签名和打包，流程差异较大，我会在最后单独提。桌面环境选 Ubuntu 22.04 或者 Debian 12 都行，内核版本不要太老，否则 FEX-Emu 的某些特性用不了。

第一步是装基础依赖。编译 FEX-Emu 需要 CMake、Ninja、Clang，还有一堆开发库。Wine 需要 flex、bison、pkg-config。DXMT 需要 Vulkan SDK 和 Metal 的着色器编译器（如果在 macOS 上编译）。

sudo apt update sudo apt install -y cmake ninja-build clang lld flex bison pkg-config \ libssl-dev libgnutls28-dev libvulkan-dev libgl1-mesa-dev \ libx11-dev libxext-dev libxrandr-dev libxi-dev

这里有个细节：Clang 的版本要够新，FEX-Emu 用了一些较新的 C++ 特性。Ubuntu 22.04 自带的 Clang 14 基本够用，但如果编译报错说某个特性不支持，就升级到 Clang 16 或更高。

4.2 编译 FEX-Emu

FEX-Emu 的编译分两部分：宿主工具和 guest rootfs。宿主工具是跑在 ARM64 上的翻译器，guest rootfs 是给 x86-64 程序用的根文件系统。

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 \ -DCMAKE_C_COMPILER=clang \ -DCMAKE_CXX_COMPILER=clang++ \ -DENABLE_ASSERTIONS=OFF \ -DBUILD_TESTS=OFF \ .. ninja

编译参数里，ENABLE_ASSERTIONS=OFF是为了性能，断言在 release 版本里没必要开。BUILD_TESTS=OFF是省时间，除非你要改 FEX-Emu 的代码，否则不用编译测试。

编译完成后，用FEXRootFSFetcher下载 rootfs。这个工具会从社区维护的镜像源拉取一个预配置好的根文件系统，里面包含了 Wine 和基本的 Windows 运行库。

./Bin/FEXRootFSFetcher

选一个较新的 rootfs 版本，比如 Ubuntu 22.04 的 x86-64 镜像。下载完成后，rootfs 会放在~/.fex-emu/RootFS/下面。

4.3 配置 Wine 和 DXMT

rootfs 里自带的 Wine 可能版本较老，如果要跑较新的程序，建议自己编译一份。Wine 的编译比较耗时，但流程成熟。

git clone https://github.com/wine-mirror/wine.git cd wine ./configure --enable-win64 --prefix=/opt/wine-madeira make -j$(nproc) sudo make install

编译 Wine 时，--enable-win64是必须的，因为我们要跑 64 位程序。如果还要跑 32 位程序，需要再编译一份 32 位的，然后用 WoW64 模式组合。不过现在大部分程序都是 64 位了，可以先只编 64 位。

DXMT 的编译需要 Vulkan 和 Metal 的头文件。在 Linux 上编译时，Metal 部分会被跳过，只编译 Vulkan 后端。如果目标是 iOS，需要在 macOS 上用 Xcode 编译，链接 Metal 框架。

git clone https://github.com/3Shain/dxmt.git cd dxmt mkdir build && cd build cmake -DCMAKE_BUILD_TYPE=Release .. make -j$(nproc)

编译出来的dxmt.dll和相关的.so文件，要放到 Wine 的system32和syswow64目录里，替换掉 Wine 自带的d3d11.dll和dxgi.dll。

4.4 启动第一个 Windows 程序

配置完成后，用 FEX-Emu 启动一个简单的 Windows 程序试试。先准备一个小的测试程序，比如 Windows 自带的notepad.exe，或者一个简单的 Win32 程序。

export FEX_ROOTFS=~/.fex-emu/RootFS/Ubuntu_22_04 export WINEPREFIX=~/.wine-madeira FEXBash -c "wine notepad.exe"

如果一切正常，应该能看到记事本窗口弹出来。如果报错，先看 FEX-Emu 的日志，通常是 rootfs 路径不对或者 Wine 的依赖没装全。

提示：第一次启动 Wine 会初始化 prefix，这个过程比较慢，可能要几分钟。初始化完成后，后续启动就快了。如果卡在初始化阶段，检查磁盘空间和权限。

4.5 iOS 端的打包思路

iOS 端的流程和桌面端差别很大。核心思路是把 FEX-Emu、Wine、DXMT 都编译成 iOS 能加载的静态库或者动态框架，然后写一个宿主应用来调用它们。

第一步是用 Xcode 创建一个 iOS 应用工程，把编译好的库链接进去。FEX-Emu 的 JIT 部分在 iOS 上不能用，所以要改成解释执行模式。Wine 的 PE 加载器也要改，改成从应用沙盒里读文件，而不是从文件系统任意位置读。

第二步是处理代码签名。所有要执行的代码都必须在签名范围内，所以 Windows 程序不能动态加载，只能作为资源打包进应用，或者从网络下载后存到沙盒里再解释执行。

第三步是图形接口。DXMT 在 iOS 上要链接 Metal，着色器转换要用 Metal 的编译器。这部分在 macOS 上用 Xcode 编译时自动处理，但要注意 Metal 的版本兼容性。

打包完成后，通过 TestFlight 或者企业分发安装到设备上。首次启动时，需要在设置里信任开发者证书，否则应用无法运行。

5. 常见问题与排查技巧实录

5.1 启动失败类问题

启动失败是最常见的问题，表现是程序闪退或者卡在启动画面。排查思路是从日志入手，FEX-Emu 和 Wine 都会输出详细的日志。

这里重点说下 DLL 缺失的问题。Windows 程序依赖大量的运行库，Wine 自带的只是一部分。遇到缺 DLL，先用WINEDEBUG=+loaddll启动，看是哪个 DLL 加载失败，然后用winetricks装对应的包。winetricks是个脚本工具，能自动下载和安装常见的 Windows 运行库。

5.2 图形渲染异常

图形问题比启动问题更难排查，因为涉及翻译链路的多个环节。常见表现有黑屏、花屏、纹理错位、帧率异常。

黑屏通常意味着 D3D 设备创建失败，或者交换链没建立起来。先确认 DXMT 是否正确替换了 Wine 的d3d11.dll，然后看日志里有没有Failed to create device之类的错误。如果有，可能是 Metal 设备不支持请求的特性，比如某些 D3D11 的特性级别在 Metal 上没有对应。

花屏和纹理错位往往是着色器转换的问题。DXMT 在转换 HLSL 到 MSL 时，如果遇到不支持的指令，会用近似实现，可能导致渲染结果偏差。这种情况只能等 DXMT 更新，或者手动改着色器。实测下来，大部分 D3D11 游戏能正常渲染，但一些用了高级特性的游戏会有问题。

帧率异常要分情况。如果帧率低但稳定，可能是翻译开销大，试试调大 FEX-Emu 的代码缓存。如果帧率波动大，可能是内存压力导致频繁 GC，检查宿主系统的内存占用。

5.3 中文乱码问题

Wine 的中文乱码是个老问题，表现是界面上的中文显示成方块或者问号。根本原因是字体缺失或者编码不匹配。

解决方法是给 Wine 装中文字体。把 Windows 的simsun.ttc、msyh.ttc复制到 Wine 的Fonts目录，然后在注册表里设置字体替换。

cp /path/to/simsun.ttc ~/.wine-madeira/drive_c/windows/Fonts/ wine reg add "HKCU\Software\Wine\Fonts\Replacements" /v "SimSun" /d "SimSun" /f

如果还是乱码，检查程序的编码设置。有些程序默认用 GBK，而 Wine 默认用 UTF-8，需要在程序的配置文件里改编码，或者在 Wine 的 locale 设置里指定zh_CN.GBK。

注意：字体文件有版权，不要随意分发。自己用的话，从已有的 Windows 系统里复制就行。

5.4 性能调优经验

性能调优是个持续的过程，没有一劳永逸的方案。我总结了几条实测有效的经验。

第一，FEX-Emu 的代码缓存要按程序大小调。小工具 64MB 够用，大型游戏可能要 256MB 甚至更多。但缓存不是越大越好，超过一定值后，缓存查找的开销会抵消收益。

第二，Wine 的WINEDEBUG要关掉。调试日志会严重拖慢性能，生产环境一定要设WINEDEBUG=-all。

第三，DXMT 的着色器缓存要开启。第一次运行程序时，着色器转换比较慢，但转换结果会缓存下来，后续启动就快了。缓存目录默认在~/.cache/dxmt，确保这个目录可写。

第四，如果宿主系统支持，开启大页内存。FEX-Emu 的代码缓存和 Wine 的堆用大页内存能减少 TLB miss，提升性能。在 Linux 上用hugetlbfs配置。

5.5 常见问题速查表

6. 这套方案的边界与后续扩展

Madeira 这套组合能覆盖的场景其实有明确边界。它擅长的是那些依赖 Win32 API 和 D3D11 的传统桌面程序，尤其是 2015 年之前的老软件和老游戏。对于依赖 .NET 新版本、UWP、或者 D3D12 的程序，支持还不完善。这不是 Madeira 独有的问题，整个 Wine 生态都面临这个边界。

后续扩展有几个方向值得关注。一是 D3D12 的支持，DXMT 在这块还在迭代，等成熟后能覆盖更多新游戏。二是 ARM64 原生 Windows 程序的兼容，随着 ARM 设备普及，这类程序会越来越多，Wine 和 FEX-Emu 都需要适配。三是 iOS 端的合规化，如果苹果开放更多 JIT 权限，iOS 上的体验会有质的提升。

我在实际搭建过程中最大的体会是，这套方案的难点不在单个组件的编译，而在组件之间的衔接。版本匹配、路径配置、权限设置，任何一环出问题都会导致整体跑不起来。建议第一次搭建时，先用最简单的程序验证链路，跑通后再逐步加复杂度。另外，社区的力量很重要，遇到问题先搜 issue 和讨论区，大概率有人踩过同样的坑。