尧图网页设计 
1. 项目缘起为什么要在 iOS 上折腾 Wine第一次看到 Madeira 这个代号是在一个跨平台兼容层的讨论帖里。简单说Madeira 是一套把 Windows 应用搬到 iOS 设备上运行的技术方案核心思路是把 Wine 的 Windows API 翻译层、FEX-Emu 的 x86-64 指令翻译层以及 DXMT 的 Direct3D 到 Metal 转译层串起来让原本只能在 Windows 上跑的 exe 程序在 iPhone 或 iPad 上也能启动、渲染、响应触摸。它解决的不是我想在手机上玩某个小游戏这种轻量需求而是我手上只有一台 iPad但某个专业工具、老版本软件、或者特定 Windows 程序没有 iOS 原生版本这类硬需求。适合读这篇的人分三类一是想在 iOS 上跑 Windows 程序但被各种报错劝退的折腾党二是对 Wine、FEX-Emu、DXMT 这套技术栈好奇、想知道它们各自负责哪一段的开发者三是做 iOS 应用兼容性测试、需要理解跨架构运行原理的工程人员。我不会只丢一堆命令而是把每一层为什么这么设计、参数怎么算、坑在哪里讲清楚。热词里出现的 wine 乱码、麒麟 wine 助手、统信 wine 兼容组件这些本质都是同一类问题的不同平台变体理解了 Madeira 的架构这些问题的排查思路是相通的。需要先说明一点Madeira 目前不是一个开箱即用的商业产品它更像一个技术集成方向把几个成熟开源项目拼在一起。所以下面讲的内容一部分是基于这些组件公开能力的合理推演一部分是我在实际搭建类似环境时踩过的坑我会明确区分哪些是已验证的、哪些是按常见实践应该这样做。2. 架构拆解Wine、FEX-Emu、DXMT 各自管什么2.1 三层翻译的分工逻辑要理解 Madeira先得把Windows 程序在 iOS 上跑起来这件事拆成三个独立问题。第一个问题是系统调用和 API 的差异。Windows 程序调用的是kernel32.dll、user32.dll这些iOS 根本没有。Wine 的作用就是提供一套兼容实现把这些 Windows API 映射到 POSIX 接口上。它不模拟硬件只是翻译函数调用所以效率比完整虚拟机高得多。第二个问题是CPU 指令集差异。Windows 程序编译出来是 x86 或 x86-64 指令而 iOS 设备是 ARM64。FEX-Emu 就是干这个的它把 x86-64 指令动态翻译成 ARM64 指令。这里有个关键点FEX-Emu 是动态二进制翻译不是解释执行它会缓存翻译结果所以第二次执行同一段代码会快很多。第三个问题是图形 API 差异。Windows 游戏和软件大量使用 Direct3DiOS 只有 Metal。DXMT 负责把 D3D 调用转成 Metal 调用。为什么不用更老的 DXVK因为 DXVK 是转成 Vulkan而 iOS 对 Vulkan 支持很有限Metal 才是原生路径DXMT 直接对接 Metal少一层转换延迟更低。提示这三层是串联的任何一层出问题程序都跑不起来。排查时一定要先定位是哪一层的锅不要一上来就乱改配置。2.2 为什么选这套组合而不是别的有人会问为什么不直接用虚拟机因为 iOS 不允许 JIT 之外的动态代码生成完整虚拟机性能损耗太大而且苹果的沙盒限制让虚拟机很难拿到足够的权限。Wine 路线是翻译而非模拟在 iOS 这种受限环境里是更现实的选择。那为什么 FEX-Emu 而不是 QEMU 的用户态模拟QEMU 更通用但更重FEX-Emu 专注 x86-64 到 ARM64针对性强而且它对 Wine 的适配做得更细比如对 Windows 的 SEH 异常处理有专门优化。DXMT 而不是 MoltenVK 路线则是因为 D3D 到 Metal 的直接映射能省掉 Vulkan 这一层的开销对帧率敏感的场景更友好。这套组合的代价是兼容性覆盖不如完整虚拟机一些依赖底层硬件特性的程序会失败。但对于大多数办公软件、老游戏、工具类程序这套方案已经够用。2.3 组件版本与依赖关系搭建前必须理清版本。Wine 建议用较新的稳定分支太老的版本对 FEX-Emu 的集成支持不好。FEX-Emu 要用支持 ARM64 宿主的最新版DXMT 则要匹配对应的 D3D 版本。三者版本不匹配是新手最常见的翻车点。组件职责关键版本考量WineWindows API 翻译选支持 FEX 集成的分支避免过老FEX-Emux86-64 到 ARM64 翻译必须匹配宿主 ARM64开启 JIT 缓存DXMTD3D 到 Metal 转译匹配目标程序的 D3D 版本3. 环境准备从零搭建 Madeira 运行环境3.1 iOS 侧的前置条件在 iOS 上跑这套东西绕不开开发者模式。热词里ios 26.3.1 怎么开发者模式ios 开发者模式搜索量很高说明很多人卡在这一步。开启路径通常在设置里的隐私与安全性相关选项不同系统版本位置略有差异。开启后设备才允许安装非商店来源的应用包。然后是签名与证书。免费证书能用但有 7 天限制到期要重签。Xcode 从证书配置到上架的全流程里开发者证书、描述文件、Bundle ID 三者必须对应。如果你只是自己测试用免费证书加自签工具就够如果要长期稳定使用建议走正规开发者账号。注意iOS 对后台执行和内存占用限制很严Wine 这类需要较大内存和持续运行的程序在旧设备上容易被系统杀掉。建议用内存 4GB 以上的设备。3.2 获取与部署组件组件获取要走官方渠道。Wine 的源码或预编译包、FEX-Emu 的 release、DXMT 的对应版本都要从各自项目主页拿。热词里wine gecko 官方正版下载统信 wine windows 兼容组件下载反映的就是大家对来源可靠性的担忧这个担心是对的来路不明的包可能带后门或被篡改。部署顺序建议是先装 Wine 运行时再集成 FEX-Emu最后接 DXMT。每装完一层都做一次最小验证比如 Wine 装完先跑一个纯控制台程序确认 API 翻译通了FEX 装完跑一个 x86-64 的简单 exe确认指令翻译通了DXMT 装完再跑带图形界面的程序。这样出问题能快速定位。3.3 目录结构与配置约定建议把 Wine prefix也就是那个模拟的 C 盘目录单独放一个路径不要和系统目录混。配置上FEX-Emu 的 JIT 缓存目录要指向可写路径DXMT 的 Metal 着色器缓存也要给足空间。这些缓存在首次运行时会拖慢启动但后续会明显加速。# 示意性的目录约定实际路径按你的部署调整 export WINEPREFIX/path/to/madeira/prefix export FEX_CACHE/path/to/madeira/fex-cache export DXMT_CACHE/path/to/madeira/dxmt-cache4. 核心实操让第一个 Windows 程序跑起来4.1 最小验证控制台程序先行不要一上来就跑大型游戏。先找一个最简单的 Windows 控制台程序比如自己用 MinGW 编译一个打印 hello 的 exe。运行命令大致是让 Wine 加载这个 exe同时确保 FEX-Emu 作为翻译层被调用。如果这一步就报错重点看两类信息一是 Wine 报的 API 缺失说明某个 Windows 函数没被实现二是 FEX 报的指令翻译失败说明遇到了不支持的 x86 指令。前者要换 Wine 版本或打补丁后者要更新 FEX-Emu。4.2 图形程序DXMT 的接入与验证控制台通了之后跑一个带窗口的程序。这时候 DXMT 开始工作。常见现象是窗口能出来但黑屏或者花屏。黑屏多半是 D3D 设备创建失败花屏多半是着色器转译有问题。排查时先确认程序用的是 D3D9、D3D11 还是 D3D12不同版本 DXMT 的支持程度不一样。D3D9 最成熟D3D12 最挑。如果程序支持切换渲染后端优先切到 D3D9 或 OpenGL 试试。提示DXMT 的日志会记录每次 D3D 调用和 Metal 映射结果出问题时先看日志里第一个失败点不要盲目调参数。4.3 参数计算内存与缓存的分配FEX-Emu 的 JIT 缓存大小、Wine 的堆大小、DXMT 的着色器缓存上限这些参数不是随便填的。以 JIT 缓存为例太小会导致频繁重新翻译太大在 iOS 上可能触发内存告警。经验值是按目标程序代码段大小的 2 到 3 倍来估比如程序代码段 50MB缓存给 128MB 到 150MB 比较稳。Wine 的堆大小则要看程序峰值内存。可以用活动监视器观察原生运行时的占用再留 30% 余量。iOS 设备内存本来就紧张宁可保守一点。参数估算方法保守取值建议FEX JIT 缓存代码段大小 x 2~3128MB 起Wine 堆原生峰值 x 1.3按设备内存调整DXMT 着色器缓存按场景复杂度256MB 起5. 常见问题与排查实录5.1 乱码问题从 wine 乱码说起热词里wine 乱码wine 栏是乱码是高频问题。乱码根源通常是字体缺失或编码不匹配。Wine 默认不带 Windows 字体程序界面用的字体在 prefix 里找不到就会显示方块或乱码。解决办法是把常用 Windows 字体比如宋体、微软雅黑复制到 Wine prefix 的字体目录然后让 Wine 注册这些字体。另外要确认 locale 设置中文程序需要对应的区域设置否则编码转换会出错。这个思路和麒麟 wine 助手、统信 wine 组件里处理乱码的方式是一致的。5.2 启动失败分层定位法程序双击没反应或者闪退用分层定位法先看 Wine 是否成功加载 exe没加载就是路径或权限问题。再看 FEX 是否成功翻译入口指令失败就是指令集不支持。最后看 DXMT 是否成功创建设备失败就是图形层问题。每一层的日志都要单独看混在一起看会晕。我习惯把三层的日志输出到不同文件出问题时按顺序翻。5.3 性能问题卡顿与掉帧卡顿分两种CPU 瓶颈和 GPU 瓶颈。FEX-Emu 翻译本身有开销如果程序是 CPU 密集型卡顿主要来自翻译层。这时候可以调 FEX 的优化选项比如开启更激进的块编译。如果是 GPU 瓶颈看 DXMT 的转译效率复杂着色器转译慢会导致掉帧。注意iOS 设备发热降频很常见长时间跑重负载程序性能会随时间下降这是硬件限制不是配置问题。5.4 常见问题速查表现象可能原因排查方向界面乱码字体缺失/编码错补字体、查 locale启动闪退指令不支持更新 FEX-Emu黑屏D3D 设备创建失败查 DXMT 日志、切后端花屏着色器转译错更新 DXMT、简化着色器卡顿CPU 或 GPU 瓶颈分层测性能、调缓存6. 实操心得与避坑经验折腾这套东西最大的体会是不要贪快。很多人一上来就想跑 3A 游戏结果卡在第一步就放弃了。正确的节奏是先跑通控制台再跑通简单窗口最后才上复杂程序。每一步都验证出问题范围小好定位。第二个体会是日志是你的朋友。Wine、FEX、DXMT 都有日志而且信息量很大。新手容易忽略日志直接猜老手都是先看日志再动手。把日志级别调高虽然输出多但关键错误往往就在里面。第三个是版本管理。这套组件更新频繁新版本可能修了旧 bug 也可能引入新问题。建议固定一套验证过的版本组合不要盲目追新。我自己的做法是每个组件留一个已知可用版本出问题能回退。最后iOS 的沙盒和签名机制决定了这套方案不可能像桌面那样随意。免费证书 7 天过期、后台被杀、内存受限这些都是常态。接受这些限制把预期放合理折腾起来会舒服很多。如果只是偶尔用某个 Windows 程序评估一下是不是有 iOS 原生替代方案可能更省事。 iOS 运行 Windows 程序：Wine+FEX-Emu+DXMT 跨架构兼容层实战
1. 项目缘起为什么要在 iOS 上折腾 Wine第一次看到 Madeira 这个代号是在一个跨平台兼容层的讨论帖里。简单说Madeira 是一套把 Windows 应用搬到 iOS 设备上运行的技术方案核心思路是把 Wine 的 Windows API 翻译层、FEX-Emu 的 x86-64 指令翻译层以及 DXMT 的 Direct3D 到 Metal 转译层串起来让原本只能在 Windows 上跑的 exe 程序在 iPhone 或 iPad 上也能启动、渲染、响应触摸。它解决的不是我想在手机上玩某个小游戏这种轻量需求而是我手上只有一台 iPad但某个专业工具、老版本软件、或者特定 Windows 程序没有 iOS 原生版本这类硬需求。适合读这篇的人分三类一是想在 iOS 上跑 Windows 程序但被各种报错劝退的折腾党二是对 Wine、FEX-Emu、DXMT 这套技术栈好奇、想知道它们各自负责哪一段的开发者三是做 iOS 应用兼容性测试、需要理解跨架构运行原理的工程人员。我不会只丢一堆命令而是把每一层为什么这么设计、参数怎么算、坑在哪里讲清楚。热词里出现的 wine 乱码、麒麟 wine 助手、统信 wine 兼容组件这些本质都是同一类问题的不同平台变体理解了 Madeira 的架构这些问题的排查思路是相通的。需要先说明一点Madeira 目前不是一个开箱即用的商业产品它更像一个技术集成方向把几个成熟开源项目拼在一起。所以下面讲的内容一部分是基于这些组件公开能力的合理推演一部分是我在实际搭建类似环境时踩过的坑我会明确区分哪些是已验证的、哪些是按常见实践应该这样做。2. 架构拆解Wine、FEX-Emu、DXMT 各自管什么2.1 三层翻译的分工逻辑要理解 Madeira先得把Windows 程序在 iOS 上跑起来这件事拆成三个独立问题。第一个问题是系统调用和 API 的差异。Windows 程序调用的是kernel32.dll、user32.dll这些iOS 根本没有。Wine 的作用就是提供一套兼容实现把这些 Windows API 映射到 POSIX 接口上。它不模拟硬件只是翻译函数调用所以效率比完整虚拟机高得多。第二个问题是CPU 指令集差异。Windows 程序编译出来是 x86 或 x86-64 指令而 iOS 设备是 ARM64。FEX-Emu 就是干这个的它把 x86-64 指令动态翻译成 ARM64 指令。这里有个关键点FEX-Emu 是动态二进制翻译不是解释执行它会缓存翻译结果所以第二次执行同一段代码会快很多。第三个问题是图形 API 差异。Windows 游戏和软件大量使用 Direct3DiOS 只有 Metal。DXMT 负责把 D3D 调用转成 Metal 调用。为什么不用更老的 DXVK因为 DXVK 是转成 Vulkan而 iOS 对 Vulkan 支持很有限Metal 才是原生路径DXMT 直接对接 Metal少一层转换延迟更低。提示这三层是串联的任何一层出问题程序都跑不起来。排查时一定要先定位是哪一层的锅不要一上来就乱改配置。2.2 为什么选这套组合而不是别的有人会问为什么不直接用虚拟机因为 iOS 不允许 JIT 之外的动态代码生成完整虚拟机性能损耗太大而且苹果的沙盒限制让虚拟机很难拿到足够的权限。Wine 路线是翻译而非模拟在 iOS 这种受限环境里是更现实的选择。那为什么 FEX-Emu 而不是 QEMU 的用户态模拟QEMU 更通用但更重FEX-Emu 专注 x86-64 到 ARM64针对性强而且它对 Wine 的适配做得更细比如对 Windows 的 SEH 异常处理有专门优化。DXMT 而不是 MoltenVK 路线则是因为 D3D 到 Metal 的直接映射能省掉 Vulkan 这一层的开销对帧率敏感的场景更友好。这套组合的代价是兼容性覆盖不如完整虚拟机一些依赖底层硬件特性的程序会失败。但对于大多数办公软件、老游戏、工具类程序这套方案已经够用。2.3 组件版本与依赖关系搭建前必须理清版本。Wine 建议用较新的稳定分支太老的版本对 FEX-Emu 的集成支持不好。FEX-Emu 要用支持 ARM64 宿主的最新版DXMT 则要匹配对应的 D3D 版本。三者版本不匹配是新手最常见的翻车点。组件职责关键版本考量WineWindows API 翻译选支持 FEX 集成的分支避免过老FEX-Emux86-64 到 ARM64 翻译必须匹配宿主 ARM64开启 JIT 缓存DXMTD3D 到 Metal 转译匹配目标程序的 D3D 版本3. 环境准备从零搭建 Madeira 运行环境3.1 iOS 侧的前置条件在 iOS 上跑这套东西绕不开开发者模式。热词里ios 26.3.1 怎么开发者模式ios 开发者模式搜索量很高说明很多人卡在这一步。开启路径通常在设置里的隐私与安全性相关选项不同系统版本位置略有差异。开启后设备才允许安装非商店来源的应用包。然后是签名与证书。免费证书能用但有 7 天限制到期要重签。Xcode 从证书配置到上架的全流程里开发者证书、描述文件、Bundle ID 三者必须对应。如果你只是自己测试用免费证书加自签工具就够如果要长期稳定使用建议走正规开发者账号。注意iOS 对后台执行和内存占用限制很严Wine 这类需要较大内存和持续运行的程序在旧设备上容易被系统杀掉。建议用内存 4GB 以上的设备。3.2 获取与部署组件组件获取要走官方渠道。Wine 的源码或预编译包、FEX-Emu 的 release、DXMT 的对应版本都要从各自项目主页拿。热词里wine gecko 官方正版下载统信 wine windows 兼容组件下载反映的就是大家对来源可靠性的担忧这个担心是对的来路不明的包可能带后门或被篡改。部署顺序建议是先装 Wine 运行时再集成 FEX-Emu最后接 DXMT。每装完一层都做一次最小验证比如 Wine 装完先跑一个纯控制台程序确认 API 翻译通了FEX 装完跑一个 x86-64 的简单 exe确认指令翻译通了DXMT 装完再跑带图形界面的程序。这样出问题能快速定位。3.3 目录结构与配置约定建议把 Wine prefix也就是那个模拟的 C 盘目录单独放一个路径不要和系统目录混。配置上FEX-Emu 的 JIT 缓存目录要指向可写路径DXMT 的 Metal 着色器缓存也要给足空间。这些缓存在首次运行时会拖慢启动但后续会明显加速。# 示意性的目录约定实际路径按你的部署调整 export WINEPREFIX/path/to/madeira/prefix export FEX_CACHE/path/to/madeira/fex-cache export DXMT_CACHE/path/to/madeira/dxmt-cache4. 核心实操让第一个 Windows 程序跑起来4.1 最小验证控制台程序先行不要一上来就跑大型游戏。先找一个最简单的 Windows 控制台程序比如自己用 MinGW 编译一个打印 hello 的 exe。运行命令大致是让 Wine 加载这个 exe同时确保 FEX-Emu 作为翻译层被调用。如果这一步就报错重点看两类信息一是 Wine 报的 API 缺失说明某个 Windows 函数没被实现二是 FEX 报的指令翻译失败说明遇到了不支持的 x86 指令。前者要换 Wine 版本或打补丁后者要更新 FEX-Emu。4.2 图形程序DXMT 的接入与验证控制台通了之后跑一个带窗口的程序。这时候 DXMT 开始工作。常见现象是窗口能出来但黑屏或者花屏。黑屏多半是 D3D 设备创建失败花屏多半是着色器转译有问题。排查时先确认程序用的是 D3D9、D3D11 还是 D3D12不同版本 DXMT 的支持程度不一样。D3D9 最成熟D3D12 最挑。如果程序支持切换渲染后端优先切到 D3D9 或 OpenGL 试试。提示DXMT 的日志会记录每次 D3D 调用和 Metal 映射结果出问题时先看日志里第一个失败点不要盲目调参数。4.3 参数计算内存与缓存的分配FEX-Emu 的 JIT 缓存大小、Wine 的堆大小、DXMT 的着色器缓存上限这些参数不是随便填的。以 JIT 缓存为例太小会导致频繁重新翻译太大在 iOS 上可能触发内存告警。经验值是按目标程序代码段大小的 2 到 3 倍来估比如程序代码段 50MB缓存给 128MB 到 150MB 比较稳。Wine 的堆大小则要看程序峰值内存。可以用活动监视器观察原生运行时的占用再留 30% 余量。iOS 设备内存本来就紧张宁可保守一点。参数估算方法保守取值建议FEX JIT 缓存代码段大小 x 2~3128MB 起Wine 堆原生峰值 x 1.3按设备内存调整DXMT 着色器缓存按场景复杂度256MB 起5. 常见问题与排查实录5.1 乱码问题从 wine 乱码说起热词里wine 乱码wine 栏是乱码是高频问题。乱码根源通常是字体缺失或编码不匹配。Wine 默认不带 Windows 字体程序界面用的字体在 prefix 里找不到就会显示方块或乱码。解决办法是把常用 Windows 字体比如宋体、微软雅黑复制到 Wine prefix 的字体目录然后让 Wine 注册这些字体。另外要确认 locale 设置中文程序需要对应的区域设置否则编码转换会出错。这个思路和麒麟 wine 助手、统信 wine 组件里处理乱码的方式是一致的。5.2 启动失败分层定位法程序双击没反应或者闪退用分层定位法先看 Wine 是否成功加载 exe没加载就是路径或权限问题。再看 FEX 是否成功翻译入口指令失败就是指令集不支持。最后看 DXMT 是否成功创建设备失败就是图形层问题。每一层的日志都要单独看混在一起看会晕。我习惯把三层的日志输出到不同文件出问题时按顺序翻。5.3 性能问题卡顿与掉帧卡顿分两种CPU 瓶颈和 GPU 瓶颈。FEX-Emu 翻译本身有开销如果程序是 CPU 密集型卡顿主要来自翻译层。这时候可以调 FEX 的优化选项比如开启更激进的块编译。如果是 GPU 瓶颈看 DXMT 的转译效率复杂着色器转译慢会导致掉帧。注意iOS 设备发热降频很常见长时间跑重负载程序性能会随时间下降这是硬件限制不是配置问题。5.4 常见问题速查表现象可能原因排查方向界面乱码字体缺失/编码错补字体、查 locale启动闪退指令不支持更新 FEX-Emu黑屏D3D 设备创建失败查 DXMT 日志、切后端花屏着色器转译错更新 DXMT、简化着色器卡顿CPU 或 GPU 瓶颈分层测性能、调缓存6. 实操心得与避坑经验折腾这套东西最大的体会是不要贪快。很多人一上来就想跑 3A 游戏结果卡在第一步就放弃了。正确的节奏是先跑通控制台再跑通简单窗口最后才上复杂程序。每一步都验证出问题范围小好定位。第二个体会是日志是你的朋友。Wine、FEX、DXMT 都有日志而且信息量很大。新手容易忽略日志直接猜老手都是先看日志再动手。把日志级别调高虽然输出多但关键错误往往就在里面。第三个是版本管理。这套组件更新频繁新版本可能修了旧 bug 也可能引入新问题。建议固定一套验证过的版本组合不要盲目追新。我自己的做法是每个组件留一个已知可用版本出问题能回退。最后iOS 的沙盒和签名机制决定了这套方案不可能像桌面那样随意。免费证书 7 天过期、后台被杀、内存受限这些都是常态。接受这些限制把预期放合理折腾起来会舒服很多。如果只是偶尔用某个 Windows 程序评估一下是不是有 iOS 原生替代方案可能更省事。