Windows 安装程序能在 Wine 下完整跑完，只能说明一次实验成功，还谈不上完成迁移。

Wine 11.0 让这项实验更值得尝试。2026 年 1 月发布的稳定版宣布完整支持新版 WoW64 架构，移除了单独的 wine64 加载器，在内核支持时启用 NTSYNC；这个版本还汇集了约 6,300 项改动和 600 多项错误修复。[1] 对于仍要维持一款棘手 Windows 桌面应用的组织，这些变化足以成为重新评估虚拟机成本的理由。

但这些变化不足以支持 Wine 11 直接打开唯一仍在正常工作的前缀。

安全的采用方式要安排三个刻意保持差异的环境：原封不动、继续使用旧 Wine 运行时的前缀，由其克隆并交给 Wine 11 升级的前缀，以及按照已记录输入全新创建的 Wine 11 前缀。三者放在一起，才能回答单次测试覆盖不了的问题：现有状态能否跨过升级关口？应用能否脱离累积多年的状态继续工作？新版 Wine 改动前缀后，团队能否恢复服务，避开给前缀降级这条险路？

题图拍摄的是 WineConf 2008 期间的 Alexandre Julliard。今日版本背后的项目已经延续多年，也提醒采用者：兼容性要在时间中持续维护，运行方法同样要把时间纳入考虑。[8]

把 Wine 11 作为迁移项目管理

Wine 前缀是一个保存 Windows 侧状态的目录，其中包括注册表数据、配置、虚拟驱动器，以及 Wine 进程使用的协调数据。WINEPREFIX 用来选择该目录，因此同一个 Unix 账户下可以并存彼此独立的 Wine 环境。[2] 前缀很适合作为测试与回滚的基本单位。只有创建前缀所需的输入已经记录齐全，它才可以随时重建。

Wine 11 还带来一个需要明确作出的选择。WINEARCH=wow64 会在 64 位前缀中选用新版 WoW64 模式。Wine 11.0 对应版本的手册说明，前缀创建时其架构便会固定；现有 64 位前缀仍可在 win64 与 wow64 之间切换，纯 win32 前缀则无法转换为 64 位前缀。[2] 决定就地升级之前，先盘点当前前缀。若它是 32 位，全新创建这条通道既用于诊断，也会进入最终迁移目标的首要候选。

启动器也要纳入审计。Wine 11 以统一的 wine 加载器取代了单独的 wine64 二进制文件；对于混合 32/64 位前缀，当脚本意在启动一对程序文件中的 32 位版本时，存在需要显式写出路径的情况。[1] 搜索桌面文件、服务单元、封装脚本、监控检查和应用更新程序。图形界面的冒烟测试发现不了仍在夜间调用 wine64 的任务。

其他版本变化也应落实到验收计划中，不能只留在庆祝式更新日志里。NTSYNC 会在可用时改变同步行为。X11 驱动如今优先通过 EGL 运行 OpenGL，同时保留 GLX 作为后备方案。[1] 对时序、图形或窗口行为敏感的应用，需要在实际目标内核、图形栈和会话类型上完成有代表性的测试。

建立三条测试通道

第一步是让旧环境正常停止。wineboot --shutdown 会模拟一次关机，--kill 则直接终止进程而不做清理；创建快照之前，后者不适合作为默认选择。[3] 随后使用文件系统快照，或采用能保留所有者、权限、符号链接和完整前缀的复制方法，不能只复制 drive_c。

三条通道各有明确任务：

1. 冻结基线： 保留当前前缀、当前 Wine 软件包、当前启动器和一份已知的数据检查点。禁止 Wine 11 打开这个前缀。它是回滚能力的实证。
2. 升级候选： 从基线克隆一份副本，只允许固定版本的 Wine 11 运行时打开，并使用 wineboot --update 更新。它用于检验真实累积状态能否跨过版本界线。[3]
3. 全新对照： 通过 wineboot --init 初始化一个新的 Wine 11 前缀，再使用已记录的安装介质重新安装应用。它用于检验 Wine 11 和应用在摆脱多年注册表修改、陈旧 DLL 与废弃实验后能否工作。[3]

命令形式很简单，真正需要严谨安排的是其外围的运行管控：

WINEPREFIX=/srv/wine/ledger-upgrade WINEARCH=wow64 wineboot --update
WINEPREFIX=/srv/wine/ledger-clean WINEARCH=wow64 wineboot --init

这些路径仅作示例，不能直接当作复制方案。前缀中会保存绝对路径的驱动器映射、用户专属设置、凭据、许可状态与应用数据。Wine 的 FAQ 说明前缀可以移动或复制，每个前缀也拥有自己的 wineserver；同一份文档同时警告，不要让多个用户共享一个正在运行的前缀。[5] 在应用条件允许时，应为每位用户或每台主机准备经过测试的独立前缀，绝不能把单个可写目录改成网络共享式的伪安装环境。

三者之间的对照，比单独观察任一候选环境更有价值。两个 Wine 11 环境若以同样方式失败，应排查 Wine、应用或宿主技术栈的回归。若只有升级后的副本失败，问题指向前缀内长期累积的状态。若全新对照可以工作，却保留不了必要设置或激活状态，余下的难点落在数据与配置迁移，基础兼容性已经得到验证。

用构建清单取代手工调校

只有其他运维人员也能复现，全新对照环境才经得住检验。将环境记录成一份小型发布清单：

• Wine 软件包的准确版本、构建来源、仓库，以及 wine --version 的输出；
• 前缀架构，以及启动器预期调用 32 位还是 64 位程序文件；
• 安装程序的确切版别、版本号、文件名与校验和；
• 宿主侧的图形、音频、字体、媒体、USB 与内核依赖；
• 添加的每一个运行库、字体、Winetricks verb 或原生 DLL，包括其版本与来源；
• 每一项 WINEDLLOVERRIDES 值，以及它所解决的具体症状；
• 各应用的 winecfg 设置、桌面尺寸、驱动器映射、区域设置与输入方式假设；
• 启动命令、工作目录、数据路径、敏感信息存放位置与许可操作流程。

Wine 可在 winecfg 中为单个应用设置配置，包括 DLL 加载顺序和显示选项。[4] 某项临时处理若只属于一个程序文件，就应限定在这个范围内。覆盖整个前缀的原生 DLL 设置，有时会修好目标程序，却悄悄破坏其更新程序或辅助进程。Wine 自身的指南警告，覆盖核心库会让 Wine 或应用陷入无法使用的状态；向上游报告回归之前，还要在不使用原生覆盖项的条件下复现问题。[4]

清单应与自动化构建程序或至少一套脚本化步骤放在一起。对话框截图可以留作证据，自动化仍要另行落实。若某一步只能以交互方式完成——许可激活最为常见——就要写清它发生的时间、获准执行的人、绑定的机器身份，并依据法律与技术条件判断克隆前缀能否部署。

复现能力与隔离能力分属两件事。前缀隔开的是 Wine 状态，Unix 权限仍由宿主账户决定。通过 Wine 运行的 Windows 软件，通常能访问该 Unix 账户可以访问的内容，默认驱动器映射也存在暴露大范围宿主路径的风险。[5][7] 对于来源不受信任或影响较大的应用，需要设置操作系统层面的安全隔离：专用 Unix 账户、强制访问控制、面向桌面负载设计的容器，或虚拟机。删除一个驱动器盘符，远不足以构成安全方案。

测试会改变状态的实际工作

“能够启动”只够写进测试计划的第一行，后面仍有完整验收。对旧基线、升级副本和全新对照运行同一套验收测试；行为出现差异时，保留终端输出和相关 WINEDEBUG 日志。[2]

测试应使用应用的真实工作流程：

• 打开有代表性的新旧文档，编辑、保存、关闭后重新打开；
• 沿生产环境的实际链路导出和打印，测试范围不能只到本地文件；
• 检验实际用户依赖的剪贴板、字体、键盘布局或输入法、DPI 缩放、多显示器与无障碍工具；
• 通过真实的代理、TLS、文件共享、数据库或单点登录链路完成身份验证；
• 测试应用更新、辅助进程、计划任务、崩溃恢复与正常关机；
• 配合目标主机驱动，测试扫描仪、USB 设备、加密狗、音频接口或图形功能；
• 重启宿主机，并验证文档所载的启动器可以重新建立预期环境。

Wine 的回归测试指南建议先备份前缀，并在全新前缀中核验问题，再逐步收窄行为回归；若可以稳定复现的 Wine 回归依然存在，后续流程将进入版本测试与 git bisect。[6] 全新对照也让运维团队直接完成同样的首轮诊断分流，省去让每位用户都成为 Wine 开发者的要求。

差异要记录成证据，不能只留下口耳相传的说法。“打印失败”提供的信息太少。“在 Wine 11.0 下，升级副本通过 CUPS 打印时会产生空白的第二页；全新对照与旧基线均未出现”则标明了失败通道、工作流程、运行时和可观察结果。随记录附上测试文档、输出、日志、软件包版本，以及不含业务数据的最小复现步骤。

正式推广的门槛还包括功能一致以外的要求。对时序敏感的工作要测量启动和任务延迟。让有代表性的用户完成一次正常工作时段，演练故障恢复，并确认备份工具捕获了真正重要的数据，而不只是最容易归档的前缀目录。

前缀回滚要与数据回滚配对

冻结基线只有与旧版 Wine 运行时配套时才有用。Arch Linux 的独立指南警告，前缀无法向前兼容：新版 Wine 一旦更新前缀，旧版 Wine 就会面临无法继续使用它的情况。[7] 因此，回滚要同时选用原封不动的前缀与固定版本的旧 Wine 软件包。把升级后的副本交给旧版二进制文件打开并寄望成功，不属于回滚方案。

配置可以由此恢复，业务状态却未必随之回到原点。Wine 11 试点期间，要预先考虑应用对文档、本地数据库、共享数据库模式、激活计数器或远端服务产生的改动。切换之前，要给每一个可写位置分类：

• 外部且向后兼容： 两套环境都能读取，但切换期间只允许其中一套写入。
• 外部且有版本： 建立检查点，并记录供应商支持的逆向恢复流程。
• 位于前缀内： 另行提取或备份，并采用能保证应用数据一致性的操作步骤。
• 远端或不可逆： 演练补偿操作；若无法补偿，则明确仅回滚前缀不足以覆盖此类变化。

除非应用明确支持，否则应避免旧环境和新环境同时写入。表面的便利，会在最糟糕的时刻制造一项数据对账工程。维护时段、单一写入方、数据检查点与明确指定的决策时点，能让回滚界线清楚可见。

正式启用之前要演练逆向流程：正常停止候选环境，选回旧启动器与 Wine 运行时，恢复或重新连接相应的数据状态，启动应用，完成一次读取和一次写入，再核验下游系统。记录耗时，也记录有权作出决定的负责人。目录即使保留在磁盘上，也要完整跑过这一轮，才称得上回滚计划。

明确兼容环境由谁负责

对于用户态依赖、文件和工作流程都可以接受测试的自成一体桌面工具，Wine 是很合适的迁移目标。若软件依赖 Windows 内核驱动、深度介入系统的端点组件、脆弱的设备过滤器、不受支持的反作弊或 DRM 系统、绑定机器的激活方式，或明确要求 Windows 的供应商合同，Wine 的适配度就会降低。Wine 的 FAQ 明确说明，Wine 无法用 Windows 硬件驱动代替宿主系统驱动。[5]

团队成熟度与应用兼容性同样重要。对于一款关键程度较低的应用，小团队也能承担维护责任，前提是指定负责人固定运行时版本、保存清单、重建全新前缀、运行验收套件，并维持一套经过测试的回滚方案。面向一批设备部署时，还需要受控的软件包来源、配置管理、按主机或用户划分的前缀归属、自动冒烟测试、日志收集、分阶段推广，以及能够区分应用、Wine 与宿主故障的事件处理流程。

若无人负责这些工作，保留虚拟机是对运行责任的如实安排。此时，虚拟机给出的运维约定会更清晰。

当应用不再依赖最初成功启动它的那个人脑中的记忆，Wine 11 迁移才真正完成。三个前缀把这份记忆变成证据：一个环境证明旧服务可以恢复，一个检验累积状态能否迁移，另一个则证明最终结果能否重新创建。

来源

1. WineHQ，〈Wine 11.0 Released〉——稳定版变更，包括新版 WoW64 支持完成、统一加载器、NTSYNC 的使用、图形改动，以及该版本的改动与错误修复总数。
2. WineHQ，Wine 11.0 的 wine(1) 手册源文件——关于 WINEPREFIX、WINEARCH、架构持久性、DLL 覆盖与调试通道配置。
3. WineHQ Wiki，〈wineboot〉——前缀初始化与更新行为、正常关机，以及不清理直接终止进程。
4. WineHQ Wiki，〈winecfg〉——各应用配置、DLL 加载顺序，以及原生覆盖项的注意事项。
5. WineHQ Wiki，〈FAQ〉——前缀复制与改名、wineserver 分离、多用户使用指南、沙盒限制与硬件驱动界线。
6. WineHQ Wiki，〈Regression Testing〉——在全新前缀中复现、备份前缀、逐步收窄回归范围，以及 git bisect。
7. ArchWiki，〈Wine〉——关于独立前缀、向前兼容性、宿主依赖与前缀隔离限度的独立运行指南。
8. Wikimedia Commons，〈File:Alexandre Julliard.jpg〉——照片来源、WineConf 2008 背景、作者署名、尺寸与 CC BY-SA 3.0 许可。