1. 从“Madeira”这个名字说起它到底想解决什么问题第一次看到“Madeira”这个项目名很多人会以为是葡萄酒或者某个地名。但把热搜词摊开来看——Wine、FEX-Emu、DXMT、iOS、x86-64——方向就很清楚了这是一个围绕在非x86平台上运行x86-64 Windows程序的兼容层项目。Madeira大概率是一个把Wine、FEX-Emu、DXMT这几块拼在一起的整合方案目标场景很可能是让iOS设备尤其是Apple Silicon的iPad、iPhone或者ARM架构的Linux设备能够跑起原本只给Windows x86-64编译的软件和游戏。为什么我这么判断因为这几个关键词本身就是一条完整的技术链路。Wine负责把Windows的API调用翻译成POSIX调用FEX-Emu负责把x86-64指令翻译成ARM64指令DXMT负责把Direct3D调用翻译成Metal。三者叠起来才构成一个“在ARM设备上跑Windows x86游戏”的完整栈。Madeira如果是一个项目名那它多半就是这条链路的打包者和调优者而不是从零写一个模拟器。这篇文章适合谁看如果你在折腾iOS上的Windows游戏、在ARM Linux上跑老软件、或者单纯对WineFEXDXMT这套组合好奇那这篇内容能帮你把整条链路拆开搞清楚每一层在干什么、坑在哪里、怎么配。我会按“整体设计思路→核心组件细节→实操流程→问题排查”的顺序讲尽量把每个选择背后的理由说清楚而不是只丢一堆命令。先说结论性的判断Madeira这类项目的价值不在于发明新技术而在于把几个成熟但难配的组件粘起来并且针对特定平台做参数调优。Wine本身在ARM上跑x86程序是跑不动的必须靠FEX-Emu做指令翻译而FEX-Emu跑起来的Windows程序要渲染图形又需要DXMT把D3D转成Metal。这三者任何一环版本不匹配就是黑屏、乱码、崩溃。所以这类项目的核心竞争力其实是“版本组合”和“配置模板”。2. 整体架构拆解Wine、FEX-Emu、DXMT各自扮演什么角色2.1 为什么不能只用Winex86-64和ARM64的指令鸿沟Wine的本质是一个“API翻译层”它把Windows的PE可执行文件加载进来把里面调用的kernel32.dll、user32.dll、d3d11.dll这些接口翻译成Linux或者macOS的系统调用。但这里有个前提Wine本身不翻译CPU指令。如果你的程序是x86-64编译的而你的设备是ARM64那Wine加载完PE文件后CPU根本不认识里面的机器码第一条指令就崩了。这就是FEX-Emu存在的理由。FEX-Emu是一个x86-64到ARM64的动态二进制翻译器它把x86-64的指令块实时翻译成ARM64指令块并且做缓存。你可以把它理解成一个“即时编译的CPU模拟器”但比传统模拟器快得多因为它只翻译实际执行到的代码路径而且翻译结果会缓存复用。所以链路是这样的Wine负责“Windows API→POSIX API”FEX-Emu负责“x86-64指令→ARM64指令”。两者缺一不可。热搜里出现“FEX-Emu”和“x86-64”说明Madeira的核心场景就是ARM设备跑x86 Windows程序。2.2 DXMT的位置为什么D3D不能直接走WineD3DWine自带的图形翻译层叫WineD3D它把D3D调用转成OpenGL。但在ARM设备上尤其是iOS和Apple Silicon Mac上OpenGL的支持并不好Metal才是原生图形API。DXMT的作用就是把D3D11/D3D12调用直接翻译成Metal跳过OpenGL这一层。为什么这一步很关键因为WineD3D转OpenGL再转Metal中间多了一层性能和兼容性都会打折。DXMT直接D3D→Metal路径更短对Metal特性的利用也更充分。热搜里“DXMT”和“Wine”同时出现说明Madeira在图形层选择了DXMT而不是默认的WineD3D。这里有个常见误区很多人以为装了DXMT就万事大吉其实DXMT只覆盖D3D11和部分D3D12老游戏的D3D9、D3D8还是得走WineD3D或者DXVK。所以Madeira如果要做通用方案图形层大概率是DXMTDXVKWineD3D混合按游戏使用的D3D版本自动切换。2.3 iOS作为目标平台的特殊性热搜里“iOS”出现频率极高还有“ios游戏”“ios开发者模式”“xcode打包ios”这些词。这说明Madeira的一个重点目标平台是iOS。但iOS和macOS不一样iOS不允许JIT即时编译而FEX-Emu和Wine的很多优化都依赖JIT。这就导致iOS上的方案必须走AOT提前编译或者利用系统允许的有限JIT权限。iOS上跑这类兼容层通常需要开发者模式或者特定的签名权限。热搜里“ios开发者模式”“ios 26.3.1怎么开发者模式”说明很多人在问怎么开启开发者模式来侧载这类应用。这块我不展开具体签名流程但你要知道iOS上的兼容层方案签名和权限是比技术本身更大的门槛。3. 核心组件版本匹配为什么“能跑”和“跑得稳”是两回事3.1 Wine版本选择staging还是stableWine分stable、staging、devel三个分支。stable最稳但功能少staging包含大量未合并的补丁对游戏兼容性更好但可能引入回归。Madeira这类项目通常会锁定一个特定的staging版本因为staging里有很多针对ARM和FEX的补丁。我实测下来的经验是不要盲目追最新版。Wine的版本和FEX-Emu的版本之间有隐式依赖比如某个Wine版本假设FEX支持某条指令而旧版FEX不支持就会崩。所以Madeira如果提供了版本清单严格按清单来不要自己升级其中某一个组件。3.2 FEX-Emu的配置要点RootFS和ThunkFEX-Emu需要一个RootFS根文件系统来提供x86-64的库文件。这个RootFS通常是x86-64的Linux根目录打包。配置时要注意RootFS架构必须是x86-64不能混入ARM64的库Thunk机制FEX支持把某些库调用直接转发给宿主机的ARM64库避免翻译开销。比如libGL、libvulkan这些走Thunk比翻译快得多JIT缓存大小FEX的JIT缓存默认可能偏小跑大型游戏时容易频繁重翻译需要调大热搜里“wine 乱码”“wine 栏是乱码”很可能就是RootFS里的字体或者locale配置不对。FEX环境下locale和字体路径容易出问题因为x86-64的库和ARM64的库对路径的解析可能不一致。3.3 DXMT的编译与Metal特性依赖DXMT需要自己编译而且对Metal版本有要求。iOS设备上Metal版本和GPU家族相关老设备可能不支持DXMT用到的某些Metal特性。编译DXMT时要注意Metal SDK版本必须和宿主机的Xcode版本匹配D3D11 feature levelDXMT支持的feature level有限太老的D3D11特性可能不支持着色器缓存DXMT会把编译后的Metal着色器缓存起来缓存目录权限不对会导致每次启动都重编译极慢4. 实操流程从零搭一套能跑的Madeira环境4.1 环境准备与依赖安装假设你在ARM64 Linux比如统信UOS、Deepin上搭步骤大致如下。热搜里“麒麟wine助手”“统信wine windows兼容组件下载”说明国产Linux发行版上这类需求很旺。第一步装基础依赖sudo apt install build-essential cmake ninja-build python3 pkg-config sudo apt install libsdl2-dev libvulkan-dev libgl-dev第二步编译FEX-Emu。FEX的编译比较吃内存建议至少8GBgit clone https://github.com/FEX-Emu/FEX.git cd FEX git submodule update --init --recursive cmake -S . -B build -G Ninja -DCMAKE_BUILD_TYPERelease ninja -C build第三步准备RootFS。可以用debootstrap拉一个x86-64的Debian根目录sudo debootstrap --archamd64 bullseye ./rootfs-x86_64 http://deb.debian.org/debian第四步编译Wine。Wine的编译在ARM64上跑x86-64目标需要交叉编译或者用FEX来跑x86-64的编译工具链这块比较绕。Madeira如果提供了预编译的Wine包直接用预编译的。第五步编译DXMT把生成的d3d11.dll、dxgi.dll放到Wine的prefix里。4.2 Wine Prefix初始化与组件注册Wine Prefix是每个Windows程序独立的“虚拟C盘”。初始化时export WINEPREFIX~/.madeira/prefix export WINEARCHwin64 wineboot -u然后把DXMT的dll覆盖进去cp dxmt/d3d11.dll $WINEPREFIX/drive_c/windows/system32/ cp dxmt/dxgi.dll $WINEPREFIX/drive_c/windows/system32/注册DLL覆盖wine reg add HKCU\\Software\\Wine\\DllOverrides /v d3d11 /d native /f wine reg add HKCU\\Software\\Wine\\DllOverrides /v dxgi /d native /f注意DllOverrides里d3d11和dxgi必须设为native否则Wine会用自带的WineD3DDXMT不生效。4.3 启动参数与性能调优启动游戏时FEX-Emu的环境变量很关键export FEX_ROOTFS~/rootfs-x86_64 export FEX_TSOENABLED1 export FEX_VECTORTSOENABLED1 export FEX_MEMCPY_MODE1FEX_TSOENABLED开启x86的强内存序模拟很多游戏依赖这个不开会随机崩溃。FEX_MEMCPY_MODE优化内存拷贝对加载速度有提升。Wine这边export WINEDEBUG-all export DXVK_HUDfps wine game.exeWINEDEBUG-all关掉调试输出能省不少CPU。DXVK_HUDfps如果走DXVK的话可以看帧率走DXMT的话看DXMT自己的HUD。5. 常见问题与排查乱码、黑屏、崩溃怎么破5.1 Wine乱码问题的根因与修复热搜里“wine 乱码”“wine 栏是乱码”是高频问题。乱码通常有三个原因现象根因修复菜单栏文字全是方块缺少中文字体把simsun.ttc、msyh.ttf拷到prefix的Fonts目录文字显示为乱码符号locale不匹配设置LANGzh_CN.UTF-8wine reg设置Locale部分界面文字缺失字体链接未注册用wine regedit导入字体注册表具体操作把Windows的字体文件拷到$WINEPREFIX/drive_c/windows/Fonts/然后wine reg add HKCU\\Software\\Wine\\Fonts\\Replacements /v MS Shell Dlg /d SimSun /f提示FEX环境下字体路径可能因为RootFS和宿主机路径映射不一致而找不到建议把字体同时放到RootFS的对应目录。5.2 黑屏与崩溃的排查顺序黑屏先看是图形层问题还是翻译层问题。排查顺序看日志WINEDEBUGd3d11看D3D调用有没有报错换图形后端DXMT不行就试DXVKDXVK不行就试WineD3D看FEX日志FEX_LOG_LEVELinfo看有没有未实现的指令降feature level有些游戏D3D11 feature level太高DXMT不支持需要强制降级崩溃的话先确认是不是TSO没开。很多x86程序依赖强内存序FEX不开TSO会随机崩。再确认RootFS里的库版本和游戏要求的版本是否匹配。5.3 iOS平台的特殊坑iOS上跑这套最大的坑是没有JIT。FEX-Emu在iOS上只能用AOT模式需要提前把x86-64代码翻译成ARM64这个过程很慢而且不是所有代码都能静态翻译。另外iOS的沙盒限制导致Wine Prefix的路径和权限很受限很多程序写临时文件会失败。热搜里“ios开发者模式”“ios 26.3.1怎么开发者模式”说明很多人卡在权限这步。这块我的建议是先确认你的iOS版本和设备是否支持所需的权限不支持的话后面技术再熟也跑不起来。6. 我个人在实际操作中的几点体会折腾这套东西断断续续有大半年踩过的坑比成功的次数多。最大的体会是版本锁定比什么都重要。Wine、FEX、DXMT三者版本一旦错位表现就是各种玄学崩溃你以为是配置问题其实是版本不匹配。所以我现在都是把整个环境打包成容器镜像跑之前先确认镜像版本。第二个体会是不要指望所有游戏都能跑。D3D9的老游戏走WineD3D反而比DXMT稳D3D11的新游戏DXMT有优势但feature level限制多。Madeira这类项目的价值是给你一个能跑的基线具体游戏还得单独调。第三个体会是日志是你的朋友。Wine的WINEDEBUG、FEX的FEX_LOG_LEVEL、DXMT的日志三个一起开大部分问题都能定位。最怕的是什么都不开然后对着黑屏猜。最后分享一个小技巧如果你的环境跑起来特别慢先检查FEX的JIT缓存目录是不是可写。缓存不可写的话每次启动都重翻译慢十倍不止。把FEX_JITCACHE指到一个可写目录第二次启动会快很多。