尧图网页设计 
1. 从Madeira这个名字说起一个跨平台兼容层的真实需求第一次看到Madeira这个项目名很多人会以为是某个度假岛屿或者葡萄酒品牌——毕竟热搜词里就挂着Wine。但如果你是一个长期在Linux桌面和移动端之间来回折腾的开发者看到Wine、FEX-Emu、DXMT、x86-64这几个词凑在一起基本就能猜到这背后想解决的是什么问题了在非x86架构或者非Windows环境下把原本为Windows/x86-64编译的应用程序跑起来。Madeira这个项目从关键词组合来看核心定位是一个面向多架构的Windows应用兼容运行环境。它不是一个简单的Wine封装而是把Wine、FEX-Emux86-64指令翻译层、DXMTDirectX到Metal的翻译层这几块拼图组合在一起目标场景很可能是在ARM架构设备比如Apple Silicon Mac、ARM Linux设备上运行Windows x86-64应用和游戏。为什么这件事值得单独做一个项目因为现成的方案各有各的短板。纯Wine只能解决API层面的兼容解决不了指令集架构差异纯FEX-Emu能翻译指令但不管图形APIDXMT能处理DirectX但需要前面两层都跑通。把这三者串起来还要处理它们之间的边界问题——比如Wine的PE加载器和FEX的翻译缓存怎么配合、DXMT的Metal后端在Wine的窗口系统下怎么初始化——这才是Madeira真正要啃的硬骨头。这篇文章适合谁看如果你正在做Linux桌面兼容层、ARM平台游戏移植、或者单纯想搞清楚一个Windows exe在ARM设备上到底经历了什么才能跑起来那接下来的内容会对你有用。我会从架构拆解、环境搭建、实际跑通、踩坑排查几个角度把这个项目的核心逻辑讲透。2. Madeira的三层架构Wine、FEX-Emu、DXMT各自负责什么2.1 Wine层API翻译与PE加载Wine在Madeira里承担的是最上层的Windows API翻译工作。当你在Linux上双击一个.exe文件Wine要做的事情包括解析PE格式、加载依赖的DLL、把Windows系统调用翻译成POSIX调用、维护注册表和文件系统的虚拟映射。但这里有个容易被忽略的细节Wine本身并不关心底层是x86还是ARM。它只负责Windows API到Linux API的翻译。如果底层CPU是x86-64那Wine编译出来的代码可以直接跑如果底层是ARM64Wine的代码本身需要被编译成ARM64而它加载的Windows PE文件仍然是x86-64的——这中间的指令集鸿沟就得靠FEX-Emu来填。在Madeira的语境下Wine大概率是以WoW64模式运行的。传统WoW64是Windows上32位跑在64位上的机制但Wine的WoW64是另一回事它允许一个64位的Wine进程加载32位的PE模块。在ARM64主机上这意味着Wine的PE加载器需要同时处理x86-64和x86两种PE格式而这两种格式的代码都需要FEX来翻译。实操提示如果你自己编译Wine记得开启--enable-archsi386,x86_64否则在ARM主机上加载32位Windows程序会直接报cannot execute binary file。2.2 FEX-Emu层x86-64到ARM64的指令翻译FEX-Emu是整个链条里最重的一层。它的工作是把x86-64指令动态翻译成ARM64指令。和QEMU那种全系统模拟不同FEX-Emu是用户态翻译——它不模拟整个CPU和硬件只翻译用户空间的指令流系统调用直接透传给宿主Linux内核。FEX-Emu的核心机制是块翻译加缓存。它会把x86-64代码按基本块切分每个基本块翻译成ARM64后缓存起来下次执行到同一块代码时直接走缓存。这个设计对游戏场景特别重要——游戏主循环里的热点代码会被反复执行缓存命中率高的时候翻译开销可以降到很低。但FEX-Emu有个关键限制它要求宿主内核支持48位地址空间。因为x86-64的虚拟地址布局和ARM64不完全一样FEX需要在宿主地址空间里模拟x86-64的地址映射。如果你的内核配置不对FEX启动时会直接报48-bit VA not supported然后退出。# 检查内核是否支持48位VA cat /proc/cpuinfo | grep -i address sizes # 输出里如果有48 bits virtual就说明支持2.3 DXMT层DirectX到Metal的翻译DXMT是Madeira里负责图形的那一环。它的作用是把Windows游戏调用的DirectX 11/12 API翻译成Apple的Metal API。为什么是Metal而不是Vulkan因为Madeira的目标平台很可能包括Apple Silicon Mac而macOS上Vulkan支持一直是个痛点Metal才是原生选择。DXMT的工作方式和DXVK类似但目标API不同。它拦截游戏对d3d11.dll、dxgi.dll的调用把着色器编译成Metal Shading Language把资源绑定映射到Metal的heap和buffer。这里最麻烦的是着色器编译——DirectX的HLSL和Metal的MSL之间语义差异不小尤其是涉及到纹理格式、采样器状态、常量缓冲区布局的时候。在Madeira的架构里DXMT是作为Wine的一个图形驱动存在的。Wine把Windows的图形调用转发给DXMTDXMT再翻译成Metal。这个转发链条里任何一环出问题表现都是黑屏或者花屏排查起来需要逐层确认。层级组件输入输出关键依赖API翻译WineWindows PE/API调用POSIX调用PE加载器、注册表指令翻译FEX-Emux86-64指令流ARM64指令流48位VA内核图形翻译DXMTDirectX 11/12调用Metal API调用Metal驱动、MSL编译器3. 把Madeira跑起来环境准备与编译顺序3.1 基础依赖的安装顺序不能乱编译Madeira这种多层项目依赖顺序搞错会浪费大量时间。正确的顺序是先装FEX-Emu再装Wine最后装DXMT。因为Wine在编译时会检测FEX的头文件DXMT又依赖Wine的开发库。在Debian/Ubuntu系上基础依赖大概是这样sudo apt update sudo apt install -y build-essential cmake ninja-build git \ libsdl2-dev libvulkan-dev libgl1-mesa-dev \ libgnutls28-dev libasound2-dev libpulse-dev \ libfontconfig1-dev libfreetype6-devFEX-Emu还需要一些额外的依赖sudo apt install -y libepoxy-dev libdrm-dev libxcb-dri3-dev \ libxcb-present-dev libxcb-sync-dev libxshmfence-dev注意如果你在Apple Silicon Mac上通过虚拟机跑Linux记得给虚拟机分配至少4GB内存和4核CPU。FEX的翻译缓存在编译大型游戏时会吃掉不少内存内存不足会直接OOM。3.2 FEX-Emu的编译与RootFS准备FEX-Emu的编译本身不复杂但它需要一个x86-64的RootFS来提供32位和64位的x86库。这个RootFS可以用debootstrap从x86-64的Debian仓库拉取# 创建x86-64 rootfs sudo debootstrap --archamd64 bookworm /opt/fex-rootfs http://deb.debian.org/debian # 编译FEX git clone https://github.com/FEX-Emu/FEX.git cd FEX git submodule update --init --recursive cmake -S . -B build -G Ninja \ -DCMAKE_BUILD_TYPERelease \ -DCMAKE_INSTALL_PREFIX/usr/local ninja -C build sudo ninja -C build install编译完成后需要配置FEX的RootFS路径# 告诉FEX去哪里找x86库 echo /opt/fex-rootfs | sudo tee /etc/fex-rootfs这里有个坑FEX的RootFS里必须包含libc、libstdc、libgcc这些基础库的x86-64版本。如果debootstrap拉取不完整后面跑Windows程序时会报library not found但又不告诉你缺哪个。我的做法是手动进rootfs用ldd检查一遍关键库。3.3 Wine的WoW64编译配置Wine的编译选项直接决定了它能不能在ARM64上加载x86-64 PE。关键配置是git clone https://github.com/wine-mirror/wine.git cd wine ./configure --enable-archsi386,x86_64 \ --with-fex/usr/local \ --prefix/opt/wine-madeira make -j$(nproc) sudo make install--with-fex这个选项不是Wine官方标准配置在Madeira项目里应该是打了补丁的。如果你用的是原版Wine需要手动应用FEX相关的补丁让Wine在加载x86-64 PE时调用FEX的翻译器而不是直接执行。编译完成后用winecfg测试一下export WINEPREFIX~/.wine-madeira /opt/wine-madeira/bin/winecfg如果能看到Wine配置窗口弹出来说明Wine层和FEX层的衔接基本通了。如果窗口弹不出来或者报错先检查/etc/fex-rootfs路径对不对再看FEX的日志。3.4 DXMT的集成与Metal后端验证DXMT的编译需要macOS的Metal框架头文件所以在Linux上编译DXMT本身是不现实的。Madeira项目里DXMT应该是作为预编译的Wine驱动存在的或者是在macOS上编译好之后拷贝到Wine的lib/wine/x86_64-windows/目录下。验证DXMT是否生效的方法# 运行一个简单的D3D11测试程序 WINEPREFIX~/.wine-madeira /opt/wine-madeira/bin/wine \ d3d11_test.exe如果程序能正常渲染出画面说明DXMT的Metal后端工作正常。如果黑屏先看Wine的调试输出WINEDEBUGd3d11,dxgi /opt/wine-madeira/bin/wine game.exe 21 | grep -i dxmt\|metal日志里会显示DXMT初始化Metal设备的过程哪一步失败一目了然。4. 实际跑通一个Windows程序从exe到画面的完整链路4.1 选择一个合适的测试目标不要一上来就拿3A大作测试那样出问题你根本不知道是哪一层的锅。建议的测试顺序是记事本notepad.exe只涉及Wine的API翻译和FEX的指令翻译不涉及图形。简单的D3D11 Demo比如微软的DirectX SDK里的Tutorial系列验证DXMT的基本渲染。老款2D游戏比如一些基于DirectDraw或早期D3D的游戏验证兼容层的稳定性。D3D11的3D游戏最后再上强度。4.2 运行记事本验证WineFEX链路把Windows的notepad.exe拷贝到Wine的C盘目录cp /path/to/notepad.exe ~/.wine-madeira/drive_c/windows/ WINEPREFIX~/.wine-madeira /opt/wine-madeira/bin/wine \ ~/.wine-madeira/drive_c/windows/notepad.exe如果记事本窗口弹出来并且能输入文字说明Wine的PE加载、FEX的指令翻译、以及基本的窗口系统都通了。这一步失败的话问题大概率在FEX的RootFS或者Wine的WoW64配置上。实操心得记事本跑通之后可以试试wine cmd然后运行一些内置命令比如dir、echo。这些命令不涉及图形能进一步确认FEX的翻译稳定性。4.3 运行D3D11 Demo验证DXMT链路找一个编译好的D3D11示例程序比如Tutorial07.exe纹理映射那个。运行之前先设置好环境变量export WINEPREFIX~/.wine-madeira export WINEDLLOVERRIDESd3d11n,b;dxgin,b /opt/wine-madeira/bin/wine Tutorial07.exeWINEDLLOVERRIDES里的n,b意思是优先使用native DLL如果失败再回退到builtin。对于DXMT来说d3d11.dll和dxgi.dll应该是DXMT提供的native版本所以这个设置是必须的。如果Demo能渲染出旋转的立方体说明DXMT的Metal后端工作正常。如果黑屏但程序没崩溃检查Metal设备是否被正确初始化# 在macOS上检查Metal设备 system_profiler SPDisplaysDataType | grep -i metal4.4 性能调优FEX的翻译缓存与DXMT的着色器缓存跑通之后下一步是让帧率能看。FEX-Emu的翻译缓存默认是开启的但缓存文件的位置和大小可以调# 设置FEX缓存目录 export FEX_CACHE_DIR~/.fex-cache # 增大缓存大小限制单位MB export FEX_CACHE_MAX_SIZE4096DXMT也有着色器缓存第一次运行游戏时着色器编译会卡顿第二次就会好很多。缓存文件通常在~/.wine-madeira/drive_c/users/steamuser/Temp/DXMT_Cache/注意FEX的翻译缓存在不同版本的FEX之间不兼容。升级FEX之后旧的缓存文件需要删掉重新生成否则可能崩溃。5. 踩坑排查那些让你怀疑人生的报错5.1 Cannot execute binary fileFEX没被正确调用这个报错通常出现在你直接运行一个x86-64的Windows exe时。Wine的PE加载器识别出了PE格式但调用FEX翻译器失败。排查步骤确认/etc/fex-rootfs文件存在且路径正确。确认FEX的二进制在PATH里which FEXInterpreter。检查Wine的编译日志里有没有--with-fex相关的警告。如果FEX装好了但Wine没找到可能是Wine的configure阶段没有检测到FEX的头文件。手动指定./configure --with-fex/usr/local/include/FEX ...5.2 黑屏但有声音DXMT的Metal后端初始化失败游戏有声音说明Wine和FEX都正常问题出在图形层。最常见的原因是Metal设备创建失败。在macOS上Metal需要GPU支持如果你在虚拟机里跑可能没有GPU直通。检查方法# 在macOS上运行 xcrun metal -v如果这个命令报错说明Metal工具链没装好。另外DXMT需要macOS 10.15以上低于这个版本Metal功能不全。5.3 中文乱码Wine的字体和locale配置热搜词里出现了wine 乱码和wine 栏是乱码这是Wine的经典问题。根本原因是Wine默认的字体映射里没有中文字体或者locale设置不对。解决方法# 安装中文字体 sudo apt install fonts-wqy-microhei fonts-wqy-zenhei # 在Wine里注册字体 WINEPREFIX~/.wine-madeira /opt/wine-madeira/bin/wine \ reg add HKLM\\Software\\Microsoft\\Windows NT\\CurrentVersion\\Fonts \ /v WenQuanYi Micro Hei /t REG_SZ /d wqy-microhei.ttc然后设置localeexport LANGzh_CN.UTF-8 export LC_ALLzh_CN.UTF-8如果菜单栏还是乱码可能是Wine的winemenubuilder在生成菜单时用了错误的编码。可以禁用菜单生成WINEPREFIX~/.wine-madeira /opt/wine-madeira/bin/wine \ reg add HKCU\\Software\\Wine\\WineBrowser /v Browsers /t REG_SZ /d 5.4 FEX缓存导致的随机崩溃这个坑我踩过好几次游戏跑着跑着突然崩溃重启之后又能跑但跑一段时间又崩。最后发现是FEX的翻译缓存文件损坏了。FEX在写入缓存时如果被中断比如强制杀进程缓存文件可能处于不一致状态。解决方法# 删除FEX缓存 rm -rf ~/.fex-cache/* # 重新运行让FEX重新生成缓存为了避免这个问题可以在FEX的配置里开启原子写入export FEX_CACHE_ATOMIC_WRITE15.5 DXMT着色器编译卡顿第一次运行D3D11游戏时每遇到一个新的着色器组合DXMT都要现场编译成Metal Shading Language。这个过程可能耗时几百毫秒导致游戏卡顿。解决办法是预编译着色器缓存# 开启DXMT的着色器磁盘缓存 export DXMT_SHADER_CACHE1 export DXMT_SHADER_CACHE_PATH~/.dxmt-cache第二次运行同一个游戏时着色器直接从缓存加载卡顿会明显减少。报错现象可能原因排查命令解决方案Cannot execute binaryFEX未调用which FEXInterpreter检查--with-fex配置黑屏有声音Metal初始化失败xcrun metal -v确认macOS版本和GPU中文乱码字体/locale缺失locale安装中文字体并注册随机崩溃FEX缓存损坏查看~/.fex-cache删除缓存并开启原子写入着色器卡顿DXMT缓存未开启查看~/.dxmt-cache设置DXMT_SHADER_CACHE16. 关于Madeira这类项目的个人体会折腾Madeira这套东西最大的感受是跨平台兼容层的难点从来不在单点技术而在层与层之间的边界。Wine本身很成熟FEX-Emu的翻译质量也很高DXMT的Metal后端在大多数场景下也能用——但把这三者串起来每一层的假设都可能和另一层冲突。比如Wine假设PE加载后的代码可以直接执行但FEX要求代码必须经过翻译器FEX假设系统调用可以直接透传但DXMT的Metal调用需要经过Wine的图形驱动层转发。这些假设冲突的地方就是bug最多的地方。另一个体会是日志的重要性。Madeira这种多层架构出问题的时候错误信息往往只停留在最外层。我的习惯是同时开三个终端一个跑Wine的WINEDEBUG输出一个跑FEX的日志一个跑DXMT的Metal调试输出。三个日志对着看才能定位到问题到底出在哪一层。最后说一个实用技巧不要追求一次跑通所有功能。先把记事本跑通再把最简单的D3D11 Demo跑通再逐步上复杂度。每跑通一层就打个快照虚拟机快照或者容器镜像这样出问题可以快速回滚不用从头编译。我见过太多人一上来就编译最新版然后跑3A大作结果卡在某个依赖上几天都出不来最后放弃。分层验证、逐步推进才是折腾这类项目的正确姿势。 Madeira 跨平台兼容层：Wine、FEX-Emu 与 DXMT 实战指南
1. 从Madeira这个名字说起一个跨平台兼容层的真实需求第一次看到Madeira这个项目名很多人会以为是某个度假岛屿或者葡萄酒品牌——毕竟热搜词里就挂着Wine。但如果你是一个长期在Linux桌面和移动端之间来回折腾的开发者看到Wine、FEX-Emu、DXMT、x86-64这几个词凑在一起基本就能猜到这背后想解决的是什么问题了在非x86架构或者非Windows环境下把原本为Windows/x86-64编译的应用程序跑起来。Madeira这个项目从关键词组合来看核心定位是一个面向多架构的Windows应用兼容运行环境。它不是一个简单的Wine封装而是把Wine、FEX-Emux86-64指令翻译层、DXMTDirectX到Metal的翻译层这几块拼图组合在一起目标场景很可能是在ARM架构设备比如Apple Silicon Mac、ARM Linux设备上运行Windows x86-64应用和游戏。为什么这件事值得单独做一个项目因为现成的方案各有各的短板。纯Wine只能解决API层面的兼容解决不了指令集架构差异纯FEX-Emu能翻译指令但不管图形APIDXMT能处理DirectX但需要前面两层都跑通。把这三者串起来还要处理它们之间的边界问题——比如Wine的PE加载器和FEX的翻译缓存怎么配合、DXMT的Metal后端在Wine的窗口系统下怎么初始化——这才是Madeira真正要啃的硬骨头。这篇文章适合谁看如果你正在做Linux桌面兼容层、ARM平台游戏移植、或者单纯想搞清楚一个Windows exe在ARM设备上到底经历了什么才能跑起来那接下来的内容会对你有用。我会从架构拆解、环境搭建、实际跑通、踩坑排查几个角度把这个项目的核心逻辑讲透。2. Madeira的三层架构Wine、FEX-Emu、DXMT各自负责什么2.1 Wine层API翻译与PE加载Wine在Madeira里承担的是最上层的Windows API翻译工作。当你在Linux上双击一个.exe文件Wine要做的事情包括解析PE格式、加载依赖的DLL、把Windows系统调用翻译成POSIX调用、维护注册表和文件系统的虚拟映射。但这里有个容易被忽略的细节Wine本身并不关心底层是x86还是ARM。它只负责Windows API到Linux API的翻译。如果底层CPU是x86-64那Wine编译出来的代码可以直接跑如果底层是ARM64Wine的代码本身需要被编译成ARM64而它加载的Windows PE文件仍然是x86-64的——这中间的指令集鸿沟就得靠FEX-Emu来填。在Madeira的语境下Wine大概率是以WoW64模式运行的。传统WoW64是Windows上32位跑在64位上的机制但Wine的WoW64是另一回事它允许一个64位的Wine进程加载32位的PE模块。在ARM64主机上这意味着Wine的PE加载器需要同时处理x86-64和x86两种PE格式而这两种格式的代码都需要FEX来翻译。实操提示如果你自己编译Wine记得开启--enable-archsi386,x86_64否则在ARM主机上加载32位Windows程序会直接报cannot execute binary file。2.2 FEX-Emu层x86-64到ARM64的指令翻译FEX-Emu是整个链条里最重的一层。它的工作是把x86-64指令动态翻译成ARM64指令。和QEMU那种全系统模拟不同FEX-Emu是用户态翻译——它不模拟整个CPU和硬件只翻译用户空间的指令流系统调用直接透传给宿主Linux内核。FEX-Emu的核心机制是块翻译加缓存。它会把x86-64代码按基本块切分每个基本块翻译成ARM64后缓存起来下次执行到同一块代码时直接走缓存。这个设计对游戏场景特别重要——游戏主循环里的热点代码会被反复执行缓存命中率高的时候翻译开销可以降到很低。但FEX-Emu有个关键限制它要求宿主内核支持48位地址空间。因为x86-64的虚拟地址布局和ARM64不完全一样FEX需要在宿主地址空间里模拟x86-64的地址映射。如果你的内核配置不对FEX启动时会直接报48-bit VA not supported然后退出。# 检查内核是否支持48位VA cat /proc/cpuinfo | grep -i address sizes # 输出里如果有48 bits virtual就说明支持2.3 DXMT层DirectX到Metal的翻译DXMT是Madeira里负责图形的那一环。它的作用是把Windows游戏调用的DirectX 11/12 API翻译成Apple的Metal API。为什么是Metal而不是Vulkan因为Madeira的目标平台很可能包括Apple Silicon Mac而macOS上Vulkan支持一直是个痛点Metal才是原生选择。DXMT的工作方式和DXVK类似但目标API不同。它拦截游戏对d3d11.dll、dxgi.dll的调用把着色器编译成Metal Shading Language把资源绑定映射到Metal的heap和buffer。这里最麻烦的是着色器编译——DirectX的HLSL和Metal的MSL之间语义差异不小尤其是涉及到纹理格式、采样器状态、常量缓冲区布局的时候。在Madeira的架构里DXMT是作为Wine的一个图形驱动存在的。Wine把Windows的图形调用转发给DXMTDXMT再翻译成Metal。这个转发链条里任何一环出问题表现都是黑屏或者花屏排查起来需要逐层确认。层级组件输入输出关键依赖API翻译WineWindows PE/API调用POSIX调用PE加载器、注册表指令翻译FEX-Emux86-64指令流ARM64指令流48位VA内核图形翻译DXMTDirectX 11/12调用Metal API调用Metal驱动、MSL编译器3. 把Madeira跑起来环境准备与编译顺序3.1 基础依赖的安装顺序不能乱编译Madeira这种多层项目依赖顺序搞错会浪费大量时间。正确的顺序是先装FEX-Emu再装Wine最后装DXMT。因为Wine在编译时会检测FEX的头文件DXMT又依赖Wine的开发库。在Debian/Ubuntu系上基础依赖大概是这样sudo apt update sudo apt install -y build-essential cmake ninja-build git \ libsdl2-dev libvulkan-dev libgl1-mesa-dev \ libgnutls28-dev libasound2-dev libpulse-dev \ libfontconfig1-dev libfreetype6-devFEX-Emu还需要一些额外的依赖sudo apt install -y libepoxy-dev libdrm-dev libxcb-dri3-dev \ libxcb-present-dev libxcb-sync-dev libxshmfence-dev注意如果你在Apple Silicon Mac上通过虚拟机跑Linux记得给虚拟机分配至少4GB内存和4核CPU。FEX的翻译缓存在编译大型游戏时会吃掉不少内存内存不足会直接OOM。3.2 FEX-Emu的编译与RootFS准备FEX-Emu的编译本身不复杂但它需要一个x86-64的RootFS来提供32位和64位的x86库。这个RootFS可以用debootstrap从x86-64的Debian仓库拉取# 创建x86-64 rootfs sudo debootstrap --archamd64 bookworm /opt/fex-rootfs http://deb.debian.org/debian # 编译FEX git clone https://github.com/FEX-Emu/FEX.git cd FEX git submodule update --init --recursive cmake -S . -B build -G Ninja \ -DCMAKE_BUILD_TYPERelease \ -DCMAKE_INSTALL_PREFIX/usr/local ninja -C build sudo ninja -C build install编译完成后需要配置FEX的RootFS路径# 告诉FEX去哪里找x86库 echo /opt/fex-rootfs | sudo tee /etc/fex-rootfs这里有个坑FEX的RootFS里必须包含libc、libstdc、libgcc这些基础库的x86-64版本。如果debootstrap拉取不完整后面跑Windows程序时会报library not found但又不告诉你缺哪个。我的做法是手动进rootfs用ldd检查一遍关键库。3.3 Wine的WoW64编译配置Wine的编译选项直接决定了它能不能在ARM64上加载x86-64 PE。关键配置是git clone https://github.com/wine-mirror/wine.git cd wine ./configure --enable-archsi386,x86_64 \ --with-fex/usr/local \ --prefix/opt/wine-madeira make -j$(nproc) sudo make install--with-fex这个选项不是Wine官方标准配置在Madeira项目里应该是打了补丁的。如果你用的是原版Wine需要手动应用FEX相关的补丁让Wine在加载x86-64 PE时调用FEX的翻译器而不是直接执行。编译完成后用winecfg测试一下export WINEPREFIX~/.wine-madeira /opt/wine-madeira/bin/winecfg如果能看到Wine配置窗口弹出来说明Wine层和FEX层的衔接基本通了。如果窗口弹不出来或者报错先检查/etc/fex-rootfs路径对不对再看FEX的日志。3.4 DXMT的集成与Metal后端验证DXMT的编译需要macOS的Metal框架头文件所以在Linux上编译DXMT本身是不现实的。Madeira项目里DXMT应该是作为预编译的Wine驱动存在的或者是在macOS上编译好之后拷贝到Wine的lib/wine/x86_64-windows/目录下。验证DXMT是否生效的方法# 运行一个简单的D3D11测试程序 WINEPREFIX~/.wine-madeira /opt/wine-madeira/bin/wine \ d3d11_test.exe如果程序能正常渲染出画面说明DXMT的Metal后端工作正常。如果黑屏先看Wine的调试输出WINEDEBUGd3d11,dxgi /opt/wine-madeira/bin/wine game.exe 21 | grep -i dxmt\|metal日志里会显示DXMT初始化Metal设备的过程哪一步失败一目了然。4. 实际跑通一个Windows程序从exe到画面的完整链路4.1 选择一个合适的测试目标不要一上来就拿3A大作测试那样出问题你根本不知道是哪一层的锅。建议的测试顺序是记事本notepad.exe只涉及Wine的API翻译和FEX的指令翻译不涉及图形。简单的D3D11 Demo比如微软的DirectX SDK里的Tutorial系列验证DXMT的基本渲染。老款2D游戏比如一些基于DirectDraw或早期D3D的游戏验证兼容层的稳定性。D3D11的3D游戏最后再上强度。4.2 运行记事本验证WineFEX链路把Windows的notepad.exe拷贝到Wine的C盘目录cp /path/to/notepad.exe ~/.wine-madeira/drive_c/windows/ WINEPREFIX~/.wine-madeira /opt/wine-madeira/bin/wine \ ~/.wine-madeira/drive_c/windows/notepad.exe如果记事本窗口弹出来并且能输入文字说明Wine的PE加载、FEX的指令翻译、以及基本的窗口系统都通了。这一步失败的话问题大概率在FEX的RootFS或者Wine的WoW64配置上。实操心得记事本跑通之后可以试试wine cmd然后运行一些内置命令比如dir、echo。这些命令不涉及图形能进一步确认FEX的翻译稳定性。4.3 运行D3D11 Demo验证DXMT链路找一个编译好的D3D11示例程序比如Tutorial07.exe纹理映射那个。运行之前先设置好环境变量export WINEPREFIX~/.wine-madeira export WINEDLLOVERRIDESd3d11n,b;dxgin,b /opt/wine-madeira/bin/wine Tutorial07.exeWINEDLLOVERRIDES里的n,b意思是优先使用native DLL如果失败再回退到builtin。对于DXMT来说d3d11.dll和dxgi.dll应该是DXMT提供的native版本所以这个设置是必须的。如果Demo能渲染出旋转的立方体说明DXMT的Metal后端工作正常。如果黑屏但程序没崩溃检查Metal设备是否被正确初始化# 在macOS上检查Metal设备 system_profiler SPDisplaysDataType | grep -i metal4.4 性能调优FEX的翻译缓存与DXMT的着色器缓存跑通之后下一步是让帧率能看。FEX-Emu的翻译缓存默认是开启的但缓存文件的位置和大小可以调# 设置FEX缓存目录 export FEX_CACHE_DIR~/.fex-cache # 增大缓存大小限制单位MB export FEX_CACHE_MAX_SIZE4096DXMT也有着色器缓存第一次运行游戏时着色器编译会卡顿第二次就会好很多。缓存文件通常在~/.wine-madeira/drive_c/users/steamuser/Temp/DXMT_Cache/注意FEX的翻译缓存在不同版本的FEX之间不兼容。升级FEX之后旧的缓存文件需要删掉重新生成否则可能崩溃。5. 踩坑排查那些让你怀疑人生的报错5.1 Cannot execute binary fileFEX没被正确调用这个报错通常出现在你直接运行一个x86-64的Windows exe时。Wine的PE加载器识别出了PE格式但调用FEX翻译器失败。排查步骤确认/etc/fex-rootfs文件存在且路径正确。确认FEX的二进制在PATH里which FEXInterpreter。检查Wine的编译日志里有没有--with-fex相关的警告。如果FEX装好了但Wine没找到可能是Wine的configure阶段没有检测到FEX的头文件。手动指定./configure --with-fex/usr/local/include/FEX ...5.2 黑屏但有声音DXMT的Metal后端初始化失败游戏有声音说明Wine和FEX都正常问题出在图形层。最常见的原因是Metal设备创建失败。在macOS上Metal需要GPU支持如果你在虚拟机里跑可能没有GPU直通。检查方法# 在macOS上运行 xcrun metal -v如果这个命令报错说明Metal工具链没装好。另外DXMT需要macOS 10.15以上低于这个版本Metal功能不全。5.3 中文乱码Wine的字体和locale配置热搜词里出现了wine 乱码和wine 栏是乱码这是Wine的经典问题。根本原因是Wine默认的字体映射里没有中文字体或者locale设置不对。解决方法# 安装中文字体 sudo apt install fonts-wqy-microhei fonts-wqy-zenhei # 在Wine里注册字体 WINEPREFIX~/.wine-madeira /opt/wine-madeira/bin/wine \ reg add HKLM\\Software\\Microsoft\\Windows NT\\CurrentVersion\\Fonts \ /v WenQuanYi Micro Hei /t REG_SZ /d wqy-microhei.ttc然后设置localeexport LANGzh_CN.UTF-8 export LC_ALLzh_CN.UTF-8如果菜单栏还是乱码可能是Wine的winemenubuilder在生成菜单时用了错误的编码。可以禁用菜单生成WINEPREFIX~/.wine-madeira /opt/wine-madeira/bin/wine \ reg add HKCU\\Software\\Wine\\WineBrowser /v Browsers /t REG_SZ /d 5.4 FEX缓存导致的随机崩溃这个坑我踩过好几次游戏跑着跑着突然崩溃重启之后又能跑但跑一段时间又崩。最后发现是FEX的翻译缓存文件损坏了。FEX在写入缓存时如果被中断比如强制杀进程缓存文件可能处于不一致状态。解决方法# 删除FEX缓存 rm -rf ~/.fex-cache/* # 重新运行让FEX重新生成缓存为了避免这个问题可以在FEX的配置里开启原子写入export FEX_CACHE_ATOMIC_WRITE15.5 DXMT着色器编译卡顿第一次运行D3D11游戏时每遇到一个新的着色器组合DXMT都要现场编译成Metal Shading Language。这个过程可能耗时几百毫秒导致游戏卡顿。解决办法是预编译着色器缓存# 开启DXMT的着色器磁盘缓存 export DXMT_SHADER_CACHE1 export DXMT_SHADER_CACHE_PATH~/.dxmt-cache第二次运行同一个游戏时着色器直接从缓存加载卡顿会明显减少。报错现象可能原因排查命令解决方案Cannot execute binaryFEX未调用which FEXInterpreter检查--with-fex配置黑屏有声音Metal初始化失败xcrun metal -v确认macOS版本和GPU中文乱码字体/locale缺失locale安装中文字体并注册随机崩溃FEX缓存损坏查看~/.fex-cache删除缓存并开启原子写入着色器卡顿DXMT缓存未开启查看~/.dxmt-cache设置DXMT_SHADER_CACHE16. 关于Madeira这类项目的个人体会折腾Madeira这套东西最大的感受是跨平台兼容层的难点从来不在单点技术而在层与层之间的边界。Wine本身很成熟FEX-Emu的翻译质量也很高DXMT的Metal后端在大多数场景下也能用——但把这三者串起来每一层的假设都可能和另一层冲突。比如Wine假设PE加载后的代码可以直接执行但FEX要求代码必须经过翻译器FEX假设系统调用可以直接透传但DXMT的Metal调用需要经过Wine的图形驱动层转发。这些假设冲突的地方就是bug最多的地方。另一个体会是日志的重要性。Madeira这种多层架构出问题的时候错误信息往往只停留在最外层。我的习惯是同时开三个终端一个跑Wine的WINEDEBUG输出一个跑FEX的日志一个跑DXMT的Metal调试输出。三个日志对着看才能定位到问题到底出在哪一层。最后说一个实用技巧不要追求一次跑通所有功能。先把记事本跑通再把最简单的D3D11 Demo跑通再逐步上复杂度。每跑通一层就打个快照虚拟机快照或者容器镜像这样出问题可以快速回滚不用从头编译。我见过太多人一上来就编译最新版然后跑3A大作结果卡在某个依赖上几天都出不来最后放弃。分层验证、逐步推进才是折腾这类项目的正确姿势。