1. 从“Madeira”这个名字说起它到底是个什么东西第一次看到“Madeira”这个词很多人第一反应是葡萄牙那个产葡萄酒的海岛或者是一块叫马德拉的蛋糕。但在折腾跨平台兼容层的圈子里Madeira 指的是一套围绕 Wine 构建的、面向移动端和桌面端的 Windows 应用兼容方案核心目标就一个让原本只能在 Windows 上跑的 x86-64 程序在别的系统上也能正常启动、正常显示、正常交互。我最早接触这类方案是因为手头有一批老旧的 Windows 工具链迁移到新环境后完全跑不起来。重写成本太高虚拟机又太重于是开始研究 Wine 这条路线。Wine 本身不是模拟器它是一套把 Windows API 调用翻译成宿主系统调用的兼容层。这个定位非常关键因为它决定了性能上限比完整虚拟机高得多但也决定了兼容性永远是个“持续打补丁”的过程。Madeira 在这个基础上做了大量工程化封装把 FEX-Emu、DXMT 这些组件串起来形成一条相对完整的链路。具体来说这套方案涉及几个核心关键词Wine 负责 API 翻译FEX-Emu 负责指令集层面的转换尤其是 ARM 设备上跑 x86-64 程序DXMT 负责把 Direct3D 调用翻译成 Metal让图形程序在 Apple 生态里也能渲染。这几个东西单独拿出来都不算新但把它们组合成一个可用的整体并且针对 iOS、统信、麒麟这类环境做适配就是 Madeira 这类项目真正花力气的地方。这篇文章适合谁看如果你正在折腾 Windows 程序跨平台运行或者你在国产操作系统上遇到 Wine 组件缺失、乱码、下载失败的问题又或者你想了解 iOS 上跑 x86-64 程序到底是怎么一回事那这篇内容应该能帮你省下不少查资料的时间。我会尽量把原理讲清楚把操作步骤写细把踩过的坑摊开来说。2. 整体架构拆解Wine、FEX-Emu、DXMT 各自扮演什么角色2.1 Wine 不是模拟器它的翻译逻辑决定了性能天花板很多人把 Wine 当成“Windows 模拟器”这个理解偏差会直接影响后续的排查思路。Wine 的全称是 Wine Is Not an Emulator它做的事情是当 Windows 程序调用一个 API比如CreateWindowExWine 会把这个调用翻译成宿主系统对应的图形接口调用而不是去模拟一个完整的 Windows 内核。这个设计带来的好处是性能损耗小程序跑起来接近原生速度。但代价是任何 Wine 没有实现或者实现不完整的 API程序就会直接崩掉或者行为异常。所以你会看到 Wine 的兼容性列表里有些程序是“白金”有些是“垃圾”差别就在于它用到的 API 有没有被完整覆盖。Madeira 在这方面的价值是它把 Wine 的配置、依赖库、字体、注册表项都预先打包好了。你自己从源码编译 Wine光是处理wine-gecko和wine-mono这两个依赖就能耗掉半天。wine-gecko是给 Wine 内置的 IE 组件用的很多安装程序会调用它来显示网页内容wine-mono是 .NET 运行时的替代实现。这两个东西如果缺失安装程序可能直接白屏或者报错退出。提示如果你在统信或麒麟系统上遇到“wine 栏是乱码”大概率不是 Wine 本身的问题而是字体配置没做对。Wine 默认会去找C:\windows\Fonts下的字体如果宿主系统没有对应的中文字体映射菜单栏就会显示成方块或者问号。2.2 FEX-Emu 解决的是指令集鸿沟不是 API 鸿沟FEX-Emu 是一个 x86-64 到 ARM64 的指令集转换层。注意它和 Wine 解决的是完全不同层面的问题。Wine 解决的是“Windows API 怎么变成 Linux/macOS API”FEX-Emu 解决的是“x86-64 的机器指令怎么变成 ARM64 能执行的指令”。为什么需要这个东西因为现在很多设备尤其是移动端和 Apple Silicon 设备用的是 ARM 架构。而大量 Windows 程序编译出来是 x86-64 的二进制。你光有 Wine 没用因为 CPU 根本不认识那些指令。FEX-Emu 就是在中间做实时翻译把 x86-64 指令块翻译成 ARM64 指令块然后缓存起来下次遇到同样的指令块就直接用缓存。这个翻译过程是有性能损耗的但 FEX-Emu 做得比较聪明的地方是它用了块级别的缓存和优化。实测下来对于一些计算密集型的程序性能大概能到原生的 60% 到 80%具体取决于程序的指令模式。如果是那种大量使用 SIMD 指令的程序损耗会更大一些。Madeira 把 FEX-Emu 集成进来意味着它可以在 ARM 设备上跑 x86-64 的 Windows 程序。这个组合在 iOS 上尤其有意义因为 iOS 设备全是 ARM 架构而 App Store 里不可能让你直接跑一个 Windows 程序。通过 Madeira 这套方案理论上可以在 iOS 上启动一些轻量级的 Windows 应用当然实际体验受限于 iOS 的沙盒机制和内存限制。2.3 DXMT 是图形翻译的关键Direct3D 到 Metal 的桥梁DXMT 的全称是 DirectX Metal Translation它做的事情是把 Direct3D 的调用翻译成 Metal 的调用。为什么需要这个因为 Wine 在 macOS 和 iOS 上图形层的默认方案是走 OpenGL 或者 Vulkan 转译但 Apple 已经明确表示 OpenGL 是废弃状态Vulkan 在 Apple 生态里也没有原生支持。Metal 才是 Apple 的亲儿子。DXMT 的出现让 Direct3D 9/10/11 的程序可以直接翻译到 Metal绕过了 OpenGL 这层中间商。这个路径更短性能更好兼容性也更可控。尤其是对于游戏和图形密集型应用DXMT 的翻译效率比传统的 WineD3D 方案要高不少。但 DXMT 也不是万能的。它目前对 Direct3D 12 的支持还在完善中而且不同的 Metal 版本支持的特性集也不一样。如果你跑的程序用了比较新的图形特性可能会遇到渲染错误或者直接崩溃。这时候就需要看日志确认是哪个 D3D 调用没有被正确翻译。2.4 三个组件怎么串起来一条完整的调用链把这三个东西串起来看一个 Windows 程序在 Madeira 环境下的执行路径大概是这样的程序启动加载 x86-64 二进制FEX-Emu 接管把 x86-64 指令翻译成 ARM64 指令程序调用 Windows APIWine 把这些调用翻译成宿主系统调用程序调用 Direct3DDXMT 把这些调用翻译成 Metal最终在屏幕上渲染出画面这条链路上任何一环出问题程序都跑不起来。所以排查问题的时候要养成看日志的习惯。Wine 有WINEDEBUG环境变量可以控制日志级别FEX-Emu 有自己的日志输出DXMT 也有对应的调试选项。把这几路的日志都打开基本能定位到问题出在哪个环节。3. 核心细节与实操要点从环境准备到第一个程序跑起来3.1 环境准备不同系统下的依赖差异Madeira 这套方案在不同系统上的部署方式差别很大。我分别说一下 Linux 桌面环境、国产操作系统、以及 iOS 环境下的准备要点。在标准的 Linux 桌面环境比如 Ubuntu 或者 Fedora你需要先确认内核版本和图形驱动。Wine 对图形驱动比较敏感尤其是当你用 DXMT 的时候需要 Metal 或者 Vulkan 的驱动支持。如果是 NVIDIA 显卡建议用专有驱动开源驱动在 Wine 下的表现不太稳定。国产操作系统这边统信 UOS 和麒麟 OS 都有自己的 Wine 兼容组件包。但问题在于这些包里的 Wine 版本往往比较老而且依赖库的版本和上游不一定对齐。我遇到过好几次“麒麟 wine 助手下载”之后装不上或者装上了但winecfg打不开的情况。后来发现是缺少libgnutls的某个特定版本手动补上就好了。注意在国产系统上装 Wine 相关组件尽量用系统自带的包管理器不要随便从网上抓一个 deb 包就装。版本不匹配导致的依赖地狱比缺组件本身更难排查。iOS 环境就更特殊了。iOS 的沙盒机制不允许你直接运行外部二进制所以 Madeira 在 iOS 上的实现方式通常是借助开发者模式或者企业签名把整个运行环境打包成一个 App。这就涉及到 iOS 开发者模式的开启、证书配置、以及 IPA 包的签名。热词里提到的“ios 26.3.1 怎么开发者模式”和“xcode 从证书配置到上架全流程”其实都是这个环节的问题。3.2 Wine 前缀的创建与配置别小看这一步Wine 的前缀prefix是一个独立的目录里面模拟了 C 盘的结构。每个前缀可以有自己的注册表、字体、DLL 覆盖设置。Madeira 通常会帮你创建一个默认前缀但如果你想跑多个程序建议给每个程序单独建前缀避免 DLL 冲突。创建前缀的命令很简单WINEPREFIX~/.madeira/prefix1 wineboot --init这个命令会初始化一个全新的前缀生成drive_c目录和注册表文件。初始化完成后你可以用winecfg来调整配置。我一般会做这几件事在Libraries标签页里把mscoree和mshtml设为native或者builtin取决于程序是否需要 .NET 或者 IE 组件在Graphics标签页里根据你的显示环境选择是否启用虚拟桌面在Drives标签页里把宿主系统的常用目录映射进去方便程序访问文件字体配置是中文用户最容易踩坑的地方。Wine 默认的字体映射里中文支持是不完整的。你需要把宿主系统的中文字体复制到前缀的drive_c/windows/Fonts目录下然后在注册表里做字体替换。具体操作是cp /usr/share/fonts/truetype/wqy/wqy-microhei.ttc ~/.madeira/prefix1/drive_c/windows/Fonts/然后在winecfg的Fonts标签页里把System、Menu、Tooltip这些字体都替换成WenQuanYi Micro Hei。这样菜单栏的乱码问题基本就能解决。3.3 FEX-Emu 的配置指令集转换的性能调优FEX-Emu 的配置主要集中在环境变量上。最关键的几个参数是FEX_APP_CONFIG指定配置文件路径FEX_ROOTFS指定根文件系统路径用于模拟 x86-64 的目录结构FEX_TSOENABLED控制是否启用 TSOTotal Store Order内存模型模拟开启后兼容性更好但性能会下降我一般会先跑一个简单的 x86-64 程序来测试 FEX-Emu 是否正常工作。比如用一个静态编译的 hello worldFEX_ROOTFS/path/to/rootfs FEX_APP_CONFIG/path/to/config ./hello_x86_64如果输出正常说明指令集转换层没问题。如果报错先检查FEX_ROOTFS里的库文件是否完整尤其是ld-linux-x86-64.so.2这个动态链接器。性能调优方面FEX-Emu 有一个块缓存机制。第一次运行程序时翻译后的指令块会被缓存到磁盘上下次运行同样的程序就会快很多。你可以通过FEX_CACHE_DIR环境变量指定缓存目录建议放在 SSD 上机械硬盘的随机读写会拖慢缓存加载速度。3.4 DXMT 的启用与调试图形程序的关键一环DXMT 的启用方式取决于你的 Wine 版本和安装方式。如果是 Madeira 打包好的环境通常已经内置了 DXMT 的 DLL你只需要在winecfg的Libraries标签页里把d3d9、d3d10core、d3d11这些 DLL 的加载顺序设为native优先。但 DXMT 的调试信息默认是不输出的。你需要设置环境变量DXMT_LOG_LEVELdebug WINEDEBUGd3d11 wine your_app.exe这样可以在终端里看到 DXMT 的翻译日志。如果程序启动后黑屏或者闪退先看日志里有没有Unsupported feature或者Failed to create Metal device这类错误。前者说明程序用了 DXMT 还没实现的 D3D 特性后者通常是 Metal 设备初始化失败可能是权限问题或者 GPU 不支持。提示在 iOS 上跑 DXMTMetal 设备的创建受限于系统的 GPU 权限。如果你在非越狱设备上折腾很多底层 Metal 调用是拿不到的这也是为什么 iOS 上的兼容层方案往往功能受限。4. 完整实操流程从零开始跑通一个 Windows 程序4.1 第一步确认系统环境与依赖完整性在开始之前先确认你的系统满足以下条件检查项Linux 桌面国产系统iOS架构x86-64 或 ARM64x86-64 或 ARM64ARM64图形接口Vulkan 或 OpenGLOpenGLMetal开发者模式不需要不需要需要存储空间至少 10GB至少 10GB至少 5GB内存建议 8GB建议 8GB建议 6GB依赖库方面Linux 下需要libgnutls、libasound2、libpulse、libvulkan1这些。国产系统上统信和麒麟的软件源里都有对应的包但版本可能偏旧。如果遇到wine deepin 无法下载的情况先检查软件源配置再确认网络是否正常。4.2 第二步安装 Madeira 运行环境Madeira 的安装方式取决于你获取到的包格式。如果是压缩包解压到/opt/madeira或者用户目录下即可。如果是 deb 包用dpkg -i安装然后apt install -f补依赖。安装完成后验证核心组件是否就位madeira --version wine --version fex-emu --version如果wine --version报错说明 Wine 的二进制没有正确链接。检查LD_LIBRARY_PATH是否包含了 Madeira 的库目录。4.3 第三步创建并配置 Wine 前缀按照前面说的方法创建前缀然后安装必要的运行时组件。wine-gecko和wine-mono可以从官方渠道下载但热词里提到的“wine gecko 官方正版下载”其实要注意版本匹配。Wine 的每个大版本对 gecko 和 mono 的版本要求不一样装错了会报MSHTML相关的错误。我一般会先跑winecfg确认图形界面能正常打开。如果winecfg都打不开后面的步骤就不用试了先解决基础环境问题。4.4 第四步安装目标 Windows 程序把需要运行的 Windows 程序安装包放到前缀的drive_c目录下然后用wine命令启动安装程序WINEPREFIX~/.madeira/prefix1 wine setup.exe安装过程中注意观察终端输出。如果出现err:module:import_dll这类错误说明缺少某个 DLL。你可以用winetricks来补装比如winetricks vcrun2019可以装上 Visual C 2019 的运行库。安装完成后找到程序的启动 exe用同样的方式启动。第一次启动可能会比较慢因为 FEX-Emu 需要翻译指令并建立缓存。4.5 第五步图形与音频的调试如果程序能启动但画面异常先检查 DXMT 是否生效。在winecfg里确认d3d11的加载顺序是native。如果画面还是有问题可以尝试切换到builtin的 WineD3D 方案看看是不是 DXMT 的兼容性问题。音频方面Wine 默认走 PulseAudio 或者 ALSA。如果程序没有声音检查winecfg的Audio标签页确认输出设备选对了。国产系统上有时候 PulseAudio 的服务没起来需要手动systemctl --user start pulseaudio。5. 常见问题与排查技巧实录5.1 Wine 乱码问题从字体到编码的完整排查路径“wine 乱码”是搜索量最高的关键词之一说明这个问题非常普遍。乱码的表现形式有好几种菜单栏显示方块、文本框显示问号、或者整个界面都是乱码。不同的表现形式对应不同的原因。菜单栏方块通常是字体缺失。Wine 找不到中文字体就用默认的位图字体渲染中文自然显示不出来。解决办法是把中文字体复制到前缀的 Fonts 目录并在注册表里做替换。文本框问号往往是编码问题。Wine 的默认编码是 UTF-8但有些老程序用的是 GBK 或者 ANSI。这时候需要在winecfg的Locale设置里把区域改成zh_CN.GBK或者对应的编码。还有一种情况是整个界面都乱码这通常是wine-gecko或者wine-mono没装好导致 HTML 渲染或者 .NET 界面出问题。重新安装这两个组件通常能解决。5.2 组件下载失败网络与源配置的排查“wine deepin 无法下载”和“统信 wine windows 兼容组件下载”这两个热词反映的是国产系统上组件获取困难的问题。原因通常有两个一是软件源里没有对应的包二是网络策略导致下载中断。排查思路是这样的先用apt search wine看看源里有没有相关包。如果没有检查/etc/apt/sources.list是否配置了正确的源地址。如果源里有包但下载失败用apt-get install -o Debug::Acquire::httptrue wine来看详细的下载日志确认是 DNS 问题还是连接超时。注意国产系统上的 Wine 组件包版本往往比上游慢好几个版本。如果你需要新特性可能需要自己从源码编译或者找第三方维护的包。但第三方包的依赖关系可能和系统自带的有冲突装之前最好做个系统快照。5.3 iOS 环境下的特殊问题开发者模式与签名iOS 上跑 Madeira 这类方案最大的门槛不是技术而是签名和权限。热词里“ios 开发者模式”、“ios 26.3.1 怎么开发者模式”、“免费证书 ios”这些都是围绕这个环节的。iOS 从 16 版本开始开发者模式需要在设置里手动开启而且设备需要连接 Xcode 或者用其他工具触发。开启之后你才能安装自签名的 IPA 包。免费证书的有效期只有 7 天到期后需要重新签名。这意味着如果你用免费证书每周都要重新安装一次。企业证书的签名有效期更长但获取门槛更高而且苹果对滥用企业证书的打击力度很大。如果你只是自己折腾免费证书加自动重签工具是比较实际的方案。5.4 常见问题速查表问题现象可能原因排查方法解决方案Wine 菜单乱码中文字体缺失检查前缀 Fonts 目录复制中文字体并替换注册表程序启动闪退缺少 DLL查看终端错误输出用 winetricks 补装运行库画面黑屏DXMT 未生效检查 d3d11 加载顺序设为 native 或切换 WineD3D无声音音频服务未启动检查 PulseAudio 状态启动服务或切换 ALSAFEX-Emu 报错根文件系统不完整检查 ld-linux 是否存在补全 rootfs 库文件iOS 安装失败签名过期检查证书有效期重新签名或换证书5.5 几个我踩过的坑第一个坑是wine-gecko的版本匹配。我有一次装了一个最新版的 gecko结果 Wine 报MSHTML初始化失败。后来查了 Wine 的发布说明发现那个版本的 Wine 只支持特定版本的 gecko。所以装之前一定要看 Wine 的官方文档确认对应的 gecko 和 mono 版本。第二个坑是 FEX-Emu 的缓存目录权限。我把缓存目录设在了/tmp下结果系统重启后缓存被清空程序启动又变慢了。后来改到用户目录下的.cache/fex-emu问题解决。第三个坑是 DXMT 在 iOS 上的 Metal 权限。我在非越狱设备上试了很久始终拿不到完整的 Metal 设备权限导致图形程序跑不起来。后来才明白iOS 的沙盒机制对 GPU 访问有严格限制不是所有 Metal 调用都能在第三方 App 里使用。这个限制目前没有完美的绕过方案只能等系统层面的开放。6. 性能调优与进阶技巧6.1 指令缓存与预翻译FEX-Emu 的块缓存是提升性能的关键。第一次运行程序时翻译过程会比较慢但翻译结果会缓存到磁盘。你可以通过FEX_CACHE_DIR指定缓存位置建议放在读写速度快的 SSD 上。如果你经常运行同一个程序可以考虑用 FEX-Emu 的预翻译功能提前把程序的指令块翻译好并缓存。这样每次启动都能直接命中缓存启动速度会快很多。预翻译的命令行参数是--precompile具体用法可以参考 FEX-Emu 的文档。6.2 Wine 的 DLL 覆盖策略Wine 允许你为每个 DLL 指定加载顺序native表示优先加载 Windows 的 DLLbuiltin表示优先加载 Wine 自带的实现。不同的程序对 DLL 的要求不一样选错了就会出问题。我一般的原则是图形相关的 DLLd3d9、d3d11、dxgi设为native让 DXMT 接管系统相关的 DLLkernel32、user32保持builtin用 Wine 的实现.NET 相关的 DLLmscoree根据程序需求选择如果程序自带 .NET 运行时就设native否则设builtin让 Wine 的 mono 来跑。6.3 内存与显存的分配在 ARM 设备上跑 x86-64 程序内存是个瓶颈。FEX-Emu 需要额外的内存来存放翻译后的指令块Wine 本身也有内存开销。如果设备内存不足程序可能会频繁触发交换导致卡顿。你可以通过FEX_MEMORY_LIMIT环境变量来限制 FEX-Emu 的内存使用避免它把系统内存吃光。但限制得太低又会影响性能需要根据设备实际情况调整。一般来说给 FEX-Emu 分配设备总内存的 30% 到 40% 比较合适。显存方面DXMT 会尽量复用 Metal 的纹理和缓冲区。如果程序用了大尺寸的纹理可能会遇到显存不足的问题。这时候可以尝试降低程序的图形设置或者用DXMT_TEXTURE_CACHE_SIZE来调整纹理缓存的大小。7. 这套方案还能怎么扩展Madeira 这套组合的扩展性其实挺强的。如果你把 Wine 换成 Proton把 FEX-Emu 换成 Box64把 DXMT 换成 DXVK就得到了另一套完全不同的兼容方案。不同的组合适合不同的场景Proton 对游戏的兼容性更好Box64 在 ARM 上的性能调优更激进DXVK 在 Linux 桌面上的支持更成熟。另一个扩展方向是容器化。把整个 Madeira 环境打包成 Docker 镜像或者 Flatpak 包可以避免污染宿主系统也方便迁移和备份。我试过用 Flatpak 打包效果还不错但 Flatpak 的沙盒权限配置比较麻烦需要仔细调整才能让 Wine 访问到必要的设备节点。还有一个方向是自动化测试。如果你需要批量验证多个 Windows 程序在 Madeira 下的兼容性可以写一套脚本自动创建前缀、安装程序、启动、截图、收集日志。这样能省下大量手动操作的时间也方便做回归测试。我个人在实际操作中的体会是这套方案最耗时间的不是安装和配置而是排查各种奇怪的兼容性问题。有时候一个程序跑不起来查了半天日志最后发现只是少了一个字体文件。所以耐心和日志分析能力比技术本身更重要。另外社区的力量不可忽视很多问题别人已经踩过坑了搜一下往往比你自己折腾半天更有效率。