谁说国产编译器没救了？

编译器是人类世界和机器世界之间的桥梁。它可以将程序员理解的高级语言转换为机器代码，以实现程序的高效执行。C/C++编译器中，国外流行的编译器有VC、Borland C++、GCC、Watcom C/C++等，但国内自主开发的编译器相对较少。毕竟开发一个实用的编译器并不容易，这涉及到前端词法分析、语法分析、语义分析以及大量的编译优化。有一个团队花了十几年时间完全独立开发YC编译器和YC浏览器内核。为什么他们不遗余力地开发自己的编译器和浏览器内核？下面，YC编译器的主要作者之一杨小兵将讲述其背后十多年漫长的研发之路。因此，我再次决定修改YC编译器以完全支持C++11标准，因为Firefox C++代码几乎使用了所有C++11语法特性。

自述文件 | 杨小兵

编辑| 吴杏玲

出品| CSDN（ID：CSDNnews）

编者注：

编译器是人类世界和机器世界之间的桥梁。 它可以将程序员理解的高级语言转换为机器代码，以实现程序的高效执行。 C/C++编译器中，国外流行的编译器有VC、Borland C++、GCC、Watcom C/C++等，但国内自主开发的编译器相对较少。

毕竟开发一个实用的编译器并不容易，这涉及到前端词法分析、语法分析、语义分析以及大量的编译优化。 有一个团队花了十几年时间完全独立开发YC编译器和YC浏览器内核。

为什么他们不遗余力地开发自己的编译器和浏览器内核？ 这个编译器有什么优点呢？ 下面，YC编译器的主要作者之一杨小兵将讲述其背后十多年漫长的研发之路。

以下为杨小兵的自述：

初衷：“做一些有助于软件行业进步的事情”

十多年前，我在中科院电子所工作，参与了一些硬件电路的设计。 那时我对硬件的兴趣远大于软件，后来自己创业，专门从事软件工作。

在自己创业的过程中，我发现做这种软件虽然可以赚钱，但是无论做得多么好，对于软件科学的进步并没有任何影响。 虽然我付出了很多努力，但我却没有任何成就感。

操作系统、数据库、编译器和浏览器内核是最基本的软件产品，不需要特殊的专业知识，开发起来非常困难。

我想选择其中一款软件进行自主研发。 虽然我不确定自己会取得什么成就，但我希望自己能做出一些有助于软件行业进步的事情，这样我才无愧于进入软件行业。 行业。 根据当时的情况，我发现可以从浏览器核心入手，所以除了维护原有产品之外，我把主要精力投入到了浏览器的研发上。

创新地将C代码嵌入HTML

两年后，我们开发并完成了浏览器内核的基本功能，例如HTML解析和显示、JavaScript脚本执行等。

这时候我们发现HTML标准越来越复杂，开发越来越困难。 如果按照这个发展，浏览器核心将无法进入市场。

于是我重新思考：如果将C语言处理嵌入到JavaScript脚本中变成HTML，并用嵌入C代码的HTML超文本作为软件的人机交互界面，这个内核应该具有一定的竞争优势。

于是我们花了两年半的时间，用类似于JavaScript的方式在HTML中实现了标准的C语言，并扩展了一个HTML标签：每个用户标签可以使用属性src来指定一个C源代码文件，以及其显示界面用户标签和所有行为都是由它的C代码决定的。

同时将C编译器做成函数，用函数来编译生成C程序的可执行代码。 可执行代码可以存储在文件中或直接执行。 此时，我们将编译器命名为YC编译器，将浏览器内核命名为YC浏览器。

三年又一年，研发之路漫漫

随后，我们不断完善浏览器内核，分离出部分内核代码并通过内嵌编译器动态编译执行，并将大部分内核源代码开源。

同时我们还遇到了另一个问题：YC编译器虽然编译速度很快，但生成的字节码执行速度很慢，而且与原生代码的相互调用（尤其是回调函数）的处理相当繁琐。 因此，当时使用YC编译器来编译开源代码是很困难的。

为了解决自编译浏览器内核代码的问题，我们决定修改YC编译器，将其字节码转换为本机执行代码，并扩展语法以具有少量的C++语法。 这项工作持续了三年。

三年后，YC编译器的功能增加了，它提供了像调用动态链接库一样直接调用C源代码中函数的功能。 此时浏览器内核的开源部分就可以使用YC编译器实时编译执行。

我们不断改进浏览器内核，将运行缓慢的 JavaScript 字节码改为二进制原生代码，使 JavaScript 的执行速度提高了约 100 倍。 同时，所有浏览器内核代码都是模块化、开源的。 每个模块都是使用YC编译器动态编译和执行的。 编译器的部分源代码也是开源的（如内联汇编编译源代码、反汇编源代码、C/C++字节码执行源代码等），所有开源代码均由嵌入式YC自动检测并编译编译器并动态执行。 这项工作大约花了四年时间。

在开发过程中，我记得 Google 和 Firefox 浏览器都是开源的。 为什么不看看他们的源代码呢？ 于是我找到了这两个浏览器的源码。

当时由于某些原因，我对Google Chrome源码的分析未能通过编译，但是Firefox的源码却编译成功，于是我就走上了分析Firefox源码的道路。

下载的Firefox源代码由纯C代码和C++代码组成。 它由Visual C++ 2013编译生成xul.dll文件和firefox.exe文件。

我首先分析了它的C代码，将所有输出函数改为类接口，让xul.dll通过YC编译器函数YC_cppLoad实时编译，然后使用类接口调用C源代码中的函数。 这一步很顺利。 如果修改了Firefox的C代码，只需重新运行Firefox即可生效。 不需要其他操作。

以前的办公桌

接下来，开始分析 Firefox C++ 代码。 YC编译器仅实现了少数C++语法，无法编译Firefox C++代码，因此分析起来非常困难。

为什么Firefox的C代码容易分析，而C++代码却很难分析？ 原来我使用YC编译器从它的C代码中生成了汇编代码文件、变量结构定义文件、宏定义文件和预编译文件。 通过这些文件，分析的难度就大大降低了。

因此，我再次决定修改YC编译器以完全支持C++11标准，因为Firefox C++代码几乎使用了所有C++11语法特性。 首先，我使用STL标准模板库代码对编译器进行修改和调试。 没想到，这个过程足足花了三年时间！ 之后，我开始使用 YC++ 编译器调试 Firefox C++ 代码。 我以为像STL这样复杂的代码都能正确编译执行，而Firefox C++代码应该能很快编译通过。 没想到，很多语法细节并没有在STL中使用，而是在Firefox C++源代码中使用。 于是我继续修改YC编译器，编译Firefox C++的各个模块。 这个过程持续了一年多。

虽然YC编译器可以编译所有Firefox C++代码，但是如何生成执行代码呢？ 我们先从主程序Firefox.cpp开始。 经过整理，这个程序可以使用YC编译器生成执行代码Firefox.exe并顺利运行。

由于 Firefox C++ 模块是紧密耦合的，因此很难将它们拆分。 经过一个多月的工作，我仍然无法将它们拆分成多个独立的源代码模块，用YC编译器进行实时编译和动态执行。 这可能是我对问题的理解。 Firefox C++源代码的整体结构尚不清楚，所以我们只见树木不见森林。

杨小兵

当我准备再次对Firefox C++代码进行整体分析时，我有机会参与了一个学校管理系统的开发。 由于原有的管理系统经常出现故障，操作极为不便。 虽然我没有开发Web服务程序的经验，但我制作的软件与Web服务器密切相关。

经过了解，开发这种管理系统需要的软件包括：Apache或Nginx服务器、数据库MySQL或其他、编程工具ASP或JSP或PHP等，于是我们受到启发，决定自己开发这些工具。 YC 的 C/C++ 和 JavaScript 编译器以及 HTML 解析器派上用场。

经过一段时间，一个稳定的、任意扩展的、多线程、高并发的HTTP服务器就完成了。 服务器处理YSP文件生成网页并将其传递给浏览器。

YSP是我设计的一种Web编程语言，具有与ASP、JSP、PHP类似的功能。 YC服务器执行YSP文件中嵌入的C/C++或JavaScript代码，生成HTML超文本并将其传输到终端设备。 工具完成后，很快就做出了管理系统的原型，这可以在发布的YC编译器中看到。

做完上面的工作，我想是时候写一本书来介绍YC编译器了。 经过一段时间，《YC编译器-多语言编程》（暂定名）即将出版。

当我读完这本书后，我立即投入到 64 位 C/C++ 和 JavaScript 编译器的开发中。 目前开发进展顺利，已进入测试阶段。

编者后记：

三年的时间，一个初生的婴儿可以变成一个蹦蹦跳跳的幼儿，一个懵懂的职场新人可以变成一个沉稳的老手。 杨小兵团队静下心来迎难而上，花了三年、三年、又一年、两年、四年，只为突破一个个技术难关，最终研发出了YC编译器和YC浏览器内核。

在这个过程中，杨小兵坦言，最大的挑战不仅是技术，还有思维水平。 在此期间，他不仅花费了大量的研发工作，还多次重写代码进行优化。 让他继续前进的是他想要为计算机软件科学的发展做出贡献的聪明才智。

杨小兵团队目前正在开发64位C/C++编译器。 谈到未来，杨晓兵表示，会先在国内推广，然后再走向海外。 祝福杨小兵。

YC编译器传送门：

网络摄像机是一种基于互联网协议的摄像机，可以通过局域网（LAN）传输视频数据，并且变得越来越流行，特别是在监控和安全场景中。 Windows 现在允许用户将网络摄像头关联到他们的电脑，从而在相机应用程序中启用照片捕获和视频流。 目前，Windows 仅支持符合 ONVIF Profile S 的摄像机*，这些摄像机是针对实时流视频捕获而优化的符合标准的网络摄像机。

注意：本文中讨论的功能在 Windows 10 Insider Build 18995 中可用。

Windows 通过 WinRT API 提供对发现、配对、配置和流式传输的支持。

要发现连接到本地子网的网络摄像机，请创建一个 DeviceWatcher 类并按照本文档中指定的说明连接到远程摄像机。

要配对已发现的网络摄像机，请使用 DeviceWatcher 返回的 DeviceInformation 实例。 Windows 支持以下配对方式：基本和自定义，如配对设备文档中所述。 简而言之，基本配对提供了一种与不需要身份验证即可访问流的摄像机配对的简单方法。 当需要对配对进行更高级的控制或相机需要身份验证时，应使用自定义配对模式。

或者，对于无需身份验证即可访问的网络摄像头，用户可以通过 Windows 10 设置页面使用添加设备向导将其配对。

步骤 1：打开 Windows 设置并选择设备

Windows 设置页面

步骤2：在蓝牙和其他设备→其他中，点击添加设备，发现连接到局域网的网络摄像机。

蓝牙和其他设备窗口

步骤 3：单击您想要配对的网络摄像机，设备现在应该已连接。

配对窗口

配对网络摄像头后，您可以使用您喜欢的相机应用程序或内置的 Windows 相机应用程序捕获照片、流式传输和录制视频。

如果使用“设置”页面与经过身份验证的相机配对的能力对于您的使用案例很重要，请通过 Windows 开发人员反馈告知我们。

附加功能

Windows 中对网络摄像头的支持正在不断改进，现在在 Windows Insider 计划中注册的开发人员可以使用其他功能。 在最新版本中，开发人员将发现对更多 ONVIF 相机的更好支持，因为 Windows 现已获得 ONVIF 的全面认证。 此外，Insider 版本中提供了一些新的 API，支持从指定 RTSP 统一资源标识符 (URI) 进行流式传输，并且可以与相机执行时间同步。 下面分别介绍这两个API。

要通过 MediaCapture 类从 URI 进行流式传输，请将所需的 URI 分配给 MediaCaptureInitializationSettings::DeviceUri。 如果需要凭据，可以通过 MediaCaptureInitializationSettings::DeviceUriPasswordCredential 设置。 该 API 支持 ONVIF 和通用 RTSP 服务器 URI。 这允许应用程序使用标准 Windows Media API 从通用 ONVIF 兼容摄像机或从任意 URI 捕获视频（无需配对）。

新的 API 还支持使用 Onvif 规范指定的网络时间协议 (NTP) 进行摄像机时间同步。 使用 KSPROPERTY_NETWORKCAMERACONTROL_NTP 为要使用的 ONVIF 摄像机配置 NTP 服务器。 通过此机制进行配置后，摄像机将开始流式传输并通过发送者报告（如 RTP/RTCP 规范中所述）在单独的通道中发送 NTP 时间，以帮助 Windows 调整从摄像机有效负载时间戳接收的 RTP。 这可用于确保多个摄像机之间捕获的视频剪辑的同步。

*不严格遵守 WS-Discovery 协议的 ONVIF Profile S 兼容摄像机可能会在发现和枚举过程中遇到问题。