奋战开源操作系统二十年：为什么编程语言是突破口？

【编者按】编程语言之于操作系统，意味着什么？本文作者飞漫软件创始人魏永明经过二十余年的操作系统开发探索，明确提出编程语言是自主基础软件，尤其是操作系统的重要抓手。如果说操作系统是基础软件生态里的皇冠，那编程语言就是王冠上的明珠。如果没有自己的编程语言，那所谓的自主，就是海市蜃楼、空中楼阁。由此，他走上了开源编程语言的探索与实践之路。

 

从低迷的 Linux 桌面系统说起

全世界范围内的开源运动浩浩荡荡，滚滚向前。Linux 内核作为开源软件中的杰出代表，在云计算、服务器端、 智能手机端、嵌入式系统中的成功举世公认。截止 2021 年底，Linux 在服务器领域占据了 96%的市场份额，在超级计算机领域几乎占领了全部市场，在云计算基础设施领域占据了 90%的市场份额，在智能手机领域也占有 85%的市场份额。现今，在人们日常的工作和生活中，Linux 内核几乎无处不在。但与此相反的，则是 Linux 桌面系统地位不断下滑。据统计，长期以来，Linux 桌面系统的市场份额徘徊在 2%左右，而原来被微软 Windows 压得喘不过气来的 macOS 系统，却在近几年取得了不小的进步，获得了超过 10%的市场份额。

自 2000 年以来，全球有众多公司如 Red Hat、SUSE 以及中国的若干企业一直在尝试打造基于 Linux 内核、GNU 工具以及 X Window、GNOME 或 KDE 的桌面系统。但二十年来，我们并没有得到一个可以媲美 Windows 或 macOS 的桌面系统，这其中的教训值得深思。究其原因，大家都会指点一二。比如 Linux 桌面系统的模仿痕迹太重，技术上始终跟随 Windows，也没有自己的产品特色；缺乏 Office 这样的关键应用软件；各种发行版满天飞，造成严重的碎片化问题，还导致应用之间的互兼容性问题等。

为什么二十年来，全世界有那么多企业和社区前赴后继、努力打造的 Linux 桌面系统，却始终无法走向大众市场，而仅仅局限于少数狂热的爱好者当中？

再以本人的亲身经历为例。笔者搞了二十多年嵌入式窗口和图形系统——MiniGUI，最初模仿 Win32 提供 C 语言的应用编程接口。在本世纪最初的十多年间，MiniGUI 在机顶盒、功能手机、数码相框等产品中得到了大量的应用。但自从 Google 开源发布了 Android 操作系统之后，包括 MiniGUI 在内的很多嵌入式基础软件，都遇到了前所未有的危机，这其中也包括针对嵌入式系统的输入法、字体、浏览器等多款软件产品。为了应对这一危机，我们也曾做出过一些尝试，比如提供类似 Visual Studio 一样的界面设计器、类 iPhone 的 UI 特效、对 Java J2SE 应用框架的支持等。然而，这些尝试和 Android 这种具有全新操作系统架构和应用框架的现代操作系统相比，实在不堪一击。

这引得我不得不思考：嵌入式领域是本世纪初兴起的产业，当时，我们在这个领域的基础软件水平和美国差不了多少，而且坐拥全球最大的消费类电子产品市场，但为什么在其后十多年的发展竞争中，我们仍然落败于美国？

编程语言是操作系统获得突破的重要抓手

尽管我们可以将自身发展不力的原因归咎于政府保护知识产权政策不完善等因素，但我们也不得不承认，在引领技术潮流方面，我们差的不是一星半点：我们的基础软件行业，和 Linux 桌面系统一样，一直将自己定位为追随者，始终没有走出模仿的怪圈。要走出这个怪圈，我们首先要想清楚操作系统这类基础软件的第一用户是谁，即我们首要服务于哪类用户。

我的观点是，类似操作系统这样的基础软件，其首要用户是开发者。一个基础软件，不论是操作系统还是数据库，只有首先满足了开发者的需求，服务甚至取悦开发者，才能建立起获得进一步成功的基础。重视开发者，优先为开发者服务，是基础软件的生存之道。其道理不言而喻：一款基础软件要获得大规模的应用，就离不开开发者，而基础软件的作者本身，纵有七十二变，也不可能把全世界的应用需求都给满足了。

只有将开发者定义为基础软件，尤其是操作系统的第一用户，我们的思路才可能有一个重要的转变。

如果我们简单回顾一下成功操作系统的发展，就可以得出这些操作系统一开始就不遗余力地为服务开发者而努力。比如微软，从 Windows 3.0 开始，就为降低 Windows 上的应用开发门槛在努力，这其中就包括 Visual C++、Visual Basic 以及后来的 Visual Studio、C#编程语言和.Net 应用框架。苹果和谷歌围绕各自操作系统所走的道路也类似。发展到今天，我们可以看到几乎所有成功的操作系统都有自己专属的一种编程语言以及围绕其打造的独特的应用框架。

作为反面案例，Linux 桌面系统上从未出现过任何专属的编程语言、应用框架以及开发工具。在当前市场趋势下，面对跨平台和融合终端应用的开发需求，Linux 桌面系统更是乏善可陈。GNOME、KDE 两大阵营，一个基于 C 语言，一个基于 C++ 语言，围绕这两个编程语言的应用框架，沿用的仍然是二十年前 Unix 工作站所使用的技术和框架。讽刺的是，Linux 桌面系统上使用最广的开发工具，是微软开发的 Visual Studio Code。

此前，我曾几度阐述过编程语言对一个操作系统的重要性。简而言之，编程语言之所以重要，是因为编程语言是确定一个系统长相的重要基因。就比如 C 语言，它适合开发贴近硬件的程序，而 C++，适合用于开发中间件。国外还有很多专注特定领域的编程语言，比如 Go 语言适合开发服务器软件，因为它天生为并发编程设计。编程语言可以确定一个系统的长相，也决定了这个系统的软件栈，及其配套的开发工具，还可以成为解决一些顽疾的灵丹妙药。因此，编程语言是自主基础软件，尤其是操作系统的重要抓手。如果没有我们自己的编程语言，那所谓的自主操作系统，就是海市蜃楼、空中楼阁。

因此，如果我们要发展自主的操作系统，就必须走出模仿的怪圈，而若想成为技术上的引领者，就要尝试为自己的操作系统设计一款全新的编程语言。没有自主的编程语言以及围绕其上的自主应用框架，对操作系统而言，就如同缺失了灵魂一样，便无法胜任技术引领者的角色。

目前，在中国信创领域，中国政府正在推广基于 Linux 的桌面系统以及嵌入式系统，在政府意志的推动之下，相关的技术积累和市场推广正在稳步推进，曾经困扰业界多年的关键应用，如办公套件、输入法等，通过中国本土的商业软件产品得到了有效解决。根据统计，单单中国政府的桌面系统，存量市场就超过了亿套，每年的新增安装量近五百万套，如果再加上一些关键行业和要害部门（如能源、交通等），足以支撑全球 10% 的桌面系统市场份额。这将给基于 Linux 的桌面系统和嵌入式系统带来前所未有的巨大市场机遇。然而，如果我们仅仅止步于跑马圈地，而无视发展自主编程语言的重要性，到头来也将竹篮打水一场空。

下一代操作系统需要什么样的编程语言？

随着云计算和物联网技术的普及，现在的应用跟二十年前大不一样了，最大的特点是需要联网、跨平台，而且可能要运行在不同类型的设备上，我们暂且称之为 “融合终端”应用。在满足融合终端类应用需求这一方面，主流的操作系统厂商在做全新的尝试，比如苹果为 macOS、iOS、padOS、watchOS 开发 Swift 编程语言，谷歌的 Flutter 使用 Dart 编程语言，微软也正在为 Universal App 做技术上的准备等等。

操作系统巨头技术生态布局（图源：《新程序员》）

显然，要在这场竞争中获胜，需要我们设计新的、云计算和物联网友好的编程语言和开发工具。一方面，可用来满足融合终端类应用的需求，另一方面还可用于提高应用的开发效率，同时，还可以成为操作系统生态的护城河。

那么什么样的编程语言是符合未来趋势的？对此，目前阶段很难准确描述。但我们可以尝试从宏观上描述适应上述全新需求的编程语言可能的主要技术特征：

• 描述式语言，易读且容易理解，甚至可支持开发者使用母语编程，从而让非职业程序员也能编写出满足需求的程序。

• 具有更高抽象层次的编程语言，开发者可以使用更少的代码实现更多的工作，且无需过多关心技术细节。

• 提供抽象的跨平台可移植接口。通过全新的接口设计来屏蔽底层操作系统或者平台的差异，这是跨平台的必然选择。

• 支持现代编程技术，如动态特性，对协程、并发、闭包等的支持。

• 良好的可扩展性和伸缩性，既可以用来开发脚本程序，也可以支持大型分布式应用的开发。

• 功能和性能的良好平衡，使之可用于嵌入式系统，甚至物联网设备端。

一旦我们为未来的融合终端应用设计了自己的编程语言，尤其是让编程模式都发生巨大变化的语言，那就可以自顶向下去设计一个新的操作系统。这个操作系统甚至可以涵盖云端、客户端、嵌入式系统和物联网。而内核、工具链、窗口系统、界面构件库、包管理系统，所有这些底层的技术将成为“汽车引擎盖”下面的东西，一般的应用开发者无需关心这些技术。如此，便有了服务开发者的基础。在此之上，我们利用或者围绕新的编程语言开发 IDE（集成开发环境）、自动化测试和部署框架、关键应用软件、应用商店、特定应用领域内的第三方运行时函数库等等，而这一切，合起来便是操作系统的生态。

自主开源编程语言设计与开发之路

为了践行上述所讲的理论，我提出并开发了全新的编程语言 HVML（Hybrid Virtual Markup Language，中文名为呼噜猫）。这是一款通用、易学的开源编程语言，从 2020 年 7 月提出并公开第一份规范草案，到 2021 年 7 月成立攻坚团队着手 HVML 解释器（PurC）的开发，2022 年 7 月 31 日，在 GitHub 上开放了 HVML 相关的六大源代码仓库（或源代码包），这标志着 HVML 1.0 正式发布，这其间已经走过了两年的时光。

而在过去整整一年的开发过程中，笔者带领团队实现了所有的设想以及绝大多数的功能。作为设计者，笔者将 HVML 定义为一种全新的编程语言：可编程标记语言（Programmable Markup Language）。并为 HVML 赋予了全新的设计理念，使之基本满足前文所说的全新编程语言的技术特征：

• 使用标记来定义程序的结构和控制流，大大提高了程序的可读性，同时大幅降低了学习难度。

• 使用具有动态功能的扩展 JSON 来定义数据，隐藏了底层系统，而且使其成为粘合不同系统组件的理想胶水。

• 引入了数据驱动的编程模型，这让开发人员更多地关注数据的生成和处理，而不是程序的控制流。

• HVML 是动态的，开发人员不仅可以从远程数据源获取数据、模板和程序片段，还能删除已有的变量。

• 使用独有的方式来支持协程、线程、闭包等现代编程语言必备的特性。

• 具有极强的灵活性，开发人员可使用 HVML 编写简单的脚本工具，也可以使用它来开发复杂的 GUI 应用程序，甚至是开发服务器软件。

• 运行飞快，HVML 解释器使用简单高效的栈式虚拟机，不使用任何垃圾收集器。

• 通过预定义变量重新定义了系统底层的模块和接口，从而屏蔽了不同操作系统或软件平台之间的差异。

• 相比常见的脚本语言，HVML 具有更高的抽象级别；使用 HVML，开发者可以用更少的代码完成更多的工作。

初衷和设计思想

之所以决定设计和开发 HVML，除了以上的思考之外，还跟我的经历有关。

在我所开发的 MiniGUI（开源 Linux 图形用户界面支持系统）生意受到 Android 冲击之后，我带领团队转战移动互联网以及智能硬件，开发过很多网站和智能手机应用。几年前，随着美国打压中国高科技产业愈演愈烈，国家又开始重视基础软件的自主可控，MiniGUI 的生意又回来了，我们也帮着一些客户开发了基于 MiniGUI 的解决方案。但由奢入俭难，习惯了网页前端开发技术的便利性，作为开发者，我们自己都难以接受使用 C/C++这样的编程语言来编写带有图形用户界面的应用程序——我发现使用 C/C++这类编程语言开发带 GUI 的应用，跟用牛刀杀鸡并无二致；就算有可视化的界面设计器帮助开发者，其开发效率也很难和 Web 前端技术相比。

有了这样的认知，我开始思考为正在开发中的 HybridOS（合璧操作系统）设计一款专门的编程语言。最初，我们的目标是让熟悉 C/C++或其他编程语言的开发人员可以通过 HVML 使用 Web 前端技术（如 HTML/SVG/ MathML 和 CSS）轻松开发 GUI 应用程序，而不是在 Web 浏览器或 Node.js 中使用 JavaScript 编程语言做绕转。最后，我们不光实现了这一目标，而且还将 HVML 实现为一种通用的编程语言。

为了将 Web 前端技术引入到通用的 GUI 应用的开发中， 开源社区也做了大量的探索性工作，比如 Electron 开源项目，就尝试用 Chromium+Node.js 来搞定一切。但这个项目存在一些问题，究其原因，跟 Web 前端技术本身的局限性有关：所有的一切都离不开浏览器，尤其是 JavaScript 编程语言。

后来，我们在开源的浏览器引擎 WebKit 中，尝试引入了一些具有动态能力的标签，可以用来实现循环迭代、分支控制等功能。有了这个基础，我提出了一个大胆设想：何不干脆设计一种全新的标记语言？于是，就有了 HVML。

简单来讲，HVML 尝试用一种新的思路来解决前面的那个问题：

第一，将 Web 前端技术（主要是 DOM、CSS 等）引入到其他编程语言中，而不是用 JavaScript 替代其他编程语言。

第二，采用类似 HTML 的描述式语言来操控 Web 页面中的元素、属性和样式，而非 JavaScript。

在设计 HVML 的过程中，我有意使用了数据驱动的概念，使得 HVML 可以非常方便地和其他编程语言以及各种网络连接协议，如数据总线、消息协议等结合在一起。这样，开发者熟悉哪种编程语言，就使用这种编程语言来开发应用的非 GUI 部分，而所有操控 GUI 的功能，交给 HVML 来完成，它们之间，通过模块间流转的数据来驱动，而 HVML 提供了对数据流转过程的抽象处理能力。

这样，围绕 HVML 形成的应用框架，和传统的 GUI 应用框架以及 Web 前端技术都有显著的不同。传统的 GUI 应用，代码设计模式无外乎直接调用 C/C++或其他编程语言提供的接口，在一个事件循环中完成创建界面元素、响应用户交互的工作。Web 前端技术和传统 GUI 应用的最大区别在于描述式的 HTML 和 CSS 语言，但程序的框架在本质上是一样的——事件循环，而且必须使用 JavaScript 语言。

但 HVML 提供了一个完全不一样的应用框架。在完整的基于 HVML 的应用框架中，包含一个独立运行的图形用户界面渲染引擎，开发者通过编写 HVML 程序来操控渲染引擎，而 HVML 程序在 HVML 解释器中运行，并可以和其他已有的编程语言的运行时环境结合在一起，接收由其他编程语言程序生成的数据，并按照 HVML 程序的指令，将其转换为图形用户界面的描述信息或者变更信息。通过这样的设计，我们将所有涉及到图形用户界面的应用程序分开成两个松散的模块：

第一，一个和 GUI 无关的数据处理模块，开发者可以使用任何其熟悉的编程语言和开发工具开发这个模块。比如，涉及到人工智能处理时，开发者选择 C++；在 C++代码中，除了装载 HVML 程序之外，开发者无需考虑任何和界面渲染及交互相关的东西，比如创建一个按钮或者点击一个菜单后完成某项操作等的这类工作，开发者只需要在 C++ 代码中准备好渲染界面所需要的数据即可。

第二，一个或者多个使用 HVML 语言编写的程序（HVML 程序），用来完成对用户界面的操控。HVML 程序根据数据处理模块提供的数据生成用户界面的描 述信息，并根据用户的交互或者从数据处理模块中获得的计算结果来更新用户界面，或者根据用户的交互驱动数据处理模块完成某些工作。

通过这样的设计，HVML 应用框架将操控界面元素的代码从原先调用 C、C++ 等接口的设计模式中解放了出来，转而使用 HVML 代码来处理。而 HVML 使用类似 HTML 的描述式语言来操控 GUI 元素，通过隐藏大量细节，降低了直接使用低级编程语言操控界面元素带来的程序复杂度。

在 HVML 应用框架中，有一个独立运行的图形用户界面渲染器。我们将这个渲染器设计为类似字符控制台的哑设备，这样，可以将 HVML 程序和应用的其他模块从控制界面元素展现行为的细节中解放出来。举个例子，我们在字符终端程序的开发中，可以使用一些转义控制指令来设置字符的颜色、是否闪烁等，而字符终端程序无需包含任何处理字符颜色以及闪烁的代码——因为这些细节字符控制台（可能是硬件，也可能是一个伪终端程序）帮我们默默处理了。HVML 的界面渲染器也遵循同样的设计思路，HVML 程序创建好一个按钮，至于这个按钮显示出来是什么样子的，用户如何跟它交互，这些统统无需 HVML 程序来操心——一切由渲染器在给定的描述式语言（如 HTML、CSS）的控制下运转。这带来另一个好处，由于在界面渲染器中不包含任何的应用运行逻辑代码和敏感的数据，从某种程度上讲，提高了安全性。

有了这样的应用框架设计，HVML 可以让几乎所有的编程语言，不论是 C/C++这类传统编程语言，还是 Python 这类脚本语言，都可以使用统一的模式来开发 GUI 应用。而在此之前，不同的编程语言有不同的 Toolkit 库，这些 Toolkit 库的能力不同，接口不同，渲染效果参差不齐。而 HVML 可以将这些交互类应用的统一起来，甚至也包括那些传统的字符界面应用程序。我们还可以将 HVML 程序运行在另外一台远程设备上（或云端），而渲染器运行在和用户交互的设备上，从而形成一个新的远程应用（或云应用）解决方案。

尽管 HVML 最初是为了解决 GUI 应用的开发而设计，但随着开发的深入，我们引入了一个全新的栈式虚拟机作为 HVML 程序的假象运行机器。有了栈式虚拟机这一坚实的理论基础，我们为 HVML 赋予了通用计算的能力。也就说，HVML 不仅仅可以作为交互式应用的胶水语言，还可以当做通用的脚本语言使用。同时，由于我们为 HVML 提供了协程、并发执行等的现代编程机制，因此，HVML 还可以用于高并发的服务器软件的开发。

任重道远，开源协作是正道

完成了最初的设计与开发后，HVML 已经进入到了开源协作的新阶段，开发团队和社区还有很多工作要做。首要目的，便是实现 HVML 规范 1.0 定义的所有特性和接口。这项工作将在 2022 年内完成。另外，作为 HVML 技术栈的一部分，针对嵌入式系统的渲染器也已提上日程，将在年底随合璧操作系统的新版本一并发布。

当然，一个编程语言走向成熟并获得广泛应用将是一个漫长的过程。这需要构建一个强有力的开源协作社区，而成功的社区运营，又需要资金、人才等各方面的支持。这在国内尚无成功先例，更是一个需要长期实践的课题。

目前 HVML 社区非常活跃，很多小伙伴帮助我们开发了各个 Linux 发行版的打包脚本，还有小伙伴制作了教学视频。作为社区领导者，我目前最希望的便是能够获得足够数量的赞助资金，用这些资金来激励 HVML 社区的小伙伴们，使得社区可以尽快进入到良性循环当中。另外，也希望有更多的基础软件企业加入到 HVML 的开发当中，助力 HVML 尽快走向成熟。

关于未来，如果 HVML 技术得到大量开发者的认同，我相信找到合适的商业模式，也只是时间的问题。另外，围绕 HVML 创立一个适当规模的基础软件企业，也不一定非要由我去做。假如有更加擅长企业经营的人围绕 HVML 开发了新的产品，找到了一套行之有效的商业模式，成功融资甚至上市，我本人也会非常高兴。我想，这是成熟生态的一部分。

未来无需假设，投身其中，让自己的设想变成现实，才有可能书写历史。