1. 从Madeira这个名字说起一个跨平台兼容层的真实需求第一次看到Madeira这个项目名很多人会以为是某个度假岛屿或者葡萄酒品牌——毕竟马德拉岛确实以加强型葡萄酒出名。但放在当前的技术语境里结合 Wine、FEX-Emu、DXMT、x86-64 这些关键词它指向的其实是一个非常具体的方向在非 x86 架构的平台上把 Windows 应用和游戏跑起来。这个需求不是凭空冒出来的。过去几年ARM 架构的设备性能突飞猛进Apple Silicon 的 Mac、高通骁龙 X Elite 的笔记本、各种 ARM 服务器和掌机层出不穷。但问题在于大量存量软件——尤其是 Windows 生态里的游戏、行业工具、老版本专业软件——依然是 x86-64 指令集编译的。你不可能要求所有开发者重新编译一遍于是翻译层就成了刚需。Madeira 在这个背景下扮演的角色可以理解为一个整合层或者发行版性质的项目它把几块原本各自为战的技术拼在一起让普通用户不用自己去折腾编译参数和依赖关系。这几块技术分别是Wine负责把 Windows 的 API 调用翻译成 POSIX 系统调用解决软件以为自己在 Windows 上的问题FEX-Emu负责把 x86-64 指令翻译成 ARM64 指令解决CPU 看不懂这些机器码的问题DXMT负责把 Direct3D 调用翻译成 Metal解决图形 API 对不上的问题。这三者缺一不可。Wine 再强遇到 x86-64 的二进制它也没法直接执行FEX-Emu 能翻译指令但如果没有 Wine 提供 Windows 运行时环境程序连启动都启动不了而 DXMT 则是让游戏画面能真正显示出来的最后一环。我之所以对这个方向感兴趣是因为过去半年我一直在折腾 ARM 设备上跑 Windows 游戏这件事。踩过的坑包括但不限于Wine 中文全是乱码、Gecko 组件下载失败导致安装程序卡死、DXMT 版本和 Wine 版本对不上导致黑屏。这些问题在官方文档里往往一笔带过但在实际操作中每一个都能让你卡上大半天。下面我把这些经验系统地整理出来希望能帮到同样在这条路上摸索的人。提示本文讨论的是在合法拥有软件授权的前提下于非 Windows 平台上运行自己已有的 Windows 程序属于个人技术研究范畴。请确保你的使用场景符合相关软件的许可协议。2. Wine 在 ARM 上的真实工作链路不只是装个兼容层那么简单2.1 Wine 到底翻译了什么没翻译什么很多人对 Wine 有个误解以为它是个模拟器。其实 Wine 的全称是 Wine Is Not an Emulator它做的是API 层面的翻译不是指令层面的模拟。具体来说当一个 Windows 程序调用CreateFileW这个 API 时Wine 会拦截这个调用然后转成 Linux 或 macOS 上的open()系统调用。程序本身还是以原生指令在 CPU 上跑的。这就带来一个关键结论Wine 本身不解决 CPU 架构不匹配的问题。在 x86-64 的 Linux 上Wine 可以直接跑 x86-64 的 Windows 程序因为指令集是一样的。但在 ARM64 设备上Windows 程序是 x86-64 机器码CPU 根本执行不了这时候就必须有 FEX-Emu 这样的指令翻译层介入。所以完整的链路是这样的Windows 程序 (x86-64 机器码) ↓ 由 FEX-Emu 翻译指令 ARM64 机器码 ↓ 调用 Windows API Wine 拦截并翻译成 POSIX 调用 ↓ 图形调用 DXMT 把 D3D 翻译成 Metal ↓ 屏幕显示理解这个链路非常重要因为它决定了你排查问题的方向。比如程序启动就崩溃可能是 FEX-Emu 的指令翻译出了问题程序能启动但界面乱码那是 Wine 的字体和区域设置问题程序能跑但画面黑屏那大概率是 DXMT 或图形驱动的问题。不同环节的症状完全不同盲目换版本只会浪费时间。2.2 FEX-Emu 的配置要点为什么你的程序跑得比别人慢FEX-Emu 的默认配置是偏向兼容性的性能上会保守一些。我在实际使用中发现几个能明显提升体验的调整点第一是TSOTotal Store Ordering模式。x86 架构的内存模型比 ARM 强为了保证多线程程序的正确性FEX-Emu 默认会开启 TSO 模拟这会带来性能损耗。如果你的程序是单线程的或者对内存顺序不敏感可以尝试关闭 TSO 来换取性能。但要注意关闭 TSO 可能导致某些多线程程序出现难以复现的崩溃所以游戏类应用建议保持默认。第二是JIT 缓存。FEX-Emu 会把翻译过的代码缓存起来第二次运行同一个程序时会快很多。缓存目录默认在~/.cache/fex-emu/下如果你发现某个程序第一次跑特别慢、后面就正常了这是正常现象。但如果缓存目录所在的分区空间不足缓存写入失败程序就会一直很慢。我建议把这个目录放在 SSD 上并且预留至少几个 GB 的空间。第三是多线程编译。FEX-Emu 在首次翻译大程序时会占用大量 CPU如果你在同时跑其他任务会感觉整个系统卡顿。可以在配置里限制它使用的核心数牺牲一点启动速度换取系统响应性。2.3 Wine 前缀Prefix的管理别把所有程序塞进一个瓶子Wine 的 prefix 机制是很多人忽略的重点。默认情况下所有程序都装在~/.wine这一个前缀里时间长了会互相污染——某个程序装的运行库可能和另一个程序冲突注册表也会越来越乱。我的做法是按用途分前缀游戏一个、办公软件一个、开发工具一个。创建新前缀的命令很简单WINEPREFIX~/.wine-games winecfg这条命令会创建一个新的前缀并打开配置界面。之后运行程序时都要带上WINEPREFIX环境变量或者写个脚本封装起来。分前缀的好处是隔离性好某个前缀玩坏了直接删掉重建不影响其他程序。代价是每个前缀都要单独装运行库磁盘占用会翻倍。对于 SSD 空间紧张的用户可以只给游戏分独立前缀其他程序共用一个。注意删除前缀前一定要确认里面没有你需要的数据。有些程序的存档和配置就存在 prefix 里删了就找不回来了。3. 中文乱码、Gecko 缺失、DXMT 黑屏三个高频坑的完整排查链路3.1 Wine 中文乱码从字体缺失到区域设置的逐层定位Wine 中文乱码是我遇到最多的求助问题症状通常是程序界面能显示但所有中文都变成了方块或者问号。这个问题的根因有好几层需要逐层排查。第一层系统字体缺失。Wine 本身不带中文字体它会去调用系统字体。如果你的系统没装中文字体Wine 自然找不到。解决办法是安装一套完整的中文字体比如思源黑体或者文泉驿。装完之后Wine 需要重新扫描字体缓存可以删除~/.cache/wine/下的字体缓存文件让它重建。第二层Wine 的字体替换规则。即使系统有中文字体Wine 也未必知道该用哪个字体来替换 Windows 的宋体、黑体。这需要在注册表里配置字体替换。具体路径是HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\FontSubstitutes把SimSun、SimHei这些映射到系统里实际存在的中文字体。第三层区域设置Locale。如果 Wine 的 locale 是en_US.UTF-8某些程序会认为当前环境不支持中文从而不加载中文字体。把 locale 设成zh_CN.UTF-8往往能解决一部分问题。但要注意locale 设置会影响程序的日期、货币格式有些游戏会因为区域不对而出现奇怪的显示需要权衡。第四层程序自带的字体。有些程序会把字体打包在自己的目录里这种情况下乱码可能是字体文件本身损坏或者版本不兼容。可以尝试用winetricks安装corefonts和cjkfonts来补齐。排查顺序建议从第一层开始逐层往上。我见过太多人一上来就改注册表结果发现只是系统没装中文字体白白折腾半天。3.2 Gecko 和 Mono 组件下载失败离线安装的正确姿势Wine 在首次运行某些程序时会提示安装 Gecko用于 HTML 渲染和 Mono用于 .NET 支持。这两个组件体积不小而且下载源在国外网络不好的时候经常卡住或者失败。失败的表现是程序启动时弹出一个对话框说 Gecko 安装失败然后程序要么卡死要么直接退出。更麻烦的是有些程序不会明确告诉你缺了 Gecko只是默默地不显示某些界面。解决办法是提前离线安装。Gecko 和 Mono 的安装包可以从 Wine 的官方发布渠道获取下载对应版本的.msi文件后用下面的命令安装WINEPREFIX~/.wine wine msiexec /i wine-gecko-xxx.msi WINEPREFIX~/.wine wine msiexec /i wine-mono-xxx.msi版本号必须和你的 Wine 版本匹配否则装了也没用。可以在 Wine 的安装目录下找到它期望的版本号通常在share/wine/wine.inf文件里能看到。提示如果你用的是发行版打包的 WineGecko 和 Mono 可能已经被打包成独立的系统包直接通过包管理器安装即可不需要手动下载 msi。3.3 DXMT 黑屏与花屏版本匹配和图形后端选择DXMT 是把 Direct3D 翻译成 Metal 的组件主要用在 macOS 上。它的黑屏问题通常有三个原因原因一DXMT 版本和 Wine 版本不匹配。DXMT 是作为 Wine 的一个模块加载的接口必须对得上。如果你用的是自己编译的 WineDXMT 也要用对应版本编译。用发行版 Wine 的话要确认 DXMT 的发布说明里写明了支持的 Wine 版本范围。原因二图形后端选择错误。DXMT 支持多种 Metal 后端配置有些游戏在默认配置下会黑屏但切换到另一个后端就正常了。这个需要在 DXMT 的配置文件里调整具体参数因版本而异建议查阅对应版本的文档。原因三游戏本身用了 DXMT 不支持的 D3D 特性。DXMT 对 D3D 的覆盖不是 100% 的某些高级特性比如特定的着色器模型或者纹理格式可能还没实现。这种情况下只能等 DXMT 更新或者换用其他翻译方案。排查黑屏问题时建议先开 Wine 的调试输出看看有没有 DXMT 相关的报错。命令大概是WINEPREFIX~/.wine WINEDEBUGdxmt wine your_game.exe日志里如果出现 unsupported 或者 failed to create 之类的字样基本就能定位到问题所在。4. 从 Wine 到 iOS跨平台兼容思路的延伸与边界4.1 为什么 iOS 上的兼容是另一套逻辑热词里出现了不少 iOS 相关的内容比如 iOS 开发者模式、Xcode 打包、iOS 原生插件、WebView 自动播放等。这些和 Wine 看似不相关但背后的思路有相通之处都是在受限环境里想办法让程序跑起来。不过 iOS 的情况和桌面 Linux/macOS 完全不同。iOS 是封闭系统不允许用户自行安装未经签名的可执行文件也不允许应用动态加载外部代码。这意味着 Wine 那套拦截 API 调用的思路在 iOS 上基本行不通——你没法在系统层面做翻译只能在应用内部做文章。所以 iOS 上所谓的兼容通常是指这几种情况WebView 里跑 Web 应用这是最常见的用 WKWebView 加载网页本质上还是 Web 技术栈应用内嵌模拟器比如某些复古游戏模拟器它们把模拟器核心打包进 App在应用内部运行远程串流把计算放在远端iOS 设备只负责显示和输入。这几种方案各有各的限制。WebView 方案受限于浏览器的能力比如热词里提到的抖音 iOS WebView 不能自动播放就是 WebView 的自动播放策略导致的需要用户交互才能触发播放。模拟器方案则受限于 App Store 的审核政策很多类型的模拟器是不允许上架的。4.2 iOS 开发者模式与真机调试的实际门槛热词里iOS 开发者模式和iOS 26.3.1 怎么开发者模式出现频率很高说明很多人在真机调试这一步卡住了。这里简单说一下流程避免大家走弯路。从 iOS 16 开始苹果把开发者模式做成了一个需要手动开启的开关位置在设置 - 隐私与安全性 - 开发者模式。但这个开关默认是隐藏的只有当你把设备连接到 Xcode 或者安装了带有开发者签名的应用之后它才会出现。开启开发者模式后设备会重启重启后需要再次确认。这个设计是为了防止普通用户误装恶意应用但对开发者来说确实多了一步。真机调试还需要处理证书和描述文件的问题。免费账号可以申请个人开发证书但签名的应用只有 7 天有效期过期后需要重新签名。付费开发者账号每年 99 美元可以申请有效期一年的证书并且可以上架 App Store。热词里提到的xcode 从证书配置到上架全流程和xcode 打包 iOS 突然很慢如何解决都是这个环节的典型问题。打包慢通常是因为 Xcode 在重新编译所有依赖可以尝试清理 DerivedData 目录或者检查是不是开了过多的编译优化选项。4.3 跨平台项目的通用经验隔离、版本锁定、日志先行不管是 Wine 还是 iOS 开发我在跨平台项目里总结出三条通用经验这里分享出来第一环境隔离。Wine 用 prefix 隔离iOS 用虚拟环境或者容器隔离Python 用 venv 隔离。隔离的核心目的是让不同项目的依赖互不干扰出问题时可以快速回滚。第二版本锁定。Wine 和 DXMT 的版本必须匹配Xcode 和 iOS SDK 的版本必须匹配任何跨平台工具链都有版本兼容性矩阵。我习惯把每个项目的工具链版本记录在一个文档里升级时对照着来避免升了一个组件结果全崩了。第三日志先行。跨平台问题的排查难度远高于单平台因为中间隔了好几层翻译。所以一定要养成开日志的习惯Wine 用WINEDEBUGiOS 用 Xcode 的控制台把日志级别调到能看到警告和错误。很多问题在日志里其实写得很清楚只是默认不显示。5. 实操复盘一次完整的 ARM 设备跑 Windows 游戏配置记录5.1 环境准备与组件版本选择下面记录一次我在 ARM64 Linux 设备上配置 Windows 游戏的完整过程供参考。设备是某款 ARM 笔记本系统是 Ubuntu 24.04 ARM64 版。组件版本选择如下组件版本选择理由Wine9.x 稳定版新版本对 D3D 支持更好且 Gecko/Mono 打包完整FEX-Emu最新稳定版指令翻译性能优化明显支持 JIT 缓存DXMT与 Wine 匹配的版本版本不匹配会直接黑屏中文字体思源黑体 文泉驿覆盖大部分中文显示需求安装顺序很重要先装 FEX-Emu再装 Wine最后配置 DXMT。因为 Wine 在编译时会检测 FEX-Emu 的存在顺序反了可能导致 Wine 没有启用 x86-64 翻译支持。5.2 逐步配置与验证第一步安装 FEX-Emu 并验证fex-emu --version确认版本号正常输出。然后创建一个测试用的 x86-64 程序用 FEX-Emu 跑一下确认指令翻译正常工作。第二步安装 Wine 并创建独立前缀WINEPREFIX~/.wine-game winecfg在配置界面里把 Windows 版本设成 Windows 10把图形驱动设成 DXMT 对应的选项。这一步如果 DXMT 没装好图形驱动选项里不会出现相关条目。第三步安装中文字体和运行库winetricks corefonts cjkfonts vcrun2019 dotnet48vcrun2019和dotnet48是很多游戏和工具的必备运行库提前装上能省去后面反复弹窗的麻烦。第四步安装 Gecko 和 Mono如果 Wine 没有自动装WINEPREFIX~/.wine-game wine msiexec /i /path/to/wine-gecko.msi WINEPREFIX~/.wine-game wine msiexec /i /path/to/wine-mono.msi第五步运行游戏并观察日志WINEPREFIX~/.wine-game WINEDEBUGdxmt,d3d wine game.exe 21 | tee game.log第一次运行会比较慢因为 FEX-Emu 在翻译指令。等 JIT 缓存建立起来之后第二次运行会快很多。5.3 实测中遇到的意外与处理实测过程中遇到了几个预料之外的问题记录如下问题一游戏启动后没有声音。排查发现是 Wine 的音频后端默认用了 PulseAudio但系统实际用的是 PipeWire。在 winecfg 里把音频驱动改成 PipeWire 对应的选项后解决。问题二手柄识别不了。游戏能识别键盘但识别不了手柄。这是因为 Wine 需要额外的驱动来映射 Linux 的输入设备。装了winetricks xinput之后手柄正常识别。问题三帧率不稳定偶尔卡顿。观察发现是 FEX-Emu 的 JIT 缓存在写入时占用了磁盘 IO。把缓存目录移到内存盘tmpfs后卡顿明显减少。但要注意内存盘重启后数据会丢失每次重启都要重新建立缓存。问题四游戏内中文显示为方块。按照前面 3.1 节的排查链路最终定位到是游戏自带的字体文件在 ARM 上渲染有问题。用 winetricks 强制替换字体后解决。这些问题在官方文档里基本找不到都是靠开日志、逐层排查、反复试错才解决的。我把它们记录下来就是希望后来者能少走一些弯路。6. 关于跨平台兼容我个人的几点体会折腾了这么久我最大的感受是跨平台兼容没有银弹只有权衡。Wine FEX-Emu DXMT 这套组合能解决大部分问题但它不是万能的。有些程序就是跑不起来有些能跑但性能损失很大有些今天能跑明天更新一下就崩了。所以我的建议是先确认你的核心需求是什么。如果只是偶尔用某个 Windows 软件可能远程桌面或者虚拟机是更省心的选择。如果是要长期跑游戏那就要做好持续维护的心理准备因为工具链更新频繁每次更新都可能带来新的问题。另外社区的力量很重要。Wine、FEX-Emu、DXMT 都是开源项目遇到问题去对应的 issue 区搜一搜往往能找到别人已经踩过的坑。我上面记录的很多解决方案其实都是从社区讨论里学来的只是整理成了更系统的形式。最后分享一个小技巧给每个游戏单独建一个启动脚本把 WINEPREFIX、WINEDEBUG、FEX-Emu 的配置都写进去。这样启动游戏时不用记一堆环境变量也方便针对不同游戏做不同的优化配置。脚本大概长这样#!/bin/bash export WINEPREFIX~/.wine-game-xxx export WINEDEBUG-all export FEX_TSOENABLED1 cd $WINEPREFIX/drive_c/Program Files/Game wine game.exe $把WINEDEBUG设成-all可以关闭调试输出减少性能开销。需要排查问题时再临时改成dxmt,d3d之类的。这个脚本放在桌面或者 PATH 里用起来就很顺手了。