企业官网建设流程全解析

1. 从“Madeira”说起：这个项目到底在折腾什么

第一次看到“Madeira”这个代号，加上旁边挂着的 FEX-Emu、Wine、DXMT、iOS、x86-64 这一串关键词，我脑子里第一反应是：这又是一个在“跨架构跑 Windows 程序”这条老路上做文章的项目。事实也确实如此。Madeira 的核心目标，是让 x86-64 架构的 Windows 应用，能够在非 x86 的平台上跑起来，尤其是 ARM 设备，并且把触角伸到了 iOS 这个相对封闭的生态里。

先把话说直白一点：你手上有一堆为 Windows + Intel/AMD 处理器编译的软件，现在你想在别的芯片、别的系统上运行它。传统做法是虚拟机，但虚拟机要模拟整套硬件，重、慢、费电。Madeira 走的是另一条路——用户态模拟 + 系统调用翻译 + 图形接口转换的组合拳。FEX-Emu 负责把 x86-64 的机器指令翻译成 ARM64 能懂的指令，Wine 负责把 Windows 的 API 调用翻译成 POSIX 调用，DXMT 则负责把 DirectX 的图形调用翻译成 Metal（苹果的图形接口）。三者叠在一起，就构成了一个“Windows 程序以为自己还在 Windows 上”的假象。

这套东西解决的是什么问题？说白了就是生态迁移的阵痛。很多行业软件、老游戏、专业工具只有 Windows 版本，而现在的硬件趋势是 ARM 越来越强势，苹果的 M 系列芯片、各种 ARM 服务器、甚至移动设备都在蚕食 x86 的地盘。用户不想被绑死在一个平台上，开发者也没精力为每个平台重新编译。Madeira 这类项目就是在这个缝隙里找生存空间。

适合谁来参考？三类人。第一类是跨平台开发者和逆向工程爱好者，想搞清楚指令翻译和 API 转换到底怎么落地；第二类是在 ARM 设备上跑 Windows 软件的重度用户，比如用 Mac 或者 Linux ARM 机器干活的人；第三类是对模拟器、兼容层技术感兴趣的技术玩家，想自己动手搭一套环境试试水。如果你只是想让某个 Windows 软件跑起来，不想深究原理，那直接找现成的打包方案更省事，但如果你想理解背后的门道，那这篇内容就是给你准备的。

我先把结论摆在这儿：Madeira 不是一个“一键安装包”，它更像是一套需要你自己组装和调优的工具链。它的价值不在于开箱即用，而在于它展示了一条可行的技术路径，并且把各个模块的边界划分得比较清楚。下面我会从整体设计、核心细节、实操过程、问题排查几个维度，把这条路径拆开来讲。

2. 整体设计与思路拆解：为什么是这三件套

2.1 指令翻译、API 翻译、图形翻译的分层逻辑

要理解 Madeira 的设计，得先明白一个 Windows 程序从“双击图标”到“窗口弹出来”中间经历了什么。程序本身是一堆 x86-64 指令，它调用 Windows 的 kernel32.dll、user32.dll 这些系统库，系统库再去调用更底层的系统调用，图形部分则通过 DirectX 或者 OpenGL 跟显卡驱动打交道。在原生 Windows 上，这一整条链路都是“原装”的，没有任何翻译损耗。

到了非 x86 平台上，这条链路的每一段都可能出问题。CPU 不认识 x86-64 指令，操作系统不认识 Windows 的 PE 格式和系统调用，显卡驱动不认识 DirectX。所以必须分段处理：

• 指令层：FEX-Emu 把 x86-64 指令动态翻译成宿主架构的指令。它用的是 JIT（即时编译）技术，不是逐条解释执行，而是把热代码块编译成宿主机器码缓存起来，这样重复执行时就不用再翻译了。
• 系统调用层：Wine 提供了一套 Windows API 的实现，把 CreateFile、RegOpenKey 这些调用映射到宿主系统的文件操作和配置存储上。它不模拟 Windows 内核，而是直接翻译成 POSIX 调用。
• 图形层：DXMT 把 Direct3D 的调用翻译成 Metal。这一步很关键，因为图形性能直接决定了用户体验，翻译得不好就是幻灯片。

这三层各司其职，好处是每一层都可以独立替换和优化。比如你不想用 DXMT，可以换成 DXVK（翻译成 Vulkan），或者用 WineD3D（翻译成 OpenGL）。FEX-Emu 也可以换成 Box64 或者 QEMU 的用户态模式。Madeira 的选择是 FEX-Emu + Wine + DXMT，这个组合在 ARM 设备上跑 Windows 游戏和生产力工具时，平衡了性能和兼容性。

注意：分层设计虽然灵活，但也意味着调试复杂度成倍增加。一个程序跑不起来，可能是指令翻译出错，可能是 API 映射缺失，也可能是图形转换不兼容。排查时要有“逐层剥离”的思路，后面会详细讲。

2.2 为什么盯上 iOS 这个目标平台

热词里出现了 iOS、iOS 开发者模式、iOS 自动化这些词，说明 Madeira 的野心不止于桌面 ARM 设备。iOS 设备用的是 ARM 架构，理论上跑 FEX-Emu 没有指令集障碍。但 iOS 的限制在于：系统封闭，不允许 JIT 编译（除非开启特定的开发者权限），不允许动态加载可执行代码，沙盒限制严格。

那为什么还要往 iOS 上靠？因为 iOS 设备保有量巨大，性能强劲，而且很多用户希望能在 iPad 上跑 Windows 软件或者老游戏。Madeira 在 iOS 上的思路，大概率是走“开发者模式 + 侧载”的路线，利用 iOS 允许的 JIT 权限（比如通过特定的 entitlement）来运行 FEX-Emu。这也就解释了为什么热词里有“iOS 开发者模式”“iOS 26.3.1 怎么开发者模式”这类搜索——用户卡在了第一步：怎么让 iOS 允许运行这种非 App Store 的、需要动态编译的软件。

这里要提醒一句：iOS 上的 JIT 权限不是随便能拿到的，普通开发者账号也不行，通常需要特定的企业证书或者越狱环境。所以 Madeira 在 iOS 上的落地，门槛比在 Linux ARM 上高得多。如果你只是想体验，建议先在 Linux ARM 或者 macOS ARM 上跑通，再考虑 iOS。

2.3 与麒麟、统信等国产系统 Wine 方案的关系

热词里还有“麒麟 wine 助手”“统信 wine windows 兼容组件下载”“wine deepin 无法下载”这些词，说明国内用户对 Wine 方案的关注度很高。麒麟和统信都是基于 Linux 的国产操作系统，它们自带或者推荐 Wine 方案来跑 Windows 软件。Madeira 和这些方案的关系是：底层原理相通，但集成度和目标场景不同。

麒麟 Wine 助手、统信 Wine 组件，本质上是把 Wine 和一堆依赖打包好，做成开箱即用的形式，用户不需要自己编译配置。Madeira 更偏向“技术验证”和“自定义组合”，它把 FEX-Emu 和 DXMT 也纳入进来，针对的是 ARM 平台，而麒麟和统信目前主要还是 x86 平台。所以如果你在 x86 的国产系统上跑 Windows 软件，直接用系统自带的 Wine 方案更省事；如果你在 ARM 设备上，Madeira 这套组合才更有参考价值。

不过，Madeira 在 Wine 配置上的很多经验，比如字体乱码怎么解决、Gecko 和 Mono 怎么装、注册表怎么调，对麒麟和统信用户同样适用。后面讲实操的时候我会把这些通用技巧也带上。

3. 核心细节解析与实操要点：从指令到窗口的每一步

3.1 FEX-Emu 的 JIT 配置与性能调优

FEX-Emu 是整个链条的起点，它决定了 x86-64 指令能不能被正确翻译。安装 FEX-Emu 本身不复杂，从源码编译或者用预编译包都行，关键是配置。FEX 的配置文件通常在~/.fex-emu/Config.json，里面有几个参数直接影响性能和兼容性。

第一个是RootFS，它指向一个包含 x86-64 库文件的根文件系统。因为很多 Windows 程序依赖的 DLL 是 x86-64 的，Wine 在翻译系统调用时需要这些库。你可以从现有的 x86-64 Linux 系统里拷贝/usr/lib和/lib，或者用 FEX 提供的工具生成一个最小根文件系统。

第二个是ThunkHostLibs，这个参数决定了哪些宿主库可以被直接调用，而不需要经过翻译。比如图形驱动、音频库，如果宿主系统有对应的 ARM64 版本，就可以通过 thunk 机制直接调用，省去翻译开销。配置得当的话，图形性能能提升不少。

第三个是TSOEnabled，也就是内存序模拟。x86 是强内存模型，ARM 是弱内存模型，有些程序依赖 x86 的内存序假设，关掉 TSO 可能会快一点，但可能导致程序崩溃或者数据错乱。我的建议是默认开启，除非你确定某个程序不需要。

{ "Config": { "RootFS": "/home/user/fex-rootfs", "ThunkHostLibs": "/usr/lib/aarch64-linux-gnu", "TSOEnabled": true, "JITCacheSize": 256 } }

JITCacheSize是 JIT 缓存的大小，单位是 MB。缓存越大，重复翻译越少，但内存占用越高。在内存充足的设备上可以调到 512 甚至 1024，内存紧张的设备保持 128 到 256 就行。

实操心得：FEX-Emu 第一次运行某个程序时会比较慢，因为它在翻译和缓存指令。第二次运行同一程序会明显快很多。如果你发现某个程序每次启动都很慢，检查一下 JIT 缓存是不是被清掉了，或者缓存大小设得太小。

3.2 Wine 的字体、Gecko 与 Mono 配置

Wine 是大家最熟悉的一层，但也是最容易出问题的一层。热词里“wine 乱码”“wine 栏是乱码”“wine gecko 官方正版下载”这些搜索，说明很多用户卡在了字体和依赖上。

Wine 乱码的根源通常是缺少中文字体，或者字体映射不对。Wine 默认会去找系统字体，但如果宿主系统没有安装中文字体，或者 Wine 的字体替换表没配好，界面就会显示成方块或者乱码。解决办法分两步：

第一步，在宿主系统安装中文字体。Linux 上可以用fc-list :lang=zh看看有没有中文字体，没有的话装一个，比如fonts-noto-cjk或者fonts-wqy-microhei。

第二步，配置 Wine 的字体替换。打开wine regedit，找到HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\FontSubstitutes，把MS Shell Dlg、MS Shell Dlg 2、Tahoma这些替换成你系统里有的中文字体，比如Noto Sans CJK SC。

Gecko 和 Mono 是 Wine 的两个可选组件。Gecko 用于渲染 HTML 内容，很多安装程序和内置浏览器依赖它；Mono 用于运行 .NET 程序。Wine 在首次运行时会提示下载，但国内网络环境下载经常失败，所以热词里才有“wine gecko 官方正版下载”这种搜索。你可以手动下载 Gecko 和 Mono 的 msi 包，放到 Wine 的C:\windows\system32目录下，然后用wine msiexec /i安装。

# 手动安装 Gecko wine msiexec /i wine-gecko-2.47.4-x86_64.msi # 手动安装 Mono wine msiexec /i wine-mono-8.0.0-x86.msi

注意：Gecko 和 Mono 的版本要和你的 Wine 版本匹配，版本不对可能装不上或者运行异常。Wine 的 release note 里会写明推荐版本，装之前先查一下。

3.3 DXMT 的 Metal 转换与图形性能

DXMT 是把 Direct3D 翻译成 Metal 的组件，主要针对苹果平台。它的工作原理是拦截 D3D 的调用，转换成 Metal 的 API，然后交给苹果的图形驱动执行。相比 DXVK 翻译成 Vulkan 再转 Metal，DXMT 少了一层转换，理论上效率更高。

DXMT 的配置主要在环境变量里。DXMT_ENABLE控制是否启用，DXMT_LOG_LEVEL控制日志详细程度，DXMT_SHADER_CACHE控制着色器缓存路径。着色器缓存很重要，因为 D3D 的着色器需要编译成 Metal 的着色器，第一次编译很慢，缓存下来后续就快了。

export DXMT_ENABLE=1 export DXMT_LOG_LEVEL=warn export DXMT_SHADER_CACHE=/home/user/.cache/dxmt

如果你的程序跑起来画面异常，比如黑屏、花屏、贴图错误，先看 DXMT 的日志。日志里会显示哪些 D3D 特性不支持，哪些着色器编译失败。有些老游戏用的 D3D8 或 D3D9 特性，DXMT 可能支持不完整，这时候可以试试切换到 DXVK 或者 WineD3D。

实操心得：DXMT 对 D3D11 和 D3D12 的支持比较好，D3D9 及以下建议用 WineD3D。如果你不确定程序用的是哪个版本的 D3D，可以在 Wine 的dlls目录里看看有没有d3d11.dll、d3d9.dll这些文件，或者用WINEDEBUG=+d3d打印调试信息。

3.4 iOS 侧的特殊处理：开发者模式与 JIT 权限

iOS 上的 Madeira 部署，最大的门槛是 JIT 权限。iOS 默认不允许应用动态生成和执行代码，这是安全策略。要绕过这个限制，通常需要：

• 开启开发者模式（Settings > Privacy & Security > Developer Mode）
• 使用带有dynamic-codesigningentitlement 的证书签名应用
• 或者使用越狱设备

热词里“iOS 26.3.1 怎么开发者模式”“iOS 开发者模式”这些搜索，说明很多用户卡在了开启开发者模式这一步。步骤其实不复杂：设置里找到“隐私与安全性”，往下滑找到“开发者模式”，打开开关，然后重启设备。但前提是你的设备已经通过 Xcode 或者 AltStore 之类的工具连接过，否则这个选项不会出现。

JIT 权限的获取更麻烦。普通个人开发者证书没有这个 entitlement，需要企业证书或者特定的研究证书。如果你只是自己玩玩，可以考虑用 AltStore + JIT 启用工具，但稳定性和安全性要自己权衡。

注意：在 iOS 上跑模拟器类软件，耗电和发热会非常明显。ARM 设备虽然性能强，但持续高负载运行 JIT 翻译和图形转换，温度会很快上去。建议插着电用，并且注意散热。

4. 实操过程与核心环节实现：从零搭一套可运行的环境

4.1 环境准备与依赖安装

我以 Linux ARM64（比如树莓派 5 或者苹果 M 系列芯片的 Linux 虚拟机）为例，走一遍完整流程。iOS 的流程类似，但多了签名和 JIT 权限的步骤，后面单独说。

首先确认系统架构和内核版本：

uname -m # 应该输出 aarch64 uname -r # 建议 5.15 以上，太老的内核可能缺少某些系统调用

然后安装基础依赖。FEX-Emu 需要 cmake、ninja、clang 这些编译工具，Wine 需要一堆开发库，DXMT 需要 Metal 相关的头文件（Linux 上没有 Metal，所以 DXMT 主要在 macOS 上用，Linux 上可以用 DXVK 替代）。

sudo apt update sudo apt install -y cmake ninja-build clang lld git python3 python3-pip sudo apt install -y libsdl2-dev libvulkan-dev libgl1-mesa-dev sudo apt install -y flex bison libelf-dev libcap-dev

如果你在 macOS 上，用 Homebrew 装依赖：

brew install cmake ninja llvm git python3 brew install molten-vk vulkan-loader

4.2 编译安装 FEX-Emu

FEX-Emu 的源码在 GitHub 上，克隆下来编译。编译过程比较吃 CPU，ARM 设备上可能要等十几分钟到半小时。

git clone https://github.com/FEX-Emu/FEX.git cd FEX git submodule update --init --recursive mkdir build && cd build cmake -DCMAKE_BUILD_TYPE=Release -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++ .. make -j$(nproc) sudo make install

安装完成后，用FEXInterpreter测试一下：

FEXInterpreter /usr/bin/uname -m # 如果输出 x86_64，说明 FEX 工作正常

这里有个细节：FEX 需要一个 x86-64 的根文件系统来提供库文件。你可以从 x86-64 机器上拷贝，也可以用 FEX 的RootFS工具生成。我通常从 Docker 里拉一个 x86-64 的 Ubuntu 镜像，把/usr/lib和/lib拷出来。

docker run --platform linux/amd64 -v /tmp/rootfs:/rootfs ubuntu:22.04 # 在容器里执行 cp -r /usr/lib /rootfs/ cp -r /lib /rootfs/

然后把RootFS指向这个目录。

4.3 编译安装 Wine

Wine 的编译更耗时，而且依赖更多。建议用--enable-win64只编译 64 位版本，省时间。

git clone https://github.com/wine-mirror/wine.git cd wine ./configure --enable-win64 --prefix=/opt/wine make -j$(nproc) sudo make install

编译完成后，设置环境变量：

export WINEPREFIX=/home/user/.wine-madeira export WINEARCH=win64 export PATH=/opt/wine/bin:$PATH

初始化 Wine 前缀：

wineboot -u

这时候 Wine 会提示安装 Gecko 和 Mono，如果网络不好就手动装，前面已经讲过方法。

4.4 配置 DXMT 或 DXVK

如果你在 macOS 上，用 DXMT；在 Linux 上，用 DXVK。DXVK 的安装更简单，下载 release 包，把 dll 文件拷到 Wine 的system32和syswow64目录，然后在 Wine 里注册。

# 下载 DXVK wget https://github.com/doitsujin/dxvk/releases/download/v2.3/dxvk-2.3.tar.gz tar -xzf dxvk-2.3.tar.gz cd dxvk-2.3 # 拷贝 dll cp x64/d3d11.dll /home/user/.wine-madeira/drive_c/windows/system32/ cp x64/dxgi.dll /home/user/.wine-madeira/drive_c/windows/system32/ # 注册 WINEPREFIX=/home/user/.wine-madeira wine regsvr32 d3d11.dll WINEPREFIX=/home/user/.wine-madeira wine regsvr32 dxgi.dll

DXMT 的安装类似，但需要 Metal 支持，所以只能在 macOS 上用。把 DXMT 的 dll 拷到对应目录，设置环境变量DXMT_ENABLE=1就行。

4.5 运行第一个 Windows 程序

找一个简单的 Windows 程序测试，比如 Notepad++ 或者 7-Zip。把 exe 文件放到 Wine 的drive_c目录下，然后用 FEX + Wine 运行。

FEXInterpreter /opt/wine/bin/wine64 /home/user/.wine-madeira/drive_c/7zFM.exe

如果窗口正常弹出，说明整条链路通了。如果报错，看错误信息定位是哪一层的问题。比如Unhandled exception: unimplemented function通常是 Wine 的 API 缺失，Invalid instruction通常是 FEX 翻译出错，Failed to create D3D device通常是图形层的问题。

实操心得：第一次运行建议用WINEDEBUG=+all打开全部日志，虽然输出很多，但能快速定位问题。定位到具体模块后，再用WINEDEBUG=+module只打开那个模块的日志，减少干扰。

5. 常见问题与排查技巧实录

5.1 程序启动失败：逐层剥离排查法

程序跑不起来是最常见的问题，排查思路是“从下往上，逐层验证”。

先验证 FEX 是否正常：用FEXInterpreter跑一个简单的 x86-64 Linux 程序，比如FEXInterpreter /usr/bin/ls，如果能列出文件，说明指令翻译没问题。

再验证 Wine 是否正常：用wine64 cmd.exe打开 Wine 的命令行，如果能进去，说明 Wine 的基本功能没问题。

最后验证图形层：用wine64 dxdiag查看 D3D 信息，如果能显示显卡信息，说明图形转换正常。

如果某一层失败，就针对那一层排查。FEX 失败通常是 RootFS 配置不对或者缺少库文件；Wine 失败通常是前缀损坏或者依赖缺失；图形层失败通常是 dll 没注册或者驱动不兼容。

5.2 字体乱码与界面显示异常

字体乱码前面讲过基本解法，但有些特殊情况。比如某些程序用的是自带的字体文件，不依赖系统字体，这时候乱码可能是字体文件本身的问题，或者 Wine 的字体渲染引擎没处理好。可以试试在 Wine 配置里关闭字体平滑，或者换一个渲染后端。

界面显示异常还包括窗口大小不对、控件错位、菜单不显示等。这些问题通常和 DPI 缩放有关。Wine 默认的 DPI 是 96，在高分屏上可能显示不正常。可以在winecfg的“显示”选项卡里调整 DPI，或者设置环境变量WINEDPI=144。

5.3 图形渲染问题：黑屏、花屏、贴图错误

图形问题最让人头疼，因为涉及 D3D 到 Metal/Vulkan 的转换，中间任何一步出错都会导致画面异常。

黑屏通常是着色器编译失败或者渲染目标创建失败。看 DXMT/DXVK 的日志，找到具体的错误信息。有些游戏需要特定的 D3D 特性，比如D3D11_FEATURE_D3D10_X_HARDWARE_OPTIONS，如果转换层不支持，就会黑屏。

花屏和贴图错误通常是纹理格式不兼容。D3D 支持很多压缩纹理格式，Metal 和 Vulkan 不一定都支持。DXVK 有纹理格式转换的选项，可以在配置文件里调整。

实操心得：遇到图形问题，先试试切换渲染后端。DXMT 不行换 DXVK，DXVK 不行换 WineD3D。WineD3D 虽然性能差，但兼容性最好，适合排查问题。确定是渲染后端的问题后，再针对那个后端调优。

5.4 iOS 侧的特殊问题：签名、JIT、沙盒

iOS 上的问题更棘手，因为系统限制多。签名过期是最常见的，免费开发者证书只有 7 天有效期，过期后应用无法启动，需要重新签名。JIT 权限失效也很常见，系统更新或者证书吊销都会导致 JIT 不可用。

沙盒限制导致的问题是文件访问受限。Wine 需要访问文件系统来读写程序文件，但 iOS 的沙盒只允许访问应用自己的目录。解决办法是把程序文件放到应用的 Documents 目录下，然后让 Wine 的前缀指向那里。

还有一个问题是后台运行。iOS 会在应用进入后台一段时间后挂起它，如果 Wine 正在运行一个长时间的任务，可能会被中断。可以在 Xcode 里配置后台模式，或者用beginBackgroundTask延长后台运行时间。

5.5 性能优化：让程序跑得更流畅

性能优化的核心是减少翻译开销和图形开销。FEX 这边，增大 JIT 缓存、开启 TSO、配置 ThunkHostLibs 都能提升性能。Wine 这边，关闭不必要的调试输出、使用轻量级桌面环境、减少后台进程都有帮助。图形这边，降低分辨率、关闭抗锯齿、使用低精度着色器能显著提升帧率。

还有一个容易被忽略的点是 CPU 调度。ARM 设备通常有大核和小核，FEX 的 JIT 编译线程应该绑定到大核上，避免被小核拖慢。可以用taskset或者cpuset来绑定。

# 把 FEX 进程绑定到大核（假设大核是 CPU 4-7） taskset -c 4-7 FEXInterpreter /opt/wine/bin/wine64 game.exe

注意：绑定 CPU 要谨慎，如果绑错了核，性能反而会下降。先用lscpu或者cat /proc/cpuinfo确认哪些是大核。

6. 我个人在实际操作中的几点体会

折腾 Madeira 这套东西有一段时间了，踩过的坑不少，说几个我觉得最有价值的经验。

第一个是不要追求一次跑通所有东西。很多人一上来就想跑 3A 游戏或者大型生产力软件，结果卡在某个环节就放弃了。正确的做法是从最简单的程序开始，比如记事本、计算器，先让整条链路跑通，再逐步增加复杂度。每跑通一个程序，你就对这套工具链多一分理解。

第二个是日志是你的朋友，但不要被日志淹没。Wine 和 FEX 的日志非常详细，全开的话几分钟就能刷出几百 MB。我的习惯是先全开跑一次，找到报错的关键词，然后只开相关模块的日志，精准定位。grep和less是必备工具。

第三个是版本匹配比什么都重要。FEX、Wine、DXMT/DXVK 的版本要相互兼容，Wine 的版本要和 Gecko/Mono 匹配，DXVK 的版本要和 Vulkan 驱动匹配。我建议用固定版本组合，不要盲目追新。每次升级只升一个组件，确认没问题再升下一个。

第四个是iOS 上的体验和桌面差距很大。即使跑通了，操作方式、性能表现、稳定性都和桌面没法比。如果你只是想在 iPad 上偶尔用一下某个 Windows 软件，可以试试；如果是重度使用，还是老老实实买台 x86 设备或者用云电脑。

最后分享一个小技巧：如果你在 Linux ARM 上跑，可以用box64作为 FEX 的替代方案。Box64 的配置更简单，对某些程序的兼容性也更好。两个都装上，哪个能跑用哪个，不用在一棵树上吊死。