企业官网建设流程全解析

Madeira项目概览：如何让iPhone单进程跑起整个Windows游戏栈

【免费下载链接】MadeiraRun x86-64 Windows PC games on jailed iOS via FEX-Emu + Wine + DXMT项目地址: https://gitcode.com/GitHub_Trending/mad/Madeira

Madeira 是一个让未越狱 iPhone 运行 x86-64 Windows PC 游戏的开源项目。它用 FEX-Emu（x86→ARM64 指令翻译）、Wine（Windows API 层）和 DXMT（D3D11→Metal 图形转换）三大技术，把一个完整的 Windows 游戏栈压缩进 iPhone 上的单个 Mach 进程，其中 wineserver 以线程而非独立进程运行。本文带你理解它的架构原理、"单进程"背后的硬核原因，以及从零构建安装的完整步骤。

一、Madeira 是什么：三大组件组成 iPhone Windows 游戏栈

Madeira 的思路可以概括为一句话：CPU 翻译交给 FEX-Emu，系统 API 交给 Wine，图形交给 DXMT，全部跑在一个 Swift/Metal 宿主应用里。项目定位是研究项目而非商业产品，目前 Thumper 和 ULTRAKILL 已可游玩。

🎮 一句话理解：游戏里的 x86 代码由 FEX 翻译成 ARM64 执行，调用 Windows API 时由 ARM64 原生的 Wine DLL 接管，画画面时由 DXMT 直接转成 Metal 调用——层层翻译，直达 iPhone 的 GPU。

二、为什么必须"单进程"：iOS 的硬性约束

这是理解 Madeira 最关键的一点：iOS 不允许fork()，所以传统 Wine 的"每个 Windows 程序一个进程"模型根本无法工作。

Madeira 的解决方案是单进程模型：

• wineserver 作为线程运行在主进程内，而不是独立守护进程，相关桥接逻辑见 WineProcessBridge.m；
• 每个 Windows"进程"（如 steam.exe、services.exe）实际是伪进程——同一个 Mach task 内的一个线程，没有任何进程隔离；
• 这也带来最棘手的问题：任何一个"进程"发生未处理的错误，都会杀死整个应用。因此项目在故障隔离（fault containment）上投入了大量工作，包括内存保护修复、辅助进程拦截门（[proc-gate]）等，细节记录在 STEAM_CEF_HANDOFF.md。

💡 单进程还意味着严格的内存纪律：可用的 CPU 虚拟地址空间约 64 GB，Jetsam 内存上限为 4096 MB，所有 JIT 内存必须提前以"双映射 RX/RW 池"一次性预留。

三、三层翻译架构拆解

FEX-Emu：x86-64 → ARM64 的即时翻译

FEX-Emu 的执行链路为：x86-64 字节 → 前端解码器 → IR（SSA）→ 优化 → ARM64 JIT 后端。在 iOS 上它面临的最大障碍是W^X 内存保护——页面不能同时可写又可执行。Madeira 借鉴了 MeloNX 的双映射技巧：同一块物理内存映射两个视图，一个只写（供编译器写入生成的代码）、一个只读执行（供 CPU 执行），从而彻底避免反复切换权限的开销，实现见 JITAllocator.c。

另一个关键设计是xtajit 接口：Wine 通过xtajit64.dll把 x86 代码交给 FEX，这意味着 Wine 成百上千个 DLL 都以 ARM64原生速度运行，只有游戏自身的代码才走模拟器——这是性能上最大的红利。

Wine：Windows API → Darwin 的原生翻译

Wine 采用PE/Unix 双半结构：

• PE 半边：Windows DLL 编译为 ARM64EC PE 二进制，随应用打包，可直接浏览 app/Madeira/arm64ec-windows/ 里的ntdll.dll、kernel32.dll等预编译产物；
• Unix 半边：原生库实现真实功能，通过__wine_syscall_dispatcher桥接到 Darwin/Mach API，iOS 定制的源文件位于build/ntdll-unix/、build/wineserver/等构建链中；
• 项目对上游 Wine 的改动以补丁形式管理，如 patches/wine-rpcss-scm-bootstrap.patch。

DXMT：D3D11 直通 Metal，少一层就是快一层

DXMT 把 DirectX 11直接翻译成 Metal，不经过 Vulkan 中转层（相比之下 DXVK 需要 DX11→Vulkan→Metal 两层）。它的特色包括：

• 着色器走DXBC → Apple AIR 位码 → Metal 库路径，贴合原生编译管线；
• 几何着色器转成 Metal mesh 着色器，绕开了 DXVK 在 Apple GPU 上的致命短板；
• 预计开销仅 5–15%，完整论证见 ARCHITECTURE_ANALYSIS.md 第 4 节。

四、如何构建 Madeira：从零开始的安装步骤

环境要求

构建流程

1. 克隆仓库（三个子模块指向含 iOS 改动的 fork，必须递归克隆）：

   git clone --recurse-submodules https://gitcode.com/GitHub_Trending/mad/Madeira

2. 按链构建：unix 侧 Wine 库、ARM64EC PE 模块、FEX、DXMT 各有独立构建脚本（build/*/build.sh），完整顺序和每一步产物都记录在 docs/BUILDING.md；

3. 编译 iOS 应用：xcodebuild构建 app/Madeira.xcodeproj，打包 IPA 后侧载到手机；

4. 自备 Visual C++ 运行时：微软 VC 运行时 DLL 不随仓库分发，获取方法见 tools/fetch-vcruntime.md；

5. 前缀保留：应用容器在重装后保留，游戏前缀（prefix）和存档不会丢失，前缀模板见 prefix-template.tar.gz。

⚠️ 注意：构建涉及 LLVM iOS 工具链、122 MB 的 llvm-mingw 工具链等多项仓库外输入，docs/BUILDING.md 逐一列出了每项的获取方式和校验和。

五、当前游玩状态与输入方案

输入方面，docs/CONTROLLERS.md 描述了完整的操控方案：物理手柄经 GameController 框架以 250 Hz 采样汇入 XInput，屏幕触控虚拟手柄合并为玩家 1，支持 A/B/X/Y、双摇杆、扳机键的完整映射，核心实现在 GamepadInput.swift 与 TouchGamepad.swift。

六、许可证与贡献须知

Madeira 采用GPL-3.0-or-later（见 LICENSE），分发的衍生作品必须保持开源。需要特别注意上游 fork 的许可差异：Wine fork 依据 LGPL-2.1 §3 转为 GPL-3.0-or-later；FEX 和 dxmt fork 保留 MIT 但修改部分为 GPL-3.0-or-later。逐组件许可文本在 LICENSES/，许可专题说明见 docs/LICENSING.md 与 THIRD-PARTY-NOTICES.md。

贡献者需注意：FEX-Emu 上游禁止 AI 生成代码，不要将本 fork 中的 AI 辅助改动直接提交回上游，细则见 CONTRIBUTING.md。

七、延伸阅读：项目关键文档导航

总结：Madeira 证明了"在 iOS 的沙箱与 W^X 约束下，把整个 Windows 游戏栈塞进一个进程"是可行的——用双映射 JIT 池、线程化 wineserver、xtajit 原生加速和 DXMT 直通 Metal，换来了 Thumper 142 FPS 的现实成绩。它仍是一个充满毛边的研究项目，但架构思路对任何想在移动端跑 Windows 负载的开发者都值得细读。

【免费下载链接】MadeiraRun x86-64 Windows PC games on jailed iOS via FEX-Emu + Wine + DXMT项目地址: https://gitcode.com/GitHub_Trending/mad/Madeira