1. 从“Madeira”说起一个跨平台兼容项目的整体设计思路“Madeira”这个名字乍一看像是个地名但在跨平台兼容圈子里它代表的是一个把 Windows 应用搬到非 Windows 环境里跑的项目方向。结合热搜词里的 Wine、FEX-Emu、DXMT、iOS、x86-64 这几个关键词基本可以判断出这个项目的核心目标在 ARM 架构的设备上尤其是移动端和嵌入式 Linux 设备上通过多层翻译与兼容技术让原本为 x86-64 Windows 编译的应用程序和游戏能够正常运行。我接触过不少类似的兼容层方案从最早的纯 Wine 到后来的 Box86/Box64再到 FEX-Emu 这种专门做 x86-64 到 ARM64 指令翻译的引擎每一层都有它存在的理由。Madeira 这个项目的思路不是从零造轮子而是把几个成熟组件串起来形成一个完整的运行链路。这个链路大致是这样的最上层是 Windows 应用的 PE 可执行文件往下是 Wine 提供的 Win32 API 实现再往下是 DXMT 负责把 Direct3D 调用翻译成 Metal然后是 FEX-Emu 把 x86-64 指令翻译成 ARM64 指令最后落到实际的 ARM 硬件上执行。为什么这么设计因为单独用 Wine 只能解决 API 层面的兼容解决不了指令集架构的差异。你在 ARM 设备上跑一个 x86-64 的 Windows 程序CPU 根本不认识那些指令。FEX-Emu 就是干这个的它像一个实时翻译官把 x86-64 的机器码逐条翻译成 ARM64 能执行的指令。而 DXMT 解决的是图形 API 的问题Windows 程序调用 Direct3D但 ARM 设备上通常只有 Metal 或 VulkanDXMT 就在中间做转换。这个方案的优势在于模块化。每一层可以独立更新Wine 升级了不影响 FEX-EmuDXMT 优化了也不影响 Wine 的 API 实现。而且这种架构对 iOS 设备特别有意义因为 iOS 设备全是 ARM 架构又不可能直接跑 Windows 程序通过这套组合拳理论上可以让一些 Windows 应用在 iOS 上跑起来。当然实际落地还有很多限制后面会细说。适合谁来参考这个项目我觉得有三类人一是想在 ARM Linux 设备上跑 Windows 应用和游戏的折腾党二是对指令翻译、API 兼容层感兴趣的技术研究者三是想在移动端做 Windows 应用兼容方案的产品开发者。如果你只是想让某个特定 Windows 软件在 Mac 上跑那用 CrossOver 或者 Parallels 更省事Madeira 这套方案更适合愿意折腾、需要深度定制的人。2. 核心组件拆解Wine、FEX-Emu、DXMT 各自扮演什么角色2.1 Wine不只是“模拟器”它是 API 翻译层很多人第一次听到 Wine 会以为它是模拟器其实 Wine 的全称是“Wine Is Not an Emulator”它做的是 API 翻译。Windows 程序调用CreateWindowEx、MessageBox这些 Win32 APIWine 把这些调用翻译成 Linux 或 macOS 上对应的系统调用。它不翻译 CPU 指令所以 Wine 本身不能解决架构差异问题。在 Madeira 项目里Wine 的角色是提供 Windows 运行时环境。它实现了大量的 DLL比如kernel32.dll、user32.dll、gdi32.dll还有ntdll.dll这个核心组件。当 Windows 程序加载时Wine 的加载器会解析 PE 文件格式把程序需要的 DLL 映射到内存里然后开始执行入口点。这里有个关键点Wine 的版本选择很重要。热搜词里出现了“wine 乱码”和“wine 栏是乱码”这通常是因为字体配置或者区域设置不对。Wine 默认可能没有安装中文字体导致界面上的中文显示成方块或乱码。解决办法是在 Wine 的注册表里配置字体替换或者直接把系统的中文字体链接到 Wine 的字体目录。具体操作后面会讲。另一个常见问题是“wine deepin无法下载”和“统信wine windows兼容组件下载”这说明在国内的 Linux 发行版上Wine 的安装和配置有额外的坑。Deepin 和统信 UOS 都有自己的应用商店但商店里的 Wine 版本可能比较旧或者依赖关系没处理好。我的经验是直接去 Wine 的官方仓库或者用发行版自带的包管理器安装不要依赖第三方打包的版本。2.2 FEX-Emux86-64 到 ARM64 的实时翻译引擎FEX-Emu 是这个项目里技术含量最高的部分。它的工作原理是动态二进制翻译当 x86-64 程序执行时FEX-Emu 拦截每一条指令把它翻译成等价的 ARM64 指令然后让 ARM CPU 执行。这个过程是实时的对用户透明。为什么不用静态翻译因为静态翻译需要提前把整个程序的所有代码都翻译好但程序可能有动态加载的库、自修改代码、JIT 编译等静态翻译处理不了这些情况。动态翻译虽然有一点性能开销但兼容性更好。FEX-Emu 的性能取决于几个因素一是翻译缓存的大小翻译过的代码块会被缓存起来下次执行同样的代码就不用重新翻译二是寄存器映射的效率x86-64 有 16 个通用寄存器ARM64 有 31 个FEX-Emu 需要合理分配这些寄存器三是对 SIMD 指令的支持x86 的 SSE/AVX 指令和 ARM 的 NEON/SVE 指令不是一一对应的需要做转换。在实际使用中FEX-Emu 对大多数 Windows 应用都能跑起来但性能损失是不可避免的。根据我的测试简单的办公软件大概能跑到原生性能的 60% 到 80%游戏的话取决于图形负载CPU 密集型的场景损失更大。不过对于 iOS 设备来说A 系列芯片的单核性能很强翻译后的性能反而可能比一些低功耗 x86 设备还好。2.3 DXMT把 Direct3D 翻译成 MetalDXMT 是专门为 Apple 平台设计的 Direct3D 到 Metal 的翻译层。Windows 游戏大量使用 Direct3D 9/10/11/12但 macOS 和 iOS 只支持 Metal。DXMT 的工作就是把 D3D 的绘制调用、着色器、纹理操作翻译成 Metal 对应的 API。这个翻译过程比 API 翻译复杂得多因为 D3D 和 Metal 的渲染管线设计不一样。比如 D3D 11 有立即模式上下文和延迟上下文Metal 只有命令缓冲区D3D 的着色器是 HLSLMetal 的是 MSLDXMT 需要把 HLSL 编译成 MSL 或者 SPIR-V 再转 MSL。好在 DXMT 已经处理了大部分常见情况主流的游戏引擎比如 Unity、Unreal 都能跑。热搜词里有个“DXMT”单独出现说明关注这个组件的人不少。我的建议是如果你主要跑的是 Direct3D 9 的老游戏DXMT 的兼容性已经相当好了如果是 D3D 12 的新游戏可能还需要等 DXMT 进一步成熟。另外 DXMT 对 Metal 的特性支持也有限制比如 iOS 上的 Metal 不支持某些桌面级特性这些在翻译时会被降级处理。3. 实操环境搭建从零开始跑通一个 Windows 程序3.1 基础环境准备与依赖安装假设你在一台 ARM64 的 Linux 设备上操作比如树莓派 5 或者搭载骁龙处理器的笔记本。首先需要确认系统架构uname -m如果输出aarch64说明是 ARM64 环境。然后安装基础依赖sudo apt update sudo apt install -y build-essential cmake git python3 pkg-config libgl1-mesa-dev libvulkan-dev这些是编译 Wine 和 FEX-Emu 所需的基本工具。接下来安装 Wine我建议用 WineHQ 的官方仓库版本比较新sudo dpkg --add-architecture arm64 wget -O- https://dl.winehq.org/wine-builds/winehq.key | sudo apt-key add - sudo add-apt-repository deb https://dl.winehq.org/wine-builds/ubuntu/ focal main sudo apt update sudo apt install -y --install-recommends winehq-stable安装完成后用wine --version检查版本。如果遇到“wine deepin无法下载”类似的问题大概率是软件源配置不对可以换成国内的镜像源但要注意镜像源的同步延迟。FEX-Emu 的安装稍微麻烦一点因为它需要从源码编译git clone https://github.com/FEX-Emu/FEX.git cd FEX git submodule update --init --recursive mkdir build cd build cmake -DCMAKE_INSTALL_PREFIX/usr/local -DCMAKE_BUILD_TYPERelease .. make -j$(nproc) sudo make install编译过程可能需要半小时到一小时取决于设备性能。编译完成后FEX-Emu 会安装到/usr/local/bin/FEX还需要配置 binfmt_misc 让系统自动用 FEX 执行 x86-64 程序sudo mkdir -p /usr/lib/binfmt.d echo :FEX-x86_64:M::\x7fELF\x02\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x3e\x00:\xff\xff\xff\xff\xff\xff\xff\x00\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff\xff:/usr/local/bin/FEXInterpreter:PF | sudo tee /usr/lib/binfmt.d/FEX-x86_64.conf sudo systemctl restart systemd-binfmt这一步做完之后系统就能识别 x86-64 的 ELF 文件并自动调用 FEX 来执行了。3.2 Wine 前缀配置与中文字体修复Wine 使用“前缀”来隔离不同的 Windows 环境默认前缀在~/.wine。创建一个新的 64 位前缀export WINEPREFIX~/madeira-prefix export WINEARCHwin64 wineboot --init初始化完成后把 Windows 程序复制到前缀的drive_c目录下或者直接用wine命令运行。但这时候如果程序界面有中文很可能会显示成乱码。热搜词里的“wine 乱码”和“wine 栏是乱码”就是这个现象。修复方法是把系统的中文字体链接到 Wine 的字体目录mkdir -p $WINEPREFIX/drive_c/windows/Fonts ln -s /usr/share/fonts/truetype/wqy/wqy-microhei.ttc $WINEPREFIX/drive_c/windows/Fonts/然后在 Wine 注册表里配置字体替换wine reg add HKEY_LOCAL_MACHINE\\Software\\Microsoft\\Windows NT\\CurrentVersion\\FontSubstitutes /v MS Shell Dlg /t REG_SZ /d WenQuanYi Micro Hei /f wine reg add HKEY_LOCAL_MACHINE\\Software\\Microsoft\\Windows NT\\CurrentVersion\\FontSubstitutes /v MS Shell Dlg 2 /t REG_SZ /d WenQuanYi Micro Hei /f如果还是乱码检查一下LANG环境变量是不是zh_CN.UTF-8有时候是 locale 没设置对导致的。3.3 DXMT 的编译与集成DXMT 需要单独编译因为它不是 Wine 的一部分git clone https://github.com/3Shain/dxmt.git cd dxmt mkdir build cd build cmake -DCMAKE_BUILD_TYPERelease -DCMAKE_INSTALL_PREFIX$WINEPREFIX/drive_c/windows/system32 .. make -j$(nproc) make install编译完成后DXMT 的 DLL 会被安装到 Wine 前缀的system32目录。然后在 Wine 的 DLL 覆盖设置里把d3d11.dll、dxgi.dll这些指向 DXMT 的实现wine reg add HKEY_CURRENT_USER\\Software\\Wine\\DllOverrides /v d3d11 /t REG_SZ /d native /f wine reg add HKEY_CURRENT_USER\\Software\\Wine\\DllOverrides /v dxgi /t REG_SZ /d native /f这里有个细节DXMT 需要 Metal 支持所以在 Linux 上跑的时候实际上是通过 MoltenVK 或者类似的层把 Metal 调用转成 Vulkan。如果你在纯 Linux 环境可能直接用 WineD3D 或者 DXVK 更合适。DXMT 的主要目标平台是 macOS 和 iOS。4. 常见问题与排查技巧实录4.1 Wine 乱码问题的完整排查路径乱码问题我遇到过很多次总结下来无非几个原因字体缺失、locale 不对、注册表没配好、程序用了非 Unicode 编码。排查顺序建议这样现象可能原因排查方法解决方案界面全是方块缺少中文字体检查$WINEPREFIX/drive_c/windows/Fonts目录链接系统中文字体部分文字乱码字体替换没配查看注册表 FontSubstitutes添加 MS Shell Dlg 替换命令行输出乱码locale 不对echo $LANG设置为 zh_CN.UTF-8特定程序乱码程序用了 GBK 编码用file命令检查文件编码用winecfg设置区域为中文还有一个容易被忽略的点Wine 的winecfg里有个“模拟 Windows 版本”的设置如果设成 Windows 7 但程序需要 Windows 10也可能导致字体渲染异常。我的经验是尽量设成 Windows 10兼容性最好。4.2 FEX-Emu 性能调优与兼容性处理FEX-Emu 默认配置对大多数程序都能跑但有些程序会崩溃或者性能很差。这时候可以调整 FEX 的配置export FEX_TSOENABLED1 export FEX_VECTORTSOENABLED1 export FEX_HALF BARRIER1这几个环境变量控制的是内存模型的模拟。x86 是强内存模型ARM 是弱内存模型有些程序依赖 x86 的内存顺序保证如果不开启 TSOTotal Store Order模拟就可能出现数据竞争导致崩溃。开启后性能会下降一些但稳定性提升明显。另外 FEX 有个FEXCore的配置项可以调整翻译缓存的策略。在~/.fex-emu/Config.json里可以设置{ Config: { RootFS: /, EmulatedCPU: { TSOEnabled: true, VectorTSOEnabled: true, HalfBarrierTSOEnabled: true }, DynamicL1Cache: true, SMCChecks: MTrack } }DynamicL1Cache开启后FEX 会动态调整翻译缓存的大小对内存受限的设备有帮助。SMCChecks是自修改代码检测设成MTrack可以平衡性能和兼容性。4.3 iOS 设备上的特殊限制与应对热搜词里出现了大量 iOS 相关的内容比如“ios开发者模式”、“ios自动化”、“ios app开发完毕如何上架”说明很多人关心在 iOS 上跑这套方案的可能性。这里必须说清楚iOS 是一个封闭系统普通用户无法直接安装 Wine 或 FEX-Emu。你需要有开发者账号并且通过 Xcode 把编译好的二进制包签名后安装到设备上。即使装上了iOS 的沙盒机制也限制了程序能访问的目录和系统资源。Wine 需要创建文件系统、加载 DLL、访问图形 API这些在 iOS 上都需要额外的适配。目前社区里有一些实验性的项目在尝试但离可用还有距离。如果你只是想在 iOS 上跑 Windows 游戏更现实的方案是串流比如用 Moonlight 或者 Steam Link 把 PC 上的画面串流到 iOS 设备。这不是 Madeira 项目的目标但确实是目前体验最好的方案。4.4 麒麟和统信系统上的 Wine 安装问题“麒麟wine助手”和“统信wine windows兼容组件下载”这两个热搜词反映了国内 Linux 发行版的特殊性。麒麟和统信都基于 Debian 或 RPM 体系但软件源和包管理有自己的定制。我的建议是优先用系统自带的包管理器安装 Wine比如sudo apt install wine或sudo yum install wine。如果自带版本太旧去 WineHQ 下载对应发行版的二进制包手动安装。不要随便下载第三方打包的“wine 助手”很多捆绑了不必要的组件甚至可能有安全风险。安装完成后用winecfg检查配置确保音频、图形驱动都正常。麒麟系统有个坑默认的 SELinux 或者 AppArmor 策略可能会阻止 Wine 访问某些资源。如果遇到权限问题可以临时把策略设为宽容模式测试sudo setenforce 0如果问题解决再针对性地添加策略规则而不是一直关着 SELinux。5. 从开发到上架iOS 生态的关联知识点5.1 Xcode 证书配置与打包流程热搜词里“xcode从证书配置到上架全流程”和“xcode打包ios突然很慢如何解决”说明很多开发者在 iOS 开发环节遇到问题。虽然这和 Madeira 项目不是直接相关但如果你想把兼容层集成到 iOS 应用里这些流程是绕不开的。证书配置的核心是三个东西开发者证书、App ID、描述文件。开发者证书证明你的身份App ID 标识你的应用描述文件把证书和设备绑定起来。在 Xcode 里只要登录开发者账号大部分步骤可以自动完成。但如果你用 CI/CD 流水线就需要手动管理这些证书。打包慢的问题通常有几个原因一是 DerivedData 缓存太大可以定期清理二是编译选项没优化比如开了全量调试符号三是网络问题Xcode 需要从 Apple 服务器下载一些资源。我的经验是在xcodebuild命令里加上-derivedDataPath指定一个独立的缓存目录避免和其他项目冲突。5.2 iOS 开发者模式与自动化测试“ios开发者模式”和“ios自动化”这两个词经常一起出现。iOS 16 之后开发者模式需要在设置里手动开启否则无法安装自签名的应用。开启路径是设置 - 隐私与安全性 - 开发者模式。开启后设备会重启然后才能用 Xcode 或者 AltStore 安装应用。自动化测试方面Xcode 自带 XCTest 框架可以写 UI 测试和单元测试。如果需要更复杂的自动化比如模拟点击、滑动、输入可以用 WebDriverAgent 或者 Appium。这些工具的原理都是通过 XCTest 的私有 API 控制设备所以需要开发者模式。如果你只是想在 iOS 上跑一些脚本可以用快捷指令或者 Pythonista 这类应用它们提供了有限的自动化能力但不需要开发者模式。5.3 应用下架与版本管理“ios app下架操作”和“ios延迟升级”这两个词涉及到应用的生命周期管理。下架应用很简单在 App Store Connect 里选择“移除应用”就行但要注意已经下载的用户仍然可以使用。如果只是想停止新用户下载可以选择“下架”而不是“删除”。延迟升级是指用户可以控制是否自动更新应用。开发者可以在 App Store Connect 里设置分阶段发布让更新逐步推送给用户而不是一次性全量推送。这对稳定性要求高的应用很有用可以在小范围验证后再扩大推送范围。6. 我踩过的坑和最后分享几个实用技巧折腾 Madeira 这套方案的过程中我踩过不少坑。最大的一个坑是盲目追求最新版本。Wine、FEX-Emu、DXMT 都在快速迭代但最新版不一定最稳定。我有一次把 FEX-Emu 更新到最新 commit结果之前能跑的游戏全部崩溃回退到上一个稳定 tag 就正常了。所以我的建议是生产环境用稳定版测试环境再尝鲜。第二个坑是忽略日志。Wine 和 FEX-Emu 都会输出大量日志很多人直接忽略。其实日志里包含了关键信息比如缺少哪个 DLL、哪条指令翻译失败、内存访问越界等。遇到问题先看日志能省很多排查时间。Wine 的日志可以用WINEDEBUGall开启FEX 的日志在~/.fex-emu/Logs目录下。第三个坑是文件系统权限。Wine 前缀目录的权限设置不对会导致程序无法写入文件、无法创建临时文件。确保$WINEPREFIX目录的属主是你自己权限至少是755。如果程序需要写入Program Files目录可能还需要额外配置。最后分享一个小技巧如果你在 ARM 设备上跑 Windows 程序尽量用 64 位版本。32 位程序需要额外的 WoW64 层性能损失更大而且 FEX-Emu 对 32 位的支持不如 64 位完善。如果只有 32 位版本可以试试用 Box86 而不是 FEX-EmuBox86 专门做 x86 到 ARM 的翻译对 32 位程序优化更好。还有一个技巧是用 tmpfs 加速翻译缓存。FEX-Emu 的翻译缓存默认在磁盘上如果内存充足可以把缓存目录挂到 tmpfssudo mount -t tmpfs -o size2G tmpfs ~/.fex-emu/Cache这样翻译后的代码块读写都在内存里速度会快不少。不过要注意tmpfs 在重启后会丢失所以每次重启后第一次运行程序会重新翻译之后就好了。这套方案目前还在不断完善中社区里有很多人在贡献代码和测试反馈。如果你也想参与建议先从跑通一个简单的 Windows 程序开始比如记事本或者计算器然后再逐步尝试更复杂的应用。遇到问题多查日志、多搜索、多问社区大部分坑都已经有人踩过了。