大数跨境

不靠 Windows 兼容层:160 万行 C++ 的《命令与征服》,完成鸿蒙真机原生迁移验证

不靠 Windows 兼容层:160 万行 C++ 的《命令与征服》,完成鸿蒙真机原生迁移验证 ByteWell AI
2026-07-10
16

点击上方蓝字,关注我们

企业咨询与生态合作:contact@bytewell.cn

这不是小游戏 Demo,也不是模拟器;我们以 2003 年 Windows 3D RTS 引擎为验证对象,打通 DirectX 8、DXVK、Vulkan 到鸿蒙 HAP 的关键链路。

这次验证的价值不在游戏本身,而在它集中覆盖了旧 C/C++ 图形程序迁移到鸿蒙时最棘手的几类问题:旧图形接口、移动 GPU 能力差异、压缩纹理、HAP 沙箱、输入与生命周期,以及开源许可证边界。

160万
9
6
多端
行 C++ 游戏
底层库上鸿蒙
已验证开源项目
目标形态

同一条工具链上,Qt、SDL3、GLFW、OpenCL、CPython 等一批底层库已完成鸿蒙适配。迁移目标同时覆盖鸿蒙手机/平板/PC,以及开源鸿蒙

01

为什么选《命令与征服》


《命令与征服:将军 - 绝命时刻》发行于 2003 年,是 C&C 系列中面向 Windows PC 的 3D RTS,也是一类典型的Windows 时代大型 C++ 图形程序:160 万行 C++、自研三维引擎、DirectX 8 图形接口,音频、视频、字体都深度依赖当年的 Windows 生态。

DirectX 8 是 Windows 独占接口,鸿蒙上没有任何现成的运行环境。我们的做法是经 DXVK——广泛用于 Steam Deck / Proton 生态的开源图形翻译层——把它翻译成鸿蒙 Mali GPU 原生支持的 Vulkan:

DirectX 8  →  DXVK  →  Vulkan

但 DXVK 从设计第一天起主要面向桌面显卡。到了鸿蒙和移动 GPU 上,窗口、沙箱、GPU feature、纹理格式与打包运行环境都需要重新处理。真正的难点,不是把代码编过去,而是让整条图形链路在真机上稳定闭合。

从源码交叉编译、链接、HAP 打包,到窗口创建、图形栈、数据加载与界面渲染,整条链路真实运行在设备上。不是模拟器,不是云游戏,不是套壳。

而且不只是渲染出一张画面——主菜单的按钮点击全部生效,界面有真实响应。渲染管线、事件分发、状态机,都在正常工作。

CHZ-AL00  ·  Mali-G610  ·  HarmonyOS 6.1  ·  原生 ARM64 编译

选择它,不是因为游戏本身,而是因为它把图形、资源、窗口、输入、沙箱和构建链路的问题压在了同一个样本里。

02

不止一个游戏,是一整条流水线


只产出「一个能跑的游戏」,不足以说明迁移能力。真正的产出,是一条可复用的底层库迁移闭环:

能力识别 → 交叉编译与探针 → 平台边界 → 打包
→ 真机验证 → 许可与声明 → 报告 → 覆盖率门禁

沿着这条流水线,已跑通并留下真机证据的包括:

SDL3  完整鸿蒙平台后端:XComponent、EGL、Vulkan、OHAudio、输入、生命周期

OpenCL  真机运行时探测通过,Mali-G610 上 OpenCL 3.0 计算核可用

GLFW  新增鸿蒙平台后端,通过真机输入、剪贴板、生命周期压测

Scintilla / Lexilla  桌面编辑器控件拆为「底层能力 + ArkUI 界面重建」,真机验证输入法上屏、撤销重做、焦点序

zlib / libpng / curl / OpenSSL  基础依赖闭包,经 vcpkg 鸿蒙三元组构建

CPython 3.14  交叉编译上鸿蒙,带 ctypes 与 libffi 的应用内隔离运行时

其中一个架构决定,比上面任何一条都重要:我们没有让 SDL3、GLFW、Qt 各自沉淀一套窗口、输入与生命周期实现,而是抽出统一的鸿蒙 Surface Bridge 合同,上层框架只挂适配器。

移植第一个库最贵,第二个就应该显著便宜。这是工具链化能力和一次性项目的区别。

03

Qt:把真实桌面应用接进鸿蒙


存量行业软件里,Qt 绕不开。它难的不是「能不能编过」,而是一个桌面应用默认依赖桌面 OS:窗口、菜单栏、工具栏、文件对话框、剪贴板、拖放、网络 TLS、打印、系统托盘、外链跳转,都要重新落到鸿蒙应用模型里。

我们的处理方式不是把 Qt 页面逐页翻成 ArkUI,也不是逐个项目临时打补丁,而是在 Qt for HarmonyOS / OpenHarmony 的官方能力上补一层项目级适配:MainNode / XComponent 宿主、ArkTS 模块桥、Qt runtime/plugin 打包、文件 URI 桥、输入与生命周期、真机 smoke

保留 Qt 主体  QWidget / Qt 模型尽量不动,把桌面 executable 改造成可被 HAP 承载的 OHOS arm64 共享库。

补齐桌面能力  文件 open/save 经系统 picker 与 URI materialize / flush 落地;openUrl、网络 TLS、剪贴板、拖放、打印、托盘、外部命令逐项适配或降级。

留下真机证据  自动安装、启动、hilog、layout、截图和动作化 smoke,验证菜单、工具栏、文本输入、文件路径与触控滚动。

Qt 桌面应用在鸿蒙 PC 上以原生窗口运行

FeatherPad 文本编辑器在鸿蒙真机上的截图证据

我们已经不只跑了 Calculator。FeatherPad(文本编辑器)已在手机真机完成安装、启动、截图与动作化 smoke:菜单栏、工具栏、编辑区、软键盘、文件打开/另存为和长文本触控滚动都进入验证;qView(图片查看器)验证了资源、图片打开与显示链路。

SpeedCrunch、KDiff3、KeePassXC、Transmission Qt 四个真实开源项目 4/4 通过迁移压力测试回归,依赖缺失为 0;FeatherPad 与 qView 也已产出对应工程与构建证据。

截图、hilog、layout 和 smoke 报告都会留存。迁移结果不是口头描述,而是可复测的工程证据。

04

这条路,还能通到哪里


一个 2003 年、深度绑定 Windows 的 C++ 图形程序能完成鸿蒙原生运行验证,说明这条链路已经覆盖了一组足够复杂的平台问题。

✅ 安卓原生游戏——覆盖其中一部分问题。安卓本就是 ARM、OpenGL ES / Vulkan,图形接口与鸿蒙的距离更近;上层 Java / Kotlin 代码,则进入我们已有的 AI 翻译与校验链路。

✅ 存量 Qt / C++ 桌面与工业软件——主战场。Qt 项目优先保留 Qt 主体,通过鸿蒙宿主和平台桥接落地;非 Qt 界面层再按需 ArkUI 重建,核心逻辑编成原生库。

⚠️ 闭源商业引擎(Unity / Unreal)——这类项目优先跟随官方引擎适配。我们更适合覆盖官方适配之外的长尾:自研引擎、老游戏、行业里的 C/C++ 图形程序。

❌ Windows 兼容层 / 跑 exe——我们明确不做。我们的路线是把软件迁成鸿蒙原生工程,而不是把鸿蒙变成 Windows 运行环境。

图形层要真机闭合;Qt 桌面应用优先保留 Qt 主体;需要重建的界面层,才进入 ArkUI。

05

我们在鸿蒙的官方路线上


我们没有另起炉灶。整条链路走的都是鸿蒙官方路径:Qt 官方 QPA / MainNode、XComponent、NAPI、ArkUI、DevEco、hvigor、vcpkg 的 OHOS 三元组。不重造平台后端,产出的是标准鸿蒙工程与 HAP。

合规上:源码全程不出域,支持私有化与气隙部署;开源许可与 NOTICE 声明随迁移自动产出;商业迁移引擎与任何 GPL 代码边界清晰。

这意味着我们迁出来的东西,长在鸿蒙生态里,不是长在它旁边。

06

三类能力


应用层  Android / iOS 源码,以及 Windows 应用的界面层源码 → ArkTS / ArkUI;移动端已在 65 个项目上实测验证,覆盖鸿蒙手机/平板/PC 与开源鸿蒙

原生层  Windows / Linux C/C++、Qt 桌面与工业软件 → 鸿蒙原生库与标准工程,覆盖鸿蒙手机/平板/PC 与开源鸿蒙

图形栈  DirectX → DXVK → Vulkan,老游戏与图形程序

这三类能力合起来,指向同一个落点:鸿蒙手机/平板/PC 与开源鸿蒙生态里的存量软件产能——工控、能源、交通、医疗、金融终端,动辄十几年历史、几十万行代码,没人再敢轻易重写。

随着鸿蒙手机/平板/PC 与开源鸿蒙生态铺开,生态需要的不只是新应用,也包括对存量桌面与行业软件的迁移能力。人力逐个重写是线性的,难以承接集中释放的迁移需求——这正是一条迁移流水线存在的意义。

07

把下一批真实项目跑上真机


我们接下来希望接入的,不是更多演示 Demo,而是有真实历史包袱的存量软件:源码、依赖、窗口、文件、网络、打印、外设、真实终端和验收标准都在。

真实项目联合验证——Qt / C++ / Windows 桌面与行业软件,从扫描、适配、构建、打包到真机截图证据。

鸿蒙手机/平板/PC 与开源鸿蒙终端适配——在更多设备上补齐窗口、输入、文件、网络、打印、外链打开等能力。

私有化迁移流水线——源码不出域,输出风险报告、适配补丁、HAP/App、截图 / hilog / smoke 验收包。

真实项目迁移、鸿蒙手机/平板/PC 与开源鸿蒙适配、私有化与气隙部署咨询:contact@bytewell.cn

关于源码与版权

2025 年 2 月,EA 以 GPL v3 协议开源了《命令与征服》多款经典作品的源代码,其中包括 Generals 与 Zero Hour。本次移植基于该开源代码及社区跨平台分支。

EA 仅开源源代码,美术、音频、关卡等全部资产版权仍归 EA,且未授予任何商标与形象权利。运行游戏需玩家自行拥有正版,ByteWell 不提供、不分发任何游戏数据。

我们对开源代码的改动遵循 GPL v3。本文所述的商业迁移引擎与之独立,不含 GPL 代码。

元启弘科(北京)信息技术有限公司

官网:https://www.bytewell.cn

点击文末「阅读原文」,直达官网


【声明】内容源于网络
0
0
ByteWell AI
AI Agent驱动的应用跨平台迁移引擎
内容 1
粉丝 0
ByteWell AI AI Agent驱动的应用跨平台迁移引擎
总阅读13
粉丝0
内容1