1. 从“Madeira”这个名字说起它到底想解决什么问题第一次看到“Madeira”这个项目名很多人会以为是某个葡萄酒品牌或者旅游项目但结合 Wine、FEX-Emu、DXMT、iOS、x86-64 这几个关键词方向就很清楚了——这是一个围绕在非 x86 平台尤其是 ARM 架构的移动设备上运行 x86-64 Windows 程序的兼容层/模拟器整合方案。Madeira 这个名字本身是葡萄牙的一个岛屿也是马德拉酒的产地但在这个语境下它更像是一个代号代表一套把 Wine、FEX-Emu、DXMT 这几块拼图拼起来的工程实践。先把这几个核心组件的关系理清楚不然后面全是糊涂账Wine不是模拟器是兼容层。它把 Windows 的 API 调用翻译成 POSIX 调用Linux/macOS 上让 Windows 程序以为自己跑在 Windows 上。它不模拟 CPU 指令所以只能跑同架构的程序——x86 的 Wine 跑 x86 程序ARM 的 Wine 跑 ARM 程序。FEX-Emu这是关键。它是一个 x86-64 到 ARM64 的动态二进制翻译器专门为游戏场景优化。它把 x86-64 指令实时翻译成 ARM64 指令让 ARM 设备能跑 x86-64 的代码。FEX-Emu 的定位和 Box64 类似但在浮点、SIMD 指令翻译和 JIT 优化上有自己的取舍。DXMT这是把 Direct3D 调用翻译成 Metal 的层。macOS 上原本有 DXVKD3D→Vulkan和 MoltenVKVulkan→Metal这条链路但 DXMT 走的是更直接的 D3D→Metal 路径减少中间层开销。在 iOS 场景下Metal 是唯一能用的图形 API所以 DXMT 的存在很关键。所以 Madeira 这个项目本质上是在回答一个问题怎么把这三层Wine 的 API 翻译 FEX-Emu 的指令翻译 DXMT 的图形翻译串起来让 iOS 设备ARM64能跑 x86-64 的 Windows 游戏或应用。这个方向不是空穴来风。iOS 设备现在性能很强M 系列芯片的 GPU 能力甚至超过不少轻薄本但 iOS 的封闭性让“跑 Windows 程序”这件事一直很难。越狱设备可以装一些兼容层非越狱设备基本只能靠远程串流。Madeira 这类项目的价值在于它试图在不越狱或轻度越狱的前提下把这条链路跑通。适合谁来参考这篇文章如果你是以下几类人这篇内容会对你有用想在 iOS/iPadOS 上跑老 Windows 游戏或工具的折腾党对 Wine、FEX-Emu、DXMT 这套技术栈感兴趣想自己搭一套兼容层的开发者在做 ARM 平台 Windows 兼容方案需要了解各组件选型和踩坑点的工程师单纯好奇“手机跑 x86 Windows 程序”这件事到底怎么实现的技術爱好者。下面我会按“整体设计思路 → 核心组件细节 → 实操流程 → 问题排查”这个顺序把 Madeira 这类项目的里里外外讲清楚。内容会涉及不少命令行操作和配置但我会尽量把每一步的意图和原理说透让你不只是抄命令而是知道为什么这么干。2. 整体架构设计为什么是 Wine FEX-Emu DXMT 这个组合2.1 三层翻译链路的必然性在 ARM 设备上跑 x86-64 Windows 程序本质上要跨越三道鸿沟第一道是 CPU 指令集鸿沟。Windows 程序编译出来是 x86-64 机器码ARM64 设备不认识。解决方式有两种一是模拟emulation逐条解释执行 x86 指令慢但兼容性好二是动态二进制翻译dynamic binary translation把 x86 指令块翻译成 ARM64 指令块并缓存起来快但实现复杂。FEX-Emu 属于后者它的 JIT 引擎会把热点代码翻译成 ARM64 并缓存冷代码则解释执行。这个取舍很关键——纯解释器跑游戏基本没法看纯静态翻译又没法处理自修改代码所以动态翻译是唯一可行的路线。第二道是操作系统 API 鸿沟。Windows 程序调用的是 kernel32.dll、user32.dll、ntdll.dll 这些ARM 设备上要么是 LinuxAndroid要么是 DarwiniOS。Wine 的作用就是提供这些 DLL 的替代实现把 Windows API 调用翻译成宿主系统的调用。比如 CreateFile 翻译成 openVirtualAlloc 翻译成 mmap。Wine 不涉及 CPU 指令翻译它假设程序已经能在当前架构上执行——所以在 ARM 上跑 x86 程序时Wine 本身也得是 x86 版本由 FEX-Emu 来翻译。第三道是图形 API 鸿沟。Windows 游戏大量使用 Direct3D 9/10/11/12而 iOS 只有 Metal。这中间的翻译层有好几种走法方案链路优点缺点DXVK MoltenVKD3D→Vulkan→Metal成熟社区大两层翻译开销高DXMTD3D→Metal少一层延迟低较新兼容性待验证WineD3DD3D→OpenGL兼容性最好iOS 上 OpenGL 已废弃D3DMetalD3D→MetalApple 官方支持仅限特定环境Madeira 选 DXMT 而不是 DXVKMoltenVK核心考量是减少翻译层数。每多一层翻译就多一次状态转换和内存拷贝对帧率的影响在移动设备上会被放大。DXMT 直接把 D3D 调用映射到 Metal理论上延迟更低。但代价是 DXMT 的成熟度不如 DXVK某些冷门 D3D 特性可能没实现。2.2 为什么不用 Box64 而用 FEX-EmuBox64 和 FEX-Emu 都是 x86-64→ARM64 的翻译器但定位不同。Box64 更偏向“能跑就行”对系统库的依赖少适合在 Android 上跑一些轻量程序。FEX-Emu 则更激进地优化游戏场景它有自己的 RootFS一个精简的 x86-64 Linux 文件系统里面打包了 Wine 和必要的库形成一个自包含的运行环境。FEX-Emu 的优势在于JIT 优化更激进对 SSE/AVX 指令的翻译做了大量特化游戏里常见的浮点运算和向量运算能跑得更快RootFS 机制把 x86-64 的库和 Wine 打包在一起不依赖宿主系统的 x86 库减少了“缺库”问题Thunk 机制允许 x86 代码直接调用 ARM64 的宿主库比如 Metal、AudioToolbox避免走完整的翻译链路。但 FEX-Emu 的 RootFS 也带来一个问题它假设宿主是 Linux。在 iOS 上Darwin 的系统调用和 Linux 差异很大所以 Madeira 这类项目需要做一层Darwin 适配把 FEX-Emu 的 Linux 系统调用翻译成 Darwin 的。这部分工作量不小也是这类项目最容易出问题的地方。2.3 iOS 作为宿主的特殊约束iOS 和 Android 在跑 Wine 这件事上约束完全不同没有 fork/execiOS 不允许应用 fork 子进程再 exec 新程序。Wine 的很多逻辑依赖进程创建在 iOS 上得改成线程或者用 posix_spawn 的受限版本。代码签名和 JIT 限制iOS 默认不允许 JIT即时编译而 FEX-Emu 的核心就是 JIT。越狱设备可以关闭这个限制非越狱设备基本没戏。这也是为什么这类项目通常要求设备已越狱或处于开发者模式。Metal 是唯一图形出口OpenGL 在 iOS 上已废弃Vulkan 没有原生支持所以 DXMT 几乎是唯一选择。文件系统沙盒Wine 需要访问 Windows 风格的路径C:\在 iOS 上得映射到沙盒内的目录路径转换逻辑要自己写。所以 Madeira 的架构不是简单地把 Linux 上的 WineFEX 搬过来而是要做大量 Darwin 适配。这也是为什么这类项目往往以“实验性”为主稳定性和兼容性需要长期打磨。3. 核心组件细节Wine、FEX-Emu、DXMT 各自的关键配置3.1 Wine 的编译与配置要点在 ARM 上跑 x86 Windows 程序Wine 本身必须是x86-64 版本由 FEX-Emu 来翻译执行。这意味着你不能用系统自带的 ARM Wine得自己编译或者用 FEX-Emu RootFS 里预打包的版本。编译 Wine 时几个关键配置./configure \ --enable-archsi386,x86_64 \ --with-x \ --without-wayland \ --disable-tests--enable-archsi386,x86_64同时支持 32 位和 64 位 Windows 程序。很多老游戏是 32 位的没有 WoW64 支持就跑不起来。--without-wayland在 iOS/Darwin 环境下 Wayland 没意义去掉减少依赖。--disable-tests测试套件编译很耗时实际使用不需要。Wine 的注册表配置也很关键。默认的 Wine 前缀prefix里有些设置会导致游戏无法启动# 创建 64 位前缀 WINEARCHwin64 WINEPREFIX~/.wine-madeira winecfg # 关键注册表项 wine reg add HKCU\\Software\\Wine\\Direct3D /v renderer /t REG_SZ /d metal /f wine reg add HKCU\\Software\\Wine\\Direct3D /v csmt /t REG_DWORD /d 1 /frenderermetal告诉 Wine 用 Metal 后端配合 DXMTcsmt1开启命令流多线程对多核设备有性能提升。注意Wine 的版本选择很重要。太新的版本可能引入了对 FEX-Emu 不友好的特性太老的版本又缺 DXMT 需要的接口。建议用 Wine 8.x 或 9.x 的稳定分支配合对应版本的 DXMT。3.2 FEX-Emu 的 RootFS 与 Thunk 配置FEX-Emu 的 RootFS 是一个 x86-64 的 Linux 根文件系统里面包含了 Wine、必要的 DLL 和库。在 Linux 上FEX-Emu 直接用 binfmt_misc 注册运行 x86 程序时自动调用 FEX。但在 iOS 上没有 binfmt_misc得手动调用FEXRootFSFetcher # 下载 RootFS FEXLoader /path/to/x86_64/binaryFEX-Emu 的配置文件~/.fex-emu/Config.json里几个关键项{ RootFS: /path/to/rootfs, Thunk: { HostLibs: [libMetal.so, libAudioToolbox.so], GuestLibs: [libwine-metal.so] }, CPU: { Core: 0, SMCChecks: mtrack } }Thunk.HostLibs列出允许 x86 代码直接调用的 ARM64 宿主库。Metal 和 AudioToolbox 是必须的否则图形和声音没法走原生路径。SMCChecks自修改代码检测策略。mtrack是较快的模式但某些加壳程序可能需要full模式。Thunk 机制是 FEX-Emu 性能的关键。没有 Thunk 的话x86 代码调用 Metal 得走“x86→翻译→ARM64→系统调用”这条长链路有了 Thunk 就是“x86→直接跳转 ARM64 函数”省掉大量开销。3.3 DXMT 的编译与 D3D 特性映射DXMT 的编译依赖 Metal 框架和 Xcode 命令行工具。在 macOS 上编译相对直接git clone https://github.com/3Shain/dxmt cd dxmt meson setup build --cross-file build-win64.txt ninja -C build编译产物是d3d11.dll、dxgi.dll等替换 Wine 前缀里的对应 DLL 即可。DXMT 对 D3D 特性的支持情况需要心里有数D3D 特性DXMT 支持备注D3D11 基础渲染完整大部分游戏能跑计算着色器部分复杂 compute 可能有问题几何着色器部分依赖 Metal 的对应功能纹理压缩 (BCn)完整Metal 原生支持多重采样 (MSAA)完整光线追踪不支持Metal RT 接口不同实操心得DXMT 的日志级别可以通过环境变量DXMT_LOG_LEVELdebug打开排查图形问题时非常有用。日志会显示每个 D3D 调用映射到了哪个 Metal 调用能快速定位是哪个特性没实现。4. 实操流程从零搭一套 Madeira 运行环境4.1 环境准备与依赖安装假设你在 macOS 上做开发验证iOS 设备上的部署后面单独说需要准备macOS 13Xcode 15Homebrew 包管理器Python 3.10FEX-Emu 的构建脚本用 PythonCMake 3.20、Ninja、Meson。brew install cmake ninja meson python3.11 xcode-select --installFEX-Emu 的编译需要 LLVM 和 Clang建议用 Homebrew 的 LLVMbrew install llvm export CC$(brew --prefix llvm)/bin/clang export CXX$(brew --prefix llvm)/bin/clang4.2 编译 FEX-Emu 并生成 RootFSgit clone https://github.com/FEX-Emu/FEX.git cd FEX git submodule update --init --recursive mkdir build cd build cmake .. -DCMAKE_BUILD_TYPERelease \ -DENABLE_LTOTrue \ -DCMAKE_INSTALL_PREFIX~/fex-install make -j$(sysctl -n hw.ncpu) make install编译完成后用FEXRootFSFetcher下载 RootFS~/fex-install/bin/FEXRootFSFetcher # 选择 Ubuntu 22.04 x86-64 RootFSRootFS 会下载到~/.fex-emu/RootFS/下。这个 RootFS 里已经包含了 Wine 和基本的 x86-64 库可以直接用。4.3 配置 Wine 前缀并安装 DXMTexport FEX_ROOTFS~/.fex-emu/RootFS/Ubuntu_22_04 export WINEPREFIX~/.wine-madeira export WINEARCHwin64 # 用 FEX 加载 RootFS 里的 Wine ~/fex-install/bin/FEXLoader $FEX_ROOTFS/usr/bin/wine winecfgwinecfg能正常弹出窗口说明 Wine 和 FEX 的链路通了。接下来把 DXMT 的 DLL 复制进去cp dxmt/build/d3d11.dll $WINEPREFIX/drive_c/windows/system32/ cp dxmt/build/dxgi.dll $WINEPREFIX/drive_c/windows/system32/ cp dxmt/build/d3d10core.dll $WINEPREFIX/drive_c/windows/system32/然后设置 DLL 覆盖让 Wine 优先加载 DXMT 而不是自带的 WineD3DWINEDLLOVERRIDESd3d11,dxgi,d3d10coren wine regedit在注册表里把HKEY_CURRENT_USER\Software\Wine\DllOverrides下这几个 DLL 设为native。4.4 运行第一个 Windows 程序验证链路找一个简单的 D3D11 程序测试比如 3DMark 的某个老版本或者自己写一个最小的 D3D11 三角形程序。运行FEXLoader $FEX_ROOTFS/usr/bin/wine /path/to/test.exe如果能看到窗口并且渲染正常说明整条链路FEX 翻译 Wine API DXMT 图形都通了。如果黑屏或者崩溃按下面的排查流程走。4.5 iOS 设备上的部署差异在 iOS 上部署和 macOS 上有几个关键差异JIT 权限需要设备越狱或者开启开发者模式下的 JIT 权限。非越狱设备基本只能跑解释模式性能会差很多。文件系统路径iOS 沙盒内没有/usr/bin所有路径要映射到应用沙盒的Documents或Library目录。Metal 设备创建DXMT 创建 Metal 设备时iOS 上要用MTLCreateSystemDefaultDevice()不能指定特定 GPU。音频后端iOS 用 AudioToolbox 而不是 ALSA/PulseAudioWine 的音频驱动要换成 CoreAudio 版本。这部分适配工作量很大也是 Madeira 这类项目最核心的工程难点。如果你只是想在 macOS 上验证技术链路前面的步骤就够了如果要上 iOS 设备需要额外的 Darwin 适配层。5. 常见问题与排查技巧实录5.1 Wine 乱码问题“wine 乱码”是高频问题表现是程序界面文字显示成方块或问号。原因通常是字体缺失或编码不匹配。排查步骤检查 Wine 前缀里有没有中文字体ls $WINEPREFIX/drive_c/windows/Fonts/如果没有simsun.ttc或msyh.ttf从 Windows 系统复制或者用开源的思源黑体替代。检查注册表里的字体替换wine reg add HKCU\\Software\\Wine\\Fonts\\Replacements /v MS Shell Dlg /t REG_SZ /d SimSun /f如果是终端输出乱码设置LANGzh_CN.UTF-8和LC_ALLzh_CN.UTF-8。实操心得Wine 的字体问题很多时候不是缺字体而是字体链接font link没配好。在注册表HKCU\Software\Wine\Fonts\Replacements里把常用的 Windows 字体名映射到实际存在的字体能解决大部分乱码。5.2 FEX-Emu 启动失败或崩溃常见原因和排查方向现象可能原因排查方法提示找不到 RootFSRootFS 路径配置错误检查~/.fex-emu/Config.json里的RootFS启动即崩溃JIT 权限不足iOS 上确认已开启 JITmacOS 上检查 hardened runtime运行中段错误自修改代码检测失败把SMCChecks改成full试试性能极差走了解释模式检查 FEX 日志里 JIT 是否正常工作FEX 的日志通过FEX_LOG_LEVELdebug打开会输出每条指令的翻译情况。如果看到大量Interpreter而不是JIT说明 JIT 没生效。5.3 DXMT 图形问题图形问题最直观黑屏、花屏、闪退、帧率低。黑屏先看 DXMT 日志确认 D3D 设备创建是否成功。如果CreateDevice失败可能是 Metal 设备创建有问题。花屏通常是纹理格式不匹配。DXMT 日志里会显示哪个纹理格式没映射成功对照 Metal 的MTLPixelFormat检查。闪退可能是某个 D3D 特性没实现DXMT 直接 abort 了。日志里搜Unimplemented能找到具体是哪个调用。帧率低检查是否走了软件渲染。DXMT 日志里如果有Software adapter说明 Metal 设备没创建成功退化到了软件路径。5.4 iOS 特有的坑开发者模式iOS 16 需要在设置里手动开启开发者模式否则无法安装自签名应用。路径是“设置→隐私与安全性→开发者模式”。证书过期免费开发者证书 7 天过期过期后应用无法启动需要重新签名安装。WebView 限制iOS 的 WKWebView 对自动播放有限制如果 Wine 程序里嵌了网页音频可能无法自动播放。后台限制iOS 应用切到后台很快会被挂起Wine 程序如果依赖后台运行比如下载需要申请后台任务权限。注意iOS 上的 JIT 权限是最大的门槛。没有 JITFEX-Emu 只能跑解释模式性能大概只有 JIT 模式的十分之一到五分之一基本没法跑游戏。所以这类项目目前主要面向越狱设备或企业签名设备。6. 性能调优与进阶技巧6.1 FEX-Emu 的 JIT 缓存优化FEX 的 JIT 会把翻译后的 ARM64 代码缓存到磁盘下次运行同一程序时直接加载缓存省去翻译时间。缓存目录在~/.fex-emu/CodeCache/下。几个优化点增大缓存大小默认缓存上限是 512MB可以在 Config.json 里调大JIT: { CacheSize: 2147483648 }预翻译热点代码FEX 有个FEXOfflineCompiler工具可以提前把程序的代码翻译好存到缓存里首次运行就不需要现场翻译了。多线程 JITFEX 支持多线程翻译在 Config.json 里设置JIT: {Threads: 4}利用多核加速翻译。6.2 DXMT 的 Metal 性能调优DXMT 把 D3D 调用映射到 Metal但 Metal 本身有很多性能选项命令缓冲区模式Metal 有MTLCommandBuffer的三种提交模式DXMT 默认用committed可以改成unretained减少引用计数开销。资源存储模式Metal 的MTLStorageMode有shared、private、managed三种。iOS 上只有shared和private纹理用private性能更好但需要 blit 拷贝。管线缓存Metal 的管线状态对象PSO创建很耗时DXMT 会把 PSO 缓存到磁盘下次直接加载。这些优化在 DXMT 的源码里都有对应配置需要根据具体游戏调整。6.3 内存管理与 OOM 规避iOS 设备的内存比桌面少很多Wine 程序如果内存占用大很容易被系统杀掉。几个应对策略限制 Wine 的堆大小通过WINEMAXMEM环境变量限制 Wine 能用的最大内存。启用内存压缩iOS 有内存压缩机制但 Wine 程序的大块分配可能绕过这个机制。可以在 FEX 层面做内存映射的优化。及时释放纹理DXMT 里对不再使用的 Metal 纹理要及时释放否则显存在 iOS 上是统一内存很快耗尽。7. 这套方案的边界与后续扩展方向Madeira 这类项目目前能跑什么、不能跑什么心里要有数能跑的老式 2D 游戏和轻量 3D 游戏D3D9 时代的大多数办公类 Windows 程序如果 Wine 的 API 覆盖够自己写的小型 D3D11 测试程序。跑不动的需要 D3D12 或光追的现代 3A依赖内核态驱动或反作弊的程序对时序要求极高的音视频应用。后续可以扩展的方向D3D12 支持DXMT 目前主要覆盖 D3D11D3D12 的映射工作量更大但 Metal 3 的特性足够支撑。Vulkan 后端除了 DXMT也可以走 DXVKMoltenVK 路线两条路各有优劣可以根据游戏适配情况切换。Android 适配同样的架构在 Android 上也能跑只是宿主从 Darwin 换成 Linux适配工作量小很多。云游戏整合本地跑不动的游戏可以结合串流方案把重负载放到远端。我在实际折腾这套链路的过程中最大的体会是瓶颈往往不在翻译层本身而在系统调用的适配和图形驱动的细节。FEX-Emu 的指令翻译已经相当成熟Wine 的 API 覆盖也很广真正卡住的是 iOS 沙盒、JIT 权限、Metal 特性这些平台特有的约束。所以如果你要入坑建议先在 macOS 上把整条链路跑通确认 WineFEXDXMT 能正常工作再往 iOS 上迁移。这样排查问题时能快速定位是平台适配的问题还是组件本身的问题。另外一个小技巧FEX-Emu 和 DXMT 的日志一定要开而且要看。这两个组件的日志信息量很大但关键错误往往就在前几行。养成“先看日志再动手”的习惯能省掉大量瞎试的时间。