1. 项目缘起：为什么要在 Linux 上折腾 Windows 应用兼容层
第一次接触 Madeira 这个项目，是在一台装了统信 UOS 的国产笔记本上。当时的需求很朴素：单位配发的机器只能用国产系统，但日常办公又离不开几个 Windows 下的小工具，比如某个老版本的财务软件、一个只有 exe 安装包的行业客户端。装虚拟机太重，双系统切换太烦，于是我把目光投向了 Wine 这条路线。
Madeira 这个名字，在兼容层圈子里并不算最响亮的，但它做的事情很实在——把 Wine、FEX-Emu、DXMT 这几套东西整合到一起，形成一个相对开箱即用的 Windows 应用运行环境。说白了，它想解决的就是"我不想研究一堆编译参数和依赖关系，只想把那个 exe 跑起来"这个最朴素的需求。
这里得先把几个核心概念捋清楚，不然后面全是糊涂账。Wine是一个兼容层，它把 Windows 的系统调用翻译成 Linux 能听懂的调用，让 exe 文件以为自己还在 Windows 上。FEX-Emu是一个 x86-64 指令集模拟器，主要用在 ARM 架构的设备上——比如那些用 ARM 芯片的国产笔记本，它们本身跑不了 x86 的二进制程序，需要 FEX-Emu 来做指令翻译。DXMT则是把 Direct3D 调用翻译成 Metal 的中间层，这个主要针对有 Metal 图形接口的平台。
Madeira 把这些组件打包在一起，针对不同的硬件架构做适配。x86-64 的机器上，它主要靠 Wine 加 DXMT 的组合；ARM 机器上，就得多套一层 FEX-Emu 来做指令翻译。这个设计思路很清晰：让用户不用关心底层是哪种指令集，拿到手就能跑 Windows 程序。
适合看这篇内容的人，我大致分三类。第一类是国产系统用户，手头有统信 UOS、麒麟这类系统，被 Windows 软件卡住了脖子。第二类是 Linux 桌面玩家，想在不装虚拟机的前提下跑一些 Windows 独占工具。第三类是对兼容层技术本身感兴趣的人，想搞清楚 Wine、FEX-Emu、DXMT 这几套东西是怎么协同工作的。不管你是哪一类，接下来的内容都会从实操角度出发，把能踩的坑和能抄的作业都摆出来。
2. 核心组件拆解：Wine、FEX-Emu、DXMT 各自扮演什么角色
2.1 Wine 到底做了什么翻译工作
很多人对 Wine 有个误解，以为它是个模拟器。其实 Wine 的全称是"Wine Is Not an Emulator"，它不模拟硬件，而是在系统调用层面做翻译。Windows 程序调用CreateFile，Wine 把它翻译成 Linux 的open；Windows 程序调用MessageBox，Wine 用 GTK 或 Qt 画一个出来。这种翻译方式的好处是性能损耗小，坏处是有些 Windows 特有的行为没法完全复现。
Wine 的目录结构里，最核心的是~/.wine这个前缀目录，它模拟了一个 C 盘的结构。里面drive_c就是假的 C 盘，system32里放的是 Wine 自己实现的 DLL。当你运行一个 exe 时，Wine 会加载这个前缀里的环境，然后开始翻译系统调用。
Madeira 对 Wine 的整合，主要体现在预配置的前缀和依赖库的补齐上。原生 Wine 装完之后，很多 Windows 程序会因为缺少 VC++ 运行库、.NET Framework 或者某些字体而跑不起来。Madeira 把这些常用依赖提前打包好，省去了用户一个个手动安装的麻烦。
注意：Wine 的版本选择很关键。开发版（wine-devel）功能新但可能不稳定，稳定版（wine-stable）靠谱但可能缺一些新特性。Madeira 通常会锁定一个经过测试的版本，不建议自己随意升级。
2.2 FEX-Emu 在 ARM 设备上的关键作用
如果你用的是 x86-64 的机器，FEX-Emu 这部分可以跳过。但如果你用的是 ARM 架构的设备，比如某些国产 ARM 笔记本或者树莓派，那 FEX-Emu 就是绕不开的一环。
ARM 芯片看不懂 x86-64 的指令，就像一个人只懂中文，你给他一份俄文文件，他得先翻译才能读。FEX-Emu 做的就是这件事：把 x86-64 的指令实时翻译成 ARM 能执行的指令。这个过程叫动态二进制翻译，性能损耗是必然的，但 FEX-Emu 在这方面做得相当不错，日常办公类应用基本感觉不到明显卡顿。
FEX-Emu 的工作流程大致是这样的：程序启动时，FEX-Emu 加载 x86-64 的二进制文件，逐条读取指令，翻译成 ARM 指令，然后执行。为了提高效率，它会缓存翻译过的代码块，下次遇到同样的指令就直接用缓存。这个缓存机制是性能的关键，第一次运行会慢一些，后面就快起来了。
Madeira 在 ARM 设备上的价值，就是把 FEX-Emu 和 Wine 的配合调好了。单独装 FEX-Emu 再装 Wine，中间有很多环境变量和路径配置要处理，Madeira 把这些都封装好了。
2.3 DXMT 如何把 Direct3D 调用转成 Metal
DXMT 这个组件，主要解决的是图形渲染问题。Windows 程序用 Direct3D 画图，Linux 上通常用 Vulkan 或 OpenGL，而 DXMT 走的是另一条路——把 Direct3D 调用翻译成 Metal。
Metal 是苹果平台的图形接口，那 DXMT 为什么会在 Linux 兼容层里出现？这是因为在某些 ARM 设备上，Metal 的驱动支持反而比 Vulkan 更成熟。DXMT 通过 Metal 来做图形翻译，绕开了 Vulkan 驱动不完善的问题。
实际使用中，DXMT 主要影响的是游戏和图形密集型应用。如果你只是跑一个记事本或者计算器，DXMT 基本不参与工作。但如果你要跑一个 3D 游戏或者视频编辑软件，DXMT 的配置就直接决定了能不能跑、跑得流不流畅。
Madeira 对 DXMT 的整合，主要是预设好 D3D 到 Metal 的映射规则，以及处理一些常见的兼容性问题。比如某些游戏需要特定的 D3D 特性级别，Madeira 会提前配好对应的参数。
| 组件 | 核心功能 | 适用场景 | 性能影响 |
|---|---|---|---|
| Wine | 系统调用翻译 | 所有 Windows 程序 | 损耗较小，接近原生 |
| FEX-Emu | x86-64 到 ARM 指令翻译 | ARM 设备运行 x86 程序 | 损耗中等，依赖缓存 |
| DXMT | Direct3D 到 Metal 翻译 | 图形密集型应用 | 损耗取决于具体实现 |
3. 实操部署：从零把 Madeira 环境跑起来
3.1 系统准备与依赖检查
在动手之前，先把系统环境确认一遍。Madeira 对系统版本有一定要求，太老的系统可能缺依赖，太新的系统可能还没适配。我实测下来，统信 UOS 专业版 1040 以上、麒麟 V10 SP1 以上都比较稳。
第一步是检查 CPU 架构，这决定了后面要不要启用 FEX-Emu：
uname -m如果输出x86_64，说明是 x86-64 架构，Wine 可以直接跑，不需要 FEX-Emu。如果输出aarch64，说明是 ARM 架构，必须启用 FEX-Emu 才能跑 x86 程序。
第二步是检查系统里有没有装过 Wine，避免版本冲突：
wine --version如果已经装了 Wine，建议先卸载干净，包括~/.wine目录。Madeira 需要在一个干净的环境里部署，残留的 Wine 配置可能导致各种奇怪问题。
第三步是确认磁盘空间。Wine 前缀加上各种依赖库，至少需要 5GB 以上的空闲空间。如果要跑大型游戏，建议留 20GB 以上。
提示：部署前最好把系统更新到最新，特别是图形驱动和字体包。很多 Wine 乱码问题，根源都是系统缺字体。
3.2 Madeira 的获取与安装
Madeira 的获取渠道，通常是通过项目官方仓库或者社区维护的软件源。这里不具体给链接，因为不同发行版的安装方式差异很大，给一个通用思路。
对于 Debian 系（包括 UOS、Deepin），通常是添加软件源后用 apt 安装：
sudo apt update sudo apt install madeira对于 RedHat 系（包括麒麟、CentOS），则是用 dnf 或 yum：
sudo dnf install madeira如果官方源里没有，可以下载离线包手动安装。离线包通常是一个压缩文件，解压后里面有安装脚本：
tar -xzf madeira-*.tar.gz cd madeira-* sudo ./install.sh安装脚本会做几件事：把 Wine 的二进制文件放到/opt/madeira下，创建桌面快捷方式，配置环境变量。安装完成后，需要重新登录一次，让环境变量生效。
安装过程中最常见的报错是依赖缺失。比如提示libfreetype6找不到，那就手动装上：
sudo apt install libfreetype6依赖问题一个个解决就行，不复杂但需要耐心。
3.3 Wine 前缀的初始化与配置
Madeira 装好后，第一件事是初始化 Wine 前缀。前缀就是那个模拟的 C 盘，所有 Windows 程序都装在里面。
madeira --init这个命令会创建一个默认前缀，通常在~/.madeira/prefix下。初始化过程会弹出一堆窗口，提示安装 Mono 和 Gecko，这两个分别是 .NET 和浏览器控件的替代实现。建议都装上，不然很多程序会因为缺 .NET 或网页控件而报错。
初始化完成后，可以看看前缀目录的结构：
ls ~/.madeira/prefix/drive_c/应该能看到Program Files、windows、users这些熟悉的目录。这就是 Windows 程序眼中的 C 盘。
接下来配置 Wine 的版本。Madeira 通常自带多个 Wine 版本，可以用winecfg来切换：
madeira --winecfg在Applications标签页里，可以针对不同的 exe 设置不同的 Windows 版本。比如老程序选 Windows XP，新程序选 Windows 10。这个设置很关键，选错了程序可能直接闪退。
注意：不要随意修改
drive_c里的系统文件，特别是system32下的 DLL。这些是 Wine 自己实现的，改了可能导致整个前缀崩溃。
3.4 安装第一个 Windows 程序
拿一个常见的 exe 安装包来试手。假设安装包叫setup.exe，放在~/Downloads下：
madeira ~/Downloads/setup.exeMadeira 会调用 Wine 来运行这个安装程序。安装界面和 Windows 上基本一样，一路下一步就行。安装完成后，程序通常会在drive_c/Program Files下。
运行已安装的程序，有两种方式。一种是直接指定路径：
madeira "~/.madeira/prefix/drive_c/Program Files/某软件/某软件.exe"另一种是创建桌面快捷方式。Madeira 通常提供了快捷方式生成工具，或者可以手动写一个.desktop文件：
[Desktop Entry] Name=某软件 Exec=madeira "~/.madeira/prefix/drive_c/Program Files/某软件/某软件.exe" Type=Application Icon=某软件图标路径把文件保存到~/.local/share/applications/下，桌面环境就能识别了。
第一次运行程序时，可能会遇到缺 DLL 的报错。比如提示msvcp140.dll not found，这是缺 VC++ 运行库。解决办法是用winetricks安装：
madeira --winetricks vcrun2015winetricks是 Wine 的辅助工具，能自动下载安装各种 Windows 运行库。Madeira 通常集成了这个工具，用起来很方便。
4. 疑难杂症：Wine 乱码、依赖缺失与性能调优
4.1 Wine 乱码问题的根源与解决
Wine 乱码是最高频的问题，没有之一。表现就是程序界面上的中文变成方块、问号或者一堆乱码字符。这个问题的根源是字体映射不对。
Wine 默认用的字体是Tahoma，这个字体在 Linux 上通常没有，Wine 就找一个替代品，但替代品可能不含中文字形，于是就乱码了。解决办法是把中文字体注册到 Wine 的字体表里。
第一步，确认系统里装了中文字体：
fc-list :lang=zh如果输出为空，说明没装中文字体，先装上：
sudo apt install fonts-wqy-microhei fonts-wqy-zenhei第二步，把字体复制到 Wine 的字体目录：
cp /usr/share/fonts/truetype/wqy/wqy-microhei.ttc ~/.madeira/prefix/drive_c/windows/Fonts/第三步，修改 Wine 的注册表，把默认字体替换成中文字体。可以用wine regedit打开注册表编辑器，找到HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\FontSubstitutes，把Tahoma的值改成WenQuanYi Micro Hei。
如果嫌注册表麻烦，也可以用winetricks一键设置：
madeira --winetricks cjkfonts这个命令会自动安装中文字体并配置好映射关系。实测下来，大部分乱码问题都能解决。
提示：有些程序会自己指定字体，不读系统的字体映射。这种情况需要把字体文件直接放到程序目录下，或者在程序的设置里手动选字体。
4.2 依赖库缺失的排查思路
Wine 程序跑不起来，十有八九是缺 DLL。报错信息通常会告诉你缺哪个文件，比如xxx.dll not found。这时候不要急着去网上找 DLL 下载，优先用 winetricks 安装。
常见的依赖库和对应的 winetricks 包名：
| 缺失的 DLL | 对应的运行库 | winetricks 命令 |
|---|---|---|
| msvcp140.dll | VC++ 2015 运行库 | winetricks vcrun2015 |
| mfc140.dll | MFC 运行库 | winetricks mfc140 |
| dotnet35 | .NET Framework 3.5 | winetricks dotnet35 |
| riched20.dll | 富文本编辑控件 | winetricks riched20 |
| gdiplus.dll | GDI+ 图形库 | winetricks gdiplus |
如果 winetricks 里没有，可以手动把 DLL 放到drive_c/windows/system32下，然后用wine regsvr32注册：
cp xxx.dll ~/.madeira/prefix/drive_c/windows/system32/ madeira regsvr32 xxx.dll但手动放 DLL 有风险，版本不匹配可能导致更严重的问题。优先用 winetricks，实在不行再手动处理。
还有一种情况是程序依赖某个 Windows 服务或驱动，这种 Wine 基本无解。比如某些带硬件加密狗的程序，或者依赖特定内核驱动的安全软件，Wine 跑不了就是跑不了，别浪费时间。
4.3 性能调优的几个关键参数
Wine 的性能调优，主要围绕图形渲染和内存管理两个方向。
图形方面，如果程序卡顿严重，可以试试切换渲染后端。Wine 支持多种渲染方式，通过环境变量控制：
export WINED3D_RENDERER=gl或者：
export WINED3D_RENDERER=vulkan不同程序对不同后端的兼容性不一样，可以多试几个。Madeira 通常会在配置里预设一个默认值，但允许用户覆盖。
内存方面，Wine 默认会限制单个进程的内存使用。如果程序需要大内存，可以调整：
export WINEMAXMEM=4096这个值单位是 MB，根据实际情况调整。但不要设得太大，超过物理内存反而会拖慢系统。
还有一个容易被忽略的点是CPU 调度。Wine 程序在 Linux 上跑，CPU 调度策略可能不是最优的。可以用taskset把程序绑定到特定核心：
taskset -c 0-3 madeira 程序.exe这样能减少 CPU 核心切换的开销，对某些计算密集型程序有奇效。
注意：性能调优没有万能参数，不同程序的最佳配置可能完全不同。建议一次只改一个参数，改完测试，确认有效再改下一个。
4.4 常见问题速查表
| 问题现象 | 可能原因 | 排查方向 | 解决方法 |
|---|---|---|---|
| 程序闪退，无报错 | 缺运行库或 Windows 版本设置错误 | 查看终端输出 | 用 winetricks 装运行库，调整 winecfg 里的版本 |
| 界面乱码 | 字体映射错误 | 检查系统字体 | 安装中文字体，配置字体替换 |
| 程序卡顿严重 | 渲染后端不兼容 | 尝试不同渲染器 | 切换 WINED3D_RENDERER |
| 无法联网 | Wine 网络配置问题 | 检查 winsock | 用 winetricks 重置网络组件 |
| 声音异常 | 音频驱动不匹配 | 检查 PulseAudio | 在 winecfg 里切换音频驱动 |
| 安装程序报错 | 权限或路径问题 | 检查安装目录 | 换一个安装路径，或用管理员模式运行 |
5. 进阶玩法：让 Madeira 融入日常工作流
5.1 多前缀管理：不同程序用不同环境
Wine 的前缀是可以有多个的。有些程序需要 .NET 4.0，有些需要 .NET 2.0，装在一个前缀里会冲突。这时候就可以创建多个前缀，每个前缀服务一组程序。
创建新前缀：
WINEPREFIX=~/.madeira/prefix-dotnet4 madeira --init运行程序时指定前缀：
WINEPREFIX=~/.madeira/prefix-dotnet4 madeira 程序.exeMadeira 通常提供了前缀管理工具，可以给每个前缀起名字，方便切换。这个功能在跑多个 Windows 程序时特别有用，避免了一个程序装崩了连累所有程序。
5.2 与系统集成的几个技巧
Wine 程序默认的文件关联、剪贴板共享、拖拽支持，都需要额外配置。
文件关联方面，可以在winecfg的Drives标签页里，把 Linux 的目录映射成 Windows 的盘符。比如把~/Documents映射成D:盘，这样 Windows 程序就能直接访问 Linux 下的文件了。
剪贴板共享通常是默认开启的，但有些程序不认。可以在winecfg的Graphics标签页里，勾选Allow the window manager to control the windows，这样剪贴板同步会更可靠。
拖拽支持需要 Wine 的xdg驱动。如果拖拽不工作，检查一下有没有装wine-mono和wine-gecko，这两个组件对系统集成很重要。
5.3 自动化脚本：一键启动常用程序
如果每天都要跑同一个 Windows 程序，可以写个脚本简化启动流程：
#!/bin/bash export WINEPREFIX=~/.madeira/prefix export WINED3D_RENDERER=vulkan cd ~/.madeira/prefix/drive_c/Program\ Files/某软件/ madeira 某软件.exe "$@"把脚本保存到/usr/local/bin/某软件，加执行权限：
sudo chmod +x /usr/local/bin/某软件以后直接在终端输入某软件就能启动了。还可以把这个脚本做成桌面快捷方式，双击就能跑。
提示：脚本里可以加一些环境变量优化，比如
export WINEDEBUG=-all可以关闭调试输出，减少终端刷屏。
5.4 备份与迁移：把配置带走
Wine 前缀是可以整体备份的。把~/.madeira/prefix目录打包，换机器时解压到同样位置，程序就能直接跑。
tar -czf madeira-prefix-backup.tar.gz ~/.madeira/prefix迁移到新机器时：
tar -xzf madeira-prefix-backup.tar.gz -C ~/但要注意，新机器的 Wine 版本和 Madeira 版本最好和旧机器一致，不然可能出现兼容性问题。如果版本不同，可以先在新机器上初始化一个空前缀，然后把旧前缀里的drive_c/Program Files复制过去，这样能保留程序但重置系统配置。
我在实际使用中发现，备份前缀这个习惯能省很多事。特别是那些配置复杂的程序，重装一次要折腾半天，有备份直接恢复，五分钟搞定。
5.5 关于 FEX-Emu 的额外说明
ARM 设备上跑 FEX-Emu，有几个参数值得关注。FEX_APP_CONFIG可以指定配置文件，里面能调整缓存大小、JIT 编译策略等。默认配置通常够用，但如果程序跑起来特别慢，可以试试调大缓存：
export FEX_APP_CONFIG=~/.fex-emu/config.json在配置文件里把CacheSize调大，比如从默认的 128MB 调到 512MB。这个缓存是存翻译后的 ARM 指令的，越大越能减少重复翻译的开销。
另外，FEX-Emu 对多线程程序的支持在不断完善中。如果程序是多线程的，确保 FEX-Emu 版本足够新，老版本可能有线程调度问题。
踩过几次坑之后，我的经验是：ARM 设备上跑 Windows 程序，优先选轻量级、单线程的程序，复杂的大型软件即使能跑，体验也往往不如 x86 设备。这是硬件架构决定的，不是软件能完全弥补的。
6. 个人实操体会与几个实用建议
折腾 Madeira 这套东西有一段时间了，说几个我觉得最有价值的经验。
第一个是不要追求最新版本。Wine、FEX-Emu、DXMT 这些组件更新都很快，但新版本不一定适合你的场景。Madeira 锁定的版本组合通常是经过测试的，除非遇到明确的问题，否则不要随意升级单个组件。我试过把 Wine 升到最新开发版，结果原本能跑的程序反而崩了，回退后才恢复正常。
第二个是善用日志。Wine 的日志输出很详细，遇到问题先看日志，比瞎猜高效得多。开启日志：
export WINEDEBUG=+all madeira 程序.exe 2> wine.log日志文件会很大，但里面通常有明确的错误信息。搜err:开头的行，基本就能定位问题。
第三个是保持耐心。Wine 兼容层不是万能的，有些程序就是跑不了，这很正常。遇到跑不了的程序，先搜搜有没有人遇到过同样的问题，很多时候社区里已经有解决方案了。如果实在不行，虚拟机或者远程桌面是备选方案，不必死磕。
最后一个建议是做好记录。每装一个程序，把用的 winetricks 包、改的配置、遇到的问题和解决方法都记下来。时间长了，这就是你自己的知识库，下次遇到类似问题能直接查。我用一个简单的 Markdown 文件记录这些，已经攒了几十条，省了很多重复排查的时间。
这个内容后续还可以这样扩展：如果你对图形翻译感兴趣，可以深入研究 DXMT 和 DXVK 的区别，两者走的是不同技术路线，适用场景也不一样。如果你关注 ARM 设备的兼容性，可以试试对比 FEX-Emu 和 Box64 的性能差异，这两个都是 x86-64 指令翻译器，但实现思路不同。这些方向都值得单独写一篇来聊。
