2014.06 昔时因 今日意 侃侃微软的CRT

Views

[作者按] 此文的原名本来是 “Visual C/C++ Runtime (CRT)的历史演化,及其即将发布的大型重构",但写下这个冗长枯燥的标题后,我感到很不好意思——题目都这么乏味,内容就可想而知了。果断删了重拟一个,也趁机往人文的路口挪上两步。


多年来,Visual Studio 几经沉浮,一直是为数不多的有竞争力的开发工具之一。而其提供的 C 语言运行时环境(C Runtime,简称 CRT),是其中一块至关重要却又默默无闻的基石。某种意义上讲,庞大的 Windows 帝国和上面运行着的大部分应用和游戏,正是构建在这薄薄的一片运行时之上。而所谓“昔时因,今日意”,正是意在正本清源,循着脉络将 CRT 的来龙去脉梳理一下,也就能回答“从何处来,向何处去”这个问题。全文分为两部分,“昔时因”回顾 CRT 与 Windows 相生相伴的历史,“今日意”则着眼于当下正在进行的重大重构,于未来趋势亦可管窥一二。


“昔时因,今日意,胡汉恩仇,须倾英雄泪。虽万千人吾往矣,悄立雁门,绝壁无余字。” 
    —— 《苏幕遮》,《天龙八部》回目名

昔时因

在很久很久以 前,曾经有一个 dll 叫做 MSVCRT.DLL,故事就是从它开始的。

在 Windows 95 的洪荒年代,这个 dll 就是 Visual C/C++ (确切地说是VC++ 4.2)的运行时库。在那时,每当 Visual C++ 团队有新的版本要发布时,Windows 团队就同步更新操作系统的 msvcrt.dll 来跟 Visual C++ 团队保持一致。这样,开发人员使用新版VC写出来的程序,才可以在更新后的系统上正常工作。而假如 Windows 团队想修一个 crt 的 bug,他们不能手一挥直接改掉,而是必须得通知 Visual C++ 团队也对同一份代码做对应的改动。俺估计呢这也实属寻常,主要有两个原因:a) 因为他们总是新 dll 的头一批用户,为了配合对应的 Windows 新特性的市场宣传,只能给 Visual C++ 当小白鼠,做做义务 QA 了。 b) 微软收到的用户反馈,比如“某游戏在某次系统更新之后无法运行了”这种事,往往不能第一时间确认是不是 crt 的兼容性问题,这些黑锅都只能 Windows 团队先背着了。

大家可能觉得 Visual C++ 团队很惬意,只管自顾自往前做就行了,反正出了事有 Windows 团队兜着(我估计事实上还真是)。在 *"Windows is not a Microsoft Visual C/C++ Run-Time delivery channel"*一文中, Raymond Chen 就举了个例子,有一次 Visual C++ 这边修了个 Y2K(千年虫)问题,结果系统一更新之后客户的程序就都崩溃了。一查之后发现,这个 crt 的修复影响了栈的行为,把客户代码里一个没初始化的变量给暴露出来了。

其实现在回过头去看看 Win95/98 的兼容性就知道,像这样的事情数不胜数。微软的每次发布都忙着四处救火,也就罢了,软件开发者们提心吊胆,生怕自己写的程序在某次系统更新后就不能用了。但凡 Visual C++ 出了新 Patch(往往还是重大安全更新),负责 Windows 系统更新的团队就得以最快的速度把这份最新的 msvcrt.dll 部署(其实就是直接把老的 msvcrt.dll 直接覆盖掉)到数以百万计的客户机器上,而客户环境配置千差万别,各种程序还能不能正常运行,只能看老天爷的眼色了。而某个中二程序直接拿它自己开发测试环境里的一个 msvcrt.dll(实际上是个相对较老的) 在安装过程中把系统的 msvcrt.dll 给偷梁换柱的事情更是屡见不鲜,导致的各种蓝屏死机随机故障也就随处可见了。


说了这么多大家可能已经明白了,考虑到这两个团队的规模,这种高度的同步是很难搞的;而且在那个动态链接都还是新鲜玩意的年代,像 COM 这样相对规范的模型被应用的范围就更小了。总的来看,微软还未演化出有效的机制和流程,去缓和 DLL Hell,系统地维护兼容性。强制高度协同(人的因素)和缺乏控制手段(技术因素)两个因素交织起来,足以搞垮任何为了维护兼容性所作出的努力。这种维护难度体现在什么地方呢?举个栗子吧,某 C++ 语言功能要求改进一下 ostream 这个类,为了不破坏二进制兼容性,维护人员不能改变对象尺寸,不能改变任何成员的偏移,他们的改动都要经过精心的设计,谨慎地绕过各种沟沟坎坎,避免打乱已有的虚函数的调用时机,还要注意避免效率上的损失。

有过程序经验的同学应该了解,即使是一段不起眼的“Hello World”程序,从语义到运行环境,内部暗含的上下文约束的信息量也是非常大的。维护代码时,要想不干扰明面上的逻辑很容易做到,但要想保证各种暗含的假定完好如初可就难了,有时甚至根本就不可能有效地证明自己是否已经做到(俺认为,这一点才是致命的)。如果你觉得对于一个像 CRT 这样规模的程序库来讲,这简直是痴人说梦的话,那你说对了,微软确实最终没做到这一点—— Win95 和 Win98 最终就有两个相互不兼容的 msvcrt.dll。


经过了无数个系统更新导致的鸡飞狗跳和西雅图夜未眠之后,微软的经理们终于想通了——按Windows怪兽般的膨胀速度,系统里鸡零狗碎的组件数量的增长情况,再这么搞下去, Win98 之后……就木有然后了。经过某次决定性的会议后,经理们手挽着手,一脸沉痛地向全世界的开发者们郑重宣布:兄弟们,msvcrt.dll 这个 dll 已经被我们玩废了,以后仅供我们 Windows 内部使用(OS DLL),大家就不要再 cue 它了,Let it go 吧。

自那以后,每个新版本的 Visual C++ 都带有一个拥有独立版本号的 crt dll ——这就是 msvcr71.dll, msvcr80.dll, msvcr90.dll 等文件的由来。他们彼此独立更新,微软也终于撇下了历史包袱。


世事难料,尽管距离 msvcrt.dll 被声明为非公开的系统 dll 已经过去很多年了,可仍然有很多不明真相的同学孜孜不倦前仆后继地 cue 这个库;并且由于 crt 的代码是公开的(为了满足那些喜欢 hacking,依赖 undocumented behavior 的同学的需要),大量历史遗留代码(和源源不断新写出来的代码)依赖了 crt 的实现细节。这些年来,微软的技术团队为这群人操碎了心(像不像 IE6 和 WinXP?),例子我就不详述了,大家如果感兴趣的话,可以去 MSDN 的 Knowledge Base 里翻翻,那里是微软工程师们的200,000部伤心的历史记录汇总。唉,满纸荒唐言,一把辛酸泪,都云作者痴,谁解其中味。程序猿们,你们懂的。


总之对于多年来微软在保持向后兼容性这个方面做出的努力来看,俺是真心佩服的。以俺的见识,也的确很难找到另一家能如此做到尽量为自己的黑历史负责任的公司。正如一句评论所说

“I continue to be amazed at the level of effort Microsoft go to in order to accommodate other people's stupid design and implementation choices.”

大家可能时常会觉得,微软背负了太多历史包袱,像是一头行动迟缓的年迈骆驼。可是对于历史遗留问题和历史决策失误,微软的确没怎么逃避过买单。虽然姿势可能一贯不怎么优雅,品味和情怀也是一贯被嘲讽的水准,不过这种负责任的精神,俺认为仍然是相当值得肯定和称道的。


今日意

说完了过去的种种,那么现今的情况如何呢?


自那以后,Visual Studio 在十多年间发布了若干个版本,微软的后缀版本号策略也一路用到了最新版本的 Visual Studio 2013(也就是对应的 msvcr120.dll 和 msvcp120.dll)。这个模型虽然把单个库文件成功地扩编成了一个加强连,但也的确解决了不少问题,至少 Visual C++ 可以放心大胆地加新功能了,不用担心破坏已有软件的行为。

可是(重点来了),在这个模型上,微软收到的负面反馈越来越多。越来越多的大型软件项目发现,系统内诸多组件对不同版本的老旧 crt 的依赖,让他们很难迁移到新版本的 crt 上;有时,还需要付出不菲的精力去支持一些古老的使用某个特定版本的 crt 的 dll 插件(有的甚至连代码都没有)。

作为软件开发者,俺也发现,在一个大型系统里,很难快速明确地查知,不同的二进制文件分别依赖了哪个版本的 crt 。考虑到一些 server 组件会在远端的机器上神不知鬼不觉地更新,没事儿就用 Dependency Walker (depends.exe) 去彻查一遍也不现实,此其一。当发现大量的不一致后,要把它们改成一致,更是难以充分预估的工作量。

口说无凭,俺就举个俺被坑过的例子吧。较新的 CRT 中,对 time_t 的定义默认情况下是 __time64_t,而这个值以前曾经有很长一段时间内是 __time32_t。也就是说,如果你用到的第三方库使用了较老的 32 位 time_t 而你用了较新的 64 位版本,那么不会有编译和链接错误,只会在运行时冒出一些难查的 bug,诸如(微小几率) sprintf() crash,(微小几率)附近的内存被写坏,等等等等。这类问题的麻烦之处在于,即使你已经费了很大劲把出错的区域定位到一段不长的局部代码,也很难联想到是 CRT 的兼容性在捣乱。

与此同时,由于受到了强大的外部压力,微软加快了 Visual Studio 的发布周期,再加上一些特定用途的定制版 crt,比如主机版,移动版,等等,需要维护的版本线以排列组合的方式加速增长。微软自己也发现,维护和支持所有老版本的 crt,把一些重要的补丁向后移植回大部分已经冷却的老版本,带来的开发和测试成本已经大的吓人。

终于又到了不得不变的时候了。


在 Visual C++ Team Blog 的 "The Great C Runtime (CRT) Refactoring 一文中,我“惊喜”地发现,下一代的 Visual Studio “14” (实际产品名称可能会是 Visual Studio 2015) 中的 crt 又回到了早先单个 “msvcrt.dll” 的模式。VC团队决定不再添加新的版本号后缀,从那以后将一直使用同一个 dll 并自始至终保持它的兼容性。

历史在这里兜了个圈,又回到了原点。


我想此刻大家最好奇的问题可能是:那个方案不是早就被淘汰了吗,为什么这回又重走老路呢?

这篇 blog 里没有正面回答这个问题。俺来试着答一下吧:

  • 第一,这些年来 crt 的特性集变动不大,整体趋于稳定,在可预见的将来,不太会出现架构性的变化,给了微软的工程师足够的信心保持整个协议层(俺把所有公开给程序员的接口统称“协议层”)的兼容度。
  • 第二,从工程师们的行文笔调看,微软这些年来在无数的口水声中积累了一套相对完整的测试套件,覆盖各种边边角角的情况(这甚至包括巨量的对以往的各种未修复的 bug 的行为的兼容性),这个套件的价值难以估量,可以帮助微软把绝大多数破坏兼容性的情况消弭于日常开发之中。
  • 第三,也是最重要的一点,就是时代变了。现在已经不再是那个通过在内存里共享代码段来节省内存的年代了。任何一个应用程序,只要它愿意,可以部署若干个 crt 的副本而不用考虑任何边际的开销。说白了,即使程序需要某个特定版本的 crt,它自己部署一个就好了。微软已经发展出各种成熟的通道把每个应用程序用到的运行时环境跟其他程序隔离开来,甚至同一个应用程序,也可以在启动时指定运行在不同的运行环境下(所谓的 WinXP / Win98 兼容模式)那么,通过版本号来区分就显得画蛇添足了。

需要说明的是,这不是官方的说明,只是俺的个人理解,欢迎讨论。


好了,解释清楚了这些情由,我们还是一起来看看新的 crt 有什么特色吧。

新的 CRT 将被切成三块:VCRuntime,AppCRT 和 DesktopCRT。如下图所示:

crt-01

功能也很明确:VCRuntime 是基础模块,是核心中的核心,运行时的运行时(the runtime of the runtime);AppCRT 是兼容移动设备的模块;DesktopCRT 是传统的桌面环境的模块。

从介绍中我们看到后两者大体上是包含关系,但我倾向于认为它们将会发展成为下面的结构:

crt-02

也就是说,俺推测,随着时间的推移,AppCRT 和 DesktopCRT 之间的公共部分会被下推到 VCRuntime 中,而 AppCRT 可能会发展出一些移动平台独有的特性,与DesktopCRT的功能集将不再重叠。当然了,无责任随便说说,大家看看就行。


说完了架构,再来说说实现吧。在新版本的 CRT 里,微软的工程师做了大量的重构来简化代码。

按惯例,那些吐槽以往的实现有多难维护的巴拉巴拉巴拉咱们还是跳过吧——慢着,这个关于 printf 的吐槽还是蛮有趣的,跳过了怪可惜的。据说大家都很熟悉的 printf 系列函数有 142 般变化,基本都实现在 output.c 里。别看这个文件不长(2696行)——里面有223个 #ifdef 条件编译开关(其中一大半都在一个1400 行长的函数里),更骇人听闻的是,这个文件以不同的编译开关反复编译达12次来生成所有的142般变化。

12次!

大家可以在自己机器上,找到 C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\crt\src\output.c 去瞅瞅看。顺便说一下,那个1400行的函数是 _output 函数族,这个函数光是 Signature (就是函数体前的声明)就长达59行,预编译宏多达36个,相当壮观,绝对值得你前去拜一下。


大家可能想不到的是,在新的 CRT 里,

  • 呃,绝大部分代码现在都改用 C++ 实现了(然后在头文件里 extern “C” 出去)。
  • 呃,绝大部分手工资源管理现在都改为某种形式的智能指针了。
  • 呃,大部分的 #ifdef 都改成模板和重载了。

微软大概可以机智而自豪地宣称,俺家的 C 语言运行时,是用 C++ 写的,独此一份哦。

唉,冤冤相报何时了啊。


明天的明天 - 写在最后的话

好了,关于CRT的故事,到这里也快要结束了。不过临走之前,请先留步,且容俺把话题稍微扯远一点吧。

曾经有段时间(新世纪的头几年),微软向开发者全力兜售托管平台(.net),希望籍此一举摆脱掉各种历史包袱,在一个崭新的,统一的,规范的,和谐的,幸福的,最重要的是,由微软主导的平台上,重建整个生态环境。奈何若干年过去了,买账的人十分有限不说,相当的 Windows 平台开发者反而被吸引到了竞争对手的移动平台。可见光是把房子盖好还不够,周边配套也要跟上。当然了,事后诸葛谁都会当,不过在我看来,.net 吃亏就吃亏在没有与之相配的,清晰明确的商业模式。当年微软宣传了无数次的“.net 大法好”,开发者们还是云里雾里,没看出来这玩意究竟好在哪儿,也没看出来微软究竟葫芦里卖的是什么药。苹果那边一声吆喝“AppStore + 三七分成”,开发者纷纷响应,用脚投票,直接光速构造了应用生态圈。商业模式之威力竟至于斯!

看到这里大家可能会想,这跟你这儿说了半天的 CRT 有什么关系,这不跑题了吗?别急,就要来了。这些年来,微软先是被软硬兼施的苹果弄得没脾气干瞪眼,又被 Google 领头的一帮九零后杀马特(你还真别急,那年头,微软眼里,这群互联网新贵还真就是这个层次)三拳两脚给打蒙。最近两年,微软逐渐回过味来,开始收复失地。新的 CEO 上任以来,也的确有了新的气象。对于广大开发者对 Visual Studio 在 Native 方面急需强化的呼声,微软终于敞开怀抱,开展了轰轰烈烈的 GoingNative 运动(2012和2013两年的 GoingNative Conference 全部是可移植C++的内容),Build大会上Native相关的内容迅速增加,对新标准C++11/14的支持也以前所未见的速度展开(C++11/14 Feature Tables For Visual Studio 14 CTP1),包括最近的 Parallel STL,以及将于2014年9月份举办的首届 cppcon (GoingNative的组织者和Visual C++团队一起操办),等等等等。

这几年 Visual C++ 也新增了各种新玩意,包括工具链诸如 MSBuild 的改进,光是 nuget 带来的方便就值得击节了,那也不必多提,俺有机会抽时间写个经验贴吧。不过这里俺还是要忍不住啰嗦一句,凡是在nuget上配置好的第三方库,在你按下F5开始调试的时候,nuget 会自动帮你下载对应VS版本的库,缓存到 Solution,配好所有 Include/Lib 等依赖关系,并将对应的 DLL 放入你的分发目录。咱 C++ 土著这些年来谁享受过这包管理呀。


在 Apple 和 Google 的步步进逼下,在移动互联的阵阵浪潮之中,微软这艘驶过了无数风雨的巨轮,仍在不断调整自己的航向,缓缓前行。作为前互联网时代整个软件行业最大的开拓者,微软承受了许多其他的组织从未有机会面对过的考验,挫败,彷徨和挣扎,也催生出很多外人难以想像的成熟(或曰老迈?)机制和文化。是的,人们总是习惯于追捧,著迷于精美,新奇,有趣的流行科技,而蔑视,唾弃一个多年陪伴的老面孔。这是社会风尚的天性使然,却并不是专业人员用来评价好坏的标准。社会风尚自然会随着流行风向而变化,而真正的价值却来源于时间的考验和岁月的沉淀。

谨以此文向微软表达一个普通开发者发自内心的敬意。

好吧,气氛好像严肃了点。那么,最后这句话,我来替微软问了吧——明天的明天,你还会用俺家的 CRT 吗?


修订历史

  • 2022-07-04 修正文中部分链接格式,顺便对字句做了些微的调整
  • 2014-06-28 本文初次发布

date: 2014-07-02 03:48:07 author: wingc email: wingc@wingc.net site: http://spaces.wingc.net ip: 131.107.147.48

全文都是干货,虽然行文调侃,但从回顾历史到剖析现状到展望未来,都是有大量的实料可读。如果读者不知CRT为何物,我劝还是关闭浏览器吧,此文不适合你。如果读者依然看得云里雾里,我劝只抓一个重点就行: “大家可能想不到的是,在新的 CRT 里,

呃,绝大部分代码现在都改用 C++ 实现了(然后在头文件里 extern "C" 出去)。
呃,绝大部分手工资源管理现在都改为某种形式的智能指针了。
呃,大部分的 #ifdef 都改成模板和重载了。

微软大概可以机智而自豪地宣称,俺们家的C语言运行时是用C++写的,独此一份哦。”

这一步步子真的有点大,肯定蛋被扯得很疼。至少处理C++异常就够头大了,C++异常不能抛到extern C那一层,全都要转换成errno反馈到C的调用者。等到这重写的CRT被静态链接到kernel代码里,那就是更进一步,kernel都是C++的咯!


date: 2014-07-02 05:35:24 author: gemfeeling email: gemfeeling@hotmail.com site: ip: 116.19.107.97

说一下俺的认识(和推测)吧 :)

  1. 由于微软断然不会更改整个库的接口的错误汇报方式,正如您所说,CRT不会使用异常作为向外汇报错误的手段,这一点是确然无疑的(否则就不能叫CRT了)。
  2. 然而,假使不把异常看作是语言提供的汇报和处理错误的一种机制,而看作是一个单纯地用于在必要时安全地 stack unwinding 的工具,那么在改善程序可读性上(替换掉已有的 goto/longjmp 之类),异常机制是有一定实用价值的。可参阅此文Error and Exception Handling 的 “When should I use exceptions?” 一节。
  3. 然而,假如决定在内部使用异常来处理错误,并总是在对外时转为 errno ,这是合情合理的实践,也是看起来有些啰嗦,但实际上益处多多的实践。 对于一个设计良好的程序库而言,内部运行产生的错误,在通过库的边界汇报给外部用户时,应该总是被统一转换为某种统一的外部错误。因为被汇报的错误也是一个库对外接口协议的一部分。不经转换直接报出的内部错误,会有在接口层暴露实现细节的风险。当然了,更简单的做法是内部和外部统一使用同一套公开的错误信息,但这样的话,公开的东西修改阻力很大,内部逻辑就少了很多自由度,有时会很被动。更多的策略性讨论可参阅 C++ Coding Standards 的第69条。
  4. 如果用的话,应该不太会直接用C++异常(std::exception)而是用结构化异常 (SEH),道理跟“不直接使用 C++ 标准库里的智能指针而是自己实现了一个简略版”类似(避免未来潜在的循环依赖)。

其实如果从思路上讲,Kernel 的很多组件在二十年前就是基于对象思路去设计和实现的了,咱们大可不必纠结其用哪种语言实现(因为差别不大)。


date: 2014-07-02 08:27:28 author: wingc email: wingc@wingc.net site: http://spaces.wingc.net ip: 131.107.159.48

找了好久直接回复评论的按钮,居然找不到…

第1/2/3条有保留同意。仔细考虑了你说的认识和推测,我倒觉得实现起来都不要C++异常更好。如果处处都智能指针了,真不一定需要C++ 异常来做stack unwinding。再考虑CRT有errno,而Windows API又有system error code和HRESULT error code平行两套,code到code做个mapping总比exception对象到code来的简单。而且,考虑到CRT要有静态库放出,若代码实现用到异常处理,但用户产品链接时却不小心link到了非异常实现的其他lib岂不是大乱(好吧,最可能出现的是用new时假设bad_alloc异常,却不小心链接到了nothrownew的实现只返回空指针)。再加有C++异常的代码编译出来后真的多了些累赘。若选实现方案,我情愿连新CRT的C++实现都不要用C++异常。我们都不是其实现者,不知道具体会怎么做,到时候放出来时再看如何?

第四条,呵呵呵,完全不同意SEH啊。那玩意是pain in the ass,从语法上来讲破坏了C和C++,从实现上来讲紧密依赖平台。我理解的“不直接使用 C++ 标准库里的智能指针而是自己实现了一个简略版”应该是把C++异常拿掉的标准库,而不是把C++异常换成SEH。同样,这是基于我的个人感受和理解。

Kernel内部组件实现是早就基于面向对象设计,但实现就未必了。没有编译器支持C++对象模型和模板元编程,靠纯C的若干奇技淫巧也是能搭出基于接口的实现。但是若直接走上了C++,再整上RAII,用模板和trait去掉了宏,那叫个高大上啊!我还是很纠结的。不过话说回来,若不小心跟踪调试进去,看不到源码,还是一样的痛苦。


date: 2014-07-02 14:47:04 author: gemfeeling email: gemfeeling@hotmail.com site: ip: 113.106.106.98

是啊,这种尴尬事(假设bad_alloc异常却 nothrownew)向来就是微软的强项 :)

我也不喜欢 SEH,只是考虑到既然已经大范围用了 (应该是在微软 crt 能跑的平台上都有实现) 就没那么强的动力去再做一套。 而且在这里 也可以看到,SEH 本身就是微软为C语言做的语言扩展异常机制,现有的 crt 中也被大量运用,所以我倾向于认为微软会继续用这个,不过世事无常,谁知道呢。

呵呵,内核调试俺不熟,不敢妄言,就不多嘴了 :)


(全文完)


comments powered by Disqus
Built with Hugo