在上一篇文章《兜兜转转,我又开始研究 Windows 系统》中,分析了微软多年深耕 Windows,早已筑牢一道深不可破的护城河。即使在国产替代的大潮下,我们还是离不开 Windows 应用。
为了让 Windows 应用运行在国产系统上,有多种方案,目前最常见的方案就是 Wine。
Wine 是一个开源项目,它在各种 Unix 变体操作系统之上重新实现了微软 Windows 操作系统的部分功能。Wine 主要面向 Linux 和 macOS,但也可以运行于 FreeBSD、NetBSD、Solaris 等系统。对用户而言,这意味着他们可以在非 Windows 系统上运行原本为 Windows 编写的软件。
Wine 不包含任何微软拥有的代码,因此无需 Windows 许可证即可运行 Wine。相反,Wine 开发者将 Windows 操作系统的各个组件重新编写,使得在 Wine 上运行的软件“以为”自己正在 Windows 系统中运行,实际上却是在例如 Linux 的环境中。
举个简单的例子,考虑 Windows 的 CreateFileA API。在 Windows 上,一个应用可能会这样调用它:
CreateFileA(
"C:\\some_file.txt", // lpFileName
GENERIC_WRITE, // dwDesiredAccess
0, // dwShareMode
NULL, // lpSecurityAttributes
CREATE_ALWAYS, // dwCreationDisposition
FILE_ATTRIBUTE_NORMAL, // dwFlagsAndAttributes
NULL // hTemplateFile
);
而 Wine 会将该调用转换为 Linux 的 open 调用:
open(
"/home/aeikum/.wine/drive_c/some_file.txt", // path
O_WRONLY | O_CREAT, // oflag
0644 // creation mode
);
然后,Wine 会将返回的文件句柄返回给应用程序,应用程序便可使用类似的映射(如将 WriteFile 映射到 Linux 的 write)来写入文件。当然,Wine 中对 CreateFileA 的实际实现要复杂得多(例如路径转换等),但上述示例足以说明 Wine 的基本做法。
Wine 是一个开源项目,“上游”(Upstream)Wine 是 Wine 的“官方”版本。Wine 项目对代码质量有着严格要求,注重正确性,包含大量单元测试以验证 Windows 的行为。向 “上游”(Upstream)Wine 提交补丁,必须附带单元测试,并且必须通过现有测试。这就导致许多有用但尚未充分验证的补丁无法被及时合并。比如说针对 deepin 系统的整合优化,就很难被合并到上游。此外, Wine 缺乏商业支持,无法及时响应用户需求。因此,Wine 项目衍生出了许多发行版。
目前已知存在数百个 Wine fork,但以下几个 fork 最为知名:
deepin‑wine 是深度操作系统(deepin)团队在上游 Wine 基础上,结合国产化需求与桌面深度集成做的一套定制化 Wine 运行环境,主要特点有:
为提升 Linux 系统对 Windows 应用的兼容能力,deepin-wine 团队自 2014 年成立起便持续探索,从技术验证到产品化落地,从单一功能到全场景兼容,十年间的每一步突破都旨在构建更完善的生态闭环。
如今,这一探索迎来重要里程碑 —— 统信 Windows 应用兼容引擎官网正式上线,标志着兼容技术从工具迭代迈向生态共建的新阶段。






统信 Windows 应用兼容引擎官网正式启用,标志着兼容技术从工具迭代迈向生态共建!
官网(https://wine.deepin.org/)提供详细教程、开发文档和论坛入口,支持用户从“确认兼容”到“一键安装”的全流程。

欢迎各位朋友加入 deepin-wine 用户队伍,参与 X86 Wine 应用的迁移投递,齐心协力推动 Linux 系统上 Windows 应用兼容技术的持续进步,为用户打造更加多元、完善的应用生态体验。