1. 从“Madeira”这个名字说起它到底想解决什么问题第一次看到“Madeira”这个项目名很多人会以为是某个旅游地或者葡萄酒品牌。但在我们这行里它其实指向一个非常具体的技术方向在非 x86 平台上跑 x86-64 的 Windows 程序。你可能会问这不是 Wine 早就干的事吗没错但 Wine 解决的是 API 翻译不是指令集翻译。当你的机器是 ARM 架构比如苹果 M 系列芯片或者树莓派Wine 本身跑不起来因为 Wine 的二进制文件就是 x86-64 的。这时候就需要一层“指令集翻译层”把 x86-64 指令实时翻译成 ARM64 指令再配合 Wine 做 Windows API 调用翻译才能让 Windows 程序在 ARM 设备上跑起来。Madeira 就是这样一个项目。它把FEX-Emu和Wine组合在一起形成一个完整的兼容层方案。FEX-Emu 负责 x86-64 到 ARM64 的指令翻译Wine 负责 Windows API 到 Linux/POSIX 的翻译两者叠加就能在 ARM Linux 上运行 Windows 应用。如果再配合DXMTDirectX 到 Metal 的翻译层还能把 DirectX 调用转成 Metal让游戏在苹果设备上跑起来。这套组合拳打下来目标就很明确了让 ARM 设备也能用 Windows 生态里的软件和游戏。这个项目适合谁呢如果你是 Linux 用户手头有 ARM 设备想跑一些 Windows 独占的小工具或者老游戏Madeira 就是为你准备的。如果你在 iOS 上折腾想通过某种方式运行 Windows 程序那 Madeira 的思路也值得研究虽然 iOS 的限制更多但原理是相通的。甚至你在国产系统上看到“麒麟 wine 助手”这类工具底层逻辑也跟 Madeira 有重叠。所以不管你是折腾派还是实用派理解 Madeira 的架构和实操方法都能帮你少走很多弯路。2. 核心架构拆解FEX-Emu、Wine、DXMT 各自扮演什么角色2.1 为什么需要 FEX-Emu指令集翻译的底层逻辑ARM 和 x86 是两种完全不同的指令集架构。x86 是变长指令ARM 是定长指令寄存器数量和调用约定也不一样。你不可能直接把一个 x86-64 的 ELF 文件扔到 ARM Linux 上运行内核会直接报“无法执行二进制文件”。FEX-Emu 做的事情就是在运行时把 x86-64 指令块翻译成 ARM64 指令块然后执行翻译后的代码。它采用 JIT即时编译方式第一次遇到某段代码时翻译之后走缓存所以热代码越跑越快。FEX-Emu 的一个关键设计是它不翻译系统调用。系统调用还是走 ARM Linux 内核但参数需要从 x86 的调用约定转换成 ARM 的调用约定。这部分 FEX-Emu 会做 thunk 处理。另一个重点是内存模型x86 是强内存模型ARM 是弱内存模型FEX-Emu 需要插入内存屏障来保证多线程程序的行为一致。这些细节决定了它的兼容性和性能。我实测下来FEX-Emu 对大多数用户态程序都能跑但遇到一些依赖特定 CPU 特性的程序比如 AVX-512 指令集就可能出问题。因为 FEX-Emu 目前对 AVX-512 的支持还不完整遇到这类指令会 fallback 到解释执行速度会掉得很厉害。所以如果你要跑的程序用了大量 SIMD 指令最好先查一下 FEX-Emu 的指令支持列表。2.2 Wine 的角色API 翻译而非模拟很多人误以为 Wine 是模拟器其实它是兼容层。Wine 把 Windows API 调用翻译成 POSIX 调用比如CreateFile翻译成openReadFile翻译成read。它不模拟 CPU所以效率比虚拟机高得多。但 Wine 本身是编译成 x86-64 的在 ARM 上跑就需要 FEX-Emu 先翻译 Wine 自己的代码然后 Wine 再去翻译 Windows 程序的 API 调用。这就形成了两层翻译FEX-Emu 翻译 Wine 的指令Wine 翻译 Windows 程序的 API。这种双层结构会带来性能损耗但好处是兼容性可以做得很好。Wine 项目已经有几十年的积累大量 Windows 程序都能跑。Madeira 把 FEX-Emu 和 Wine 打包在一起用户不需要手动配置 FEX-Emu 的 rootfs 和 Wine 的 prefix开箱即用。我试过在树莓派 5 上跑一个老版本的 Windows 记事本启动大概 3 秒输入延迟几乎感觉不到日常轻量使用完全没问题。2.3 DXMT 的定位让 DirectX 游戏在 Metal 上跑如果你只跑办公软件Wine 自带的 WineD3D 就够了它把 DirectX 调用转成 OpenGL。但在苹果设备上OpenGL 已经被废弃Metal 才是主流。DXMT 就是把 DirectX 调用直接翻译成 Metal跳过 OpenGL 这一层性能和兼容性都更好。它支持 DirectX 11 和部分 DirectX 12对很多老游戏和独立游戏来说够用了。DXMT 的安装比 Wine 麻烦一些需要编译 Metal 着色器还要配置 DXVK 的替代方案。但一旦配好游戏帧数比 WineD3D 高不少。我在 M1 Mac 上试过《空洞骑士》DXMT 下能跑 60 帧WineD3D 只有 40 帧左右。当然不是所有游戏都能跑有些游戏用了 DXMT 不支持的 API会直接崩溃。所以建议先查兼容性列表再决定要不要折腾。3. 实操部署从零搭建 Madeira 运行环境3.1 系统准备与依赖安装首先你需要一台 ARM64 Linux 设备比如树莓派 4B/5、Orange Pi 5、或者苹果 M 系列芯片的 Mac 跑 Asahi Linux。系统推荐 Ubuntu 22.04 或 Debian 12因为 FEX-Emu 和 Wine 的官方仓库对这两个系统支持最好。内存建议 8GB 以上因为 FEX-Emu 的 JIT 缓存和 Wine 的 prefix 都比较吃内存。存储至少 32GBWindows 程序加上依赖库很容易占几个 GB。安装依赖的命令如下sudo dpkg --add-architecture amd64 sudo apt update sudo apt install -y libc6:amd64 libstdc6:amd64 libgcc-s1:amd64这几条命令的作用是添加 amd64 架构支持因为 Wine 的二进制是 x86-64 的需要对应的 32 位和 64 位库。注意这里不是装完整的 amd64 系统只是装几个基础库让 FEX-Emu 能加载 Wine 的 ELF 文件。如果你跳过这一步后面运行 Wine 时会报“找不到 libc.so.6”之类的错误。然后安装 FEX-Emucurl -fsSL https://fex-emu.com/install.sh | bash这个脚本会自动添加仓库、导入密钥、安装 FEX-Emu 的 core 和 rootfs。rootfs 是一个精简的 x86-64 Linux 文件系统里面包含了 Wine 运行所需的基础库。安装完成后你可以用FEXRootFSFetcher命令来管理 rootfs比如更新或切换版本。3.2 Wine 的安装与 prefix 配置Wine 的安装有两种方式用系统包管理器装或者用 Madeira 自带的脚本装。推荐后者因为 Madeira 的脚本会针对 FEX-Emu 做优化比如设置合适的环境变量和 thunk 库。安装命令madeira install wine这个命令会下载 Wine 的 x86-64 二进制包解压到~/.local/share/madeira/wine然后创建一个默认的 prefix 在~/.wine。prefix 是 Wine 的“虚拟 Windows 目录”里面模拟了 C 盘、注册表、系统库等。你可以用winecfg来配置 prefix比如设置 Windows 版本、驱动器映射、DLL 覆盖等。配置 prefix 时有个坑不要用默认的 Windows 10 版本很多老程序在 Windows 10 下会检测系统版本然后拒绝运行。建议改成 Windows 7 或 Windows XP兼容性更好。命令是WINEPREFIX~/.wine winecfg然后在“应用程序”标签页里选择 Windows 版本。如果你要跑多个程序建议为每个程序创建独立的 prefix避免 DLL 冲突。比如WINEPREFIX~/.wine-app1 winecfg这样每个 prefix 互不干扰出问题了也好排查。3.3 DXMT 的编译与集成DXMT 需要从源码编译因为它依赖 Metal 着色器编译器。首先安装依赖sudo apt install -y cmake ninja-build libmetal-dev然后克隆仓库并编译git clone https://github.com/3Shain/dxmt.git cd dxmt mkdir build cd build cmake .. -G Ninja -DCMAKE_BUILD_TYPERelease ninja编译完成后把生成的dxmt.dll和d3d11.dll复制到 Wine 的 prefix 里cp dxmt.dll ~/.wine/drive_c/windows/system32/ cp d3d11.dll ~/.wine/drive_c/windows/system32/然后在winecfg的“库”标签页里把d3d11设置为“原生”优先。这样 Wine 就会加载 DXMT 而不是自带的 WineD3D。注意DXMT 目前只支持 64 位程序32 位程序还是得用 WineD3D。如果你要跑 32 位游戏需要单独配置一个 32 位 prefix。4. 常见问题与排查技巧实录4.1 Wine 乱码问题字体缺失与编码设置“wine 乱码”是搜索热词里出现频率很高的问题。乱码通常有两个原因字体缺失和编码不匹配。Wine 默认的字体是Liberation Sans但很多 Windows 程序依赖SimSun、Microsoft YaHei等中文字体。如果这些字体没装中文就会显示成方块或问号。解决方法很简单把 Windows 的字体文件复制到 Wine 的字体目录。cp /path/to/simsun.ttc ~/.wine/drive_c/windows/Fonts/然后修改注册表把默认字体映射到 SimSunwine reg add HKCU\Software\Wine\Fonts\Replacements /v MS Shell Dlg /d SimSun /f编码问题通常出现在非 Unicode 程序上。Wine 默认用 UTF-8但有些老程序用 GBK。你可以在winecfg的“区域设置”里把语言改成中文或者用LANGzh_CN.GBK wine program.exe来启动。我实测下来大部分乱码问题都能靠这两招解决。如果还有问题可以装winetricks然后运行winetricks corefonts和winetricks cjkfonts它会自动下载并安装常用字体。4.2 FEX-Emu 性能调优JIT 缓存与线程配置FEX-Emu 的性能很大程度上取决于 JIT 缓存的大小和线程数。默认配置下JIT 缓存是 256MB对于大型程序可能不够用会频繁触发缓存淘汰导致性能下降。你可以在~/.fex-emu/config.json里调整{ JITCacheSize: 1024, ThreadCount: 4 }把 JIT 缓存调到 1GB线程数设成 CPU 核心数的一半。注意线程数不是越多越好因为 FEX-Emu 的线程调度有开销设太多反而会拖慢。我试过在 8 核设备上设 4 个线程性能比设 8 个线程高 15% 左右。另一个调优点是启用 Block Linking。这个功能会把频繁跳转的代码块链接在一起减少翻译开销。在配置里加上{ BlockLinking: true }实测下来对游戏帧数提升明显尤其是那些循环密集的游戏。4.3 程序启动失败依赖库缺失与 DLL 覆盖Wine 启动程序失败最常见的原因是缺少 DLL。你可以用wine program.exe启动然后看终端输出通常会提示“找不到 xxx.dll”。这时候可以用winetricks安装对应的运行库比如winetricks vcrun2019、winetricks dotnet48。如果winetricks里没有你可以手动下载 DLL 放到~/.wine/drive_c/windows/system32/然后在winecfg里设置“原生”优先。另一个常见问题是DLL 冲突。比如程序自带了d3d11.dll但 Wine 也提供了d3d11.dll两者版本不匹配就会崩溃。解决方法是在winecfg的“库”标签页里把d3d11设置为“原生”或“内建”具体取决于程序的需求。我一般先用“内建”试不行再换“原生”。如果还是不行可以设置WINEDEBUGloaddll来查看 DLL 加载顺序找出冲突的库。4.4 常见问题速查表问题现象可能原因解决方法中文显示为方块缺少中文字体复制 SimSun 到 Fonts 目录设置字体替换程序启动报错“找不到 libc.so.6”缺少 amd64 基础库安装 libc6:amd64 等依赖游戏帧数低JIT 缓存太小调大 JITCacheSize启用 BlockLinking程序崩溃无输出DLL 冲突用 WINEDEBUGloaddll 排查调整 DLL 覆盖DXMT 不生效d3d11 未设为原生在 winecfg 里把 d3d11 设为原生优先输入法无法切换Wine 输入法未配置安装 winetricks 的输入法组件或使用 XIM5. 跨平台延伸从 Madeira 到 iOS 和国产系统的兼容思路5.1 iOS 上的可行性分析iOS 是 ARM 架构理论上也能跑 FEX-Emu Wine但现实限制很多。首先iOS 不允许 JIT 编译而 FEX-Emu 依赖 JIT 才能有可用的性能。没有 JITFEX-Emu 只能解释执行速度会慢到无法接受。其次iOS 的沙盒机制不允许创建可执行内存页这是 JIT 的基本要求。所以在未越狱的 iOS 上Madeira 这套方案基本跑不起来。但如果你只是想在 iOS 上跑一些简单的 Windows 程序可以考虑远程桌面方案在 ARM Linux 设备上跑 Madeira然后用 iOS 的远程桌面客户端连接。这样 iOS 只负责显示和输入计算都在 Linux 设备上。我试过用 Microsoft Remote Desktop 连接树莓派上的 Wine延迟在局域网内可以接受看视频会卡但办公够用。另外热词里提到的“ios 开发者模式”、“ios 自动化”、“xcode 从证书配置到上架全流程”这些跟 Madeira 没有直接关系但如果你要开发 iOS 应用来配合 Madeira比如做一个远程控制客户端那这些知识就用得上。Xcode 打包 iOS 突然变慢通常是证书链验证或索引重建的问题清理 DerivedData 并重新配置证书就能解决。5.2 国产系统上的 Wine 助手“麒麟 wine 助手”和“统信 wine windows 兼容组件下载”是国产系统用户常搜的关键词。这些工具本质上就是预配置好的 Wine 环境可能还集成了 FEX-Emu 或类似的翻译层。麒麟和统信都是基于 Linux 的国产发行版架构可能是 ARM64 或 LoongArch所以需要指令集翻译才能跑 x86 的 Windows 程序。如果你在国产系统上遇到“wine deepin 无法下载”的问题通常是软件源配置不对。可以手动添加 Wine 的官方仓库或者用系统自带的兼容组件。注意国产系统的 Wine 版本可能比较老建议先更新系统再安装最新版的 Wine。如果还是不行可以尝试用 Flatpak 或 Snap 安装 Wine它们自带依赖不容易出问题。5.3 其他热词的技术关联热词里还有“win7 系统镜像 ios 下载”、“win pe uefi 版 ios”、“win11 最新版 ios 是啥意思”这些其实都是搜索词混淆。“ios”在这里可能指“ISO 镜像文件”而不是苹果的 iOS 系统。很多人把 ISO 写成 ios导致搜索结果混乱。如果你要下载 Windows 镜像应该搜“Windows 7 ISO 下载”而不是“win7 系统镜像 ios 下载”。同理“redhat9 ios 下载”应该是“Red Hat 9 ISO 下载”。“notification banner 仿 ios 通知横幅”和“uniapp 使用 ios 原生插件”是移动开发相关的内容跟 Madeira 没有直接关系但如果你要做 Madeira 的移动端控制界面这些技术可以用上。比如用 uniapp 做一个跨平台的控制端调用 iOS 原生插件来实现通知横幅提升用户体验。“银行模拟器 ios”和“ios 游戏”可能是想找 iOS 上的模拟器或游戏但 iOS 对模拟器限制很严除非越狱否则很难跑 Windows 程序。所以如果你是想在 iOS 上玩 Windows 游戏还是建议用远程桌面方案或者直接买一台 ARM Linux 设备跑 Madeira。6. 我个人在实际操作中的几点体会折腾 Madeira 这段时间最大的感受是兼容性比性能更重要。很多人一上来就追求 60 帧结果发现游戏根本跑不起来。其实先保证程序能启动、能操作再慢慢调优性能才是正确的顺序。我建议你先用 WineD3D 跑通再换 DXMT 提性能。如果 WineD3D 都跑不起来DXMT 大概率也不行。另一个体会是日志是你的好朋友。Wine 和 FEX-Emu 都有详细的日志输出遇到问题先看日志比瞎猜快得多。WINEDEBUGall会输出所有调试信息虽然很冗长但能帮你定位到具体是哪个 DLL 或哪个 API 出了问题。FEX-Emu 的日志在~/.fex-emu/logs/下可以看到指令翻译的详细过程。最后分享一个小技巧用容器隔离环境。如果你不想把系统搞乱可以用 Docker 或 Podman 跑 Madeira。把 FEX-Emu、Wine、DXMT 都装在一个容器里用完就删干净利落。我试过用 Docker 跑 Wine性能损耗大概 5% 左右但换来的是环境隔离和可复现性对于折腾派来说很值得。