d3d与OpenGL的博弈 来自：http://thatax.blog.163.com/blog/static/20892680200871494531969/
随着OOXML与ODF的竞争为世人所知，微软又一次与开放扯上了关系。9月初OOXML在ISO
的投票失败之后，就免不了有一批微软的粉丝们忿忿不平，他们很无辜地质问道，不是
要一个开放文档标准吗？OOXML不是开放文档标准吗？为什么要反对呢？难道微软提出的
开放标准就不是开放标准吗？当然对面阵营的人士也不含糊，他们凭直觉抗拒把微软与
开放并列，并且质疑OOXML厚达数千页的说明规范是一种阴谋，或者至少会反对在ODF之
外另立一个开放文档标准。不过不能否认，仅从法理上看，OOXML的开放性并不存在什么
问题。其唯一的问题就是OOXML背后的名字——微软。在越来越开放的软件产业里，微软
几乎是传统封闭势力的最后一块保留地。尽管做出了一些小的、无足轻重的姿态，但是
在整体上讲，它仍然强硬地抗拒开放的趋势，禁止在自己的几乎任何产品和项目中使用
和参与开放软件，并且在各种场合散布反对开源的观点，试图使人们的思想重新回到十
数年前的状态。这些都不假，但是具体到OOXML这件事情上，微软的“开放性”似乎又确
实无可指责。这就给我们讨论这一话题带来了困难：总不能仅凭臆测就妄断是非曲直吧
。
在这种时候，讲一点实证主义是有好处的，认真地了解一点历史故事，看看历史上微软
在开放标准领域的所作所为，有助于我们更好地理解现在正在发生的事情。
很遗憾的，在微软不长的历史中，每次与开放扯上关系，几乎都是充当反面教员的角色
。人们记忆犹新的，如微软分化和吞噬Java的企图，在Web标准方面与W3C唱对台戏的故
事。然而有一段几乎被人遗忘的精彩故事，其实却能更全面、更深入地揭示微软对于开
放标准的策略和手段。现在就让我们来回顾一下这个充满了权谋、利诱、屈膝投降和最
终悲剧收场的真实往事。
1. 和平年代
这段往事发生在实时3D计算机图形API领域。
计算机图形学就是用数学计算和软硬件手段在计算机输出设备上绘制图形的学问，1970
年代以来，随着相应设备和研究的进展，计算机图形学获得了快速的发展。人是视觉动
物，因此图形毫无疑问是计算机最重要的应用领域之一。一开始，计算机图形的主要应
用是在科学和工程方面，比如统计图表、CAD等。1970年代末期，视频游戏出现了，计算
机图形学很快从壁垒森严的国家实验室和军方研究机构走出来。不过那个时候很少有人
想到，计算机图形最终能够实施绘制以假乱真的三维真实感图形，营造一个虚拟现实。
1992年斯皮尔伯格的《侏罗纪公园》引起全球轰动，计算机绘制真实感图形的能力已经
无人质疑，而这一领域的进展将给游戏、CAD、教育、科学、管理和军事等几乎所有IT应
用领域带来完全革命性的变化。毫无疑问，这个领域是兵家必争之地。
但是怎么个争法呢？做图形硬件？当然好，但是很快就会有竞争对手。做应用软件或者
游戏，不错，不过也是局限于一时之争。在IT领域里，真正高层次的竞争是工业标准的
竞争，那么在计算机图形领域里，最重要的工业标准是什么呢？毫无疑问，就是图形AP
I。所有的开发者都希望用统一的方式编写图形程序，这就给在这个领域里形成工业标准
创造了条件。一旦这样的API标准出现并且被接受，那么所有的硬件设备制造商都得老老
实实地实现这个API标准，并尽量对它实施优化件，所有的平台制造商都得支持这个API
标准，所有软件开发商都得在这个API之上开发图形软件。谁要是掌握这个标准，就可谓
挟天子以令诸侯，一呼天下应。意识到这一点，就不难明白，3D图形API是影响整个计算
机图形工业的重大标准，兹事体大，不可等闲视之。也正是因此，绝不应该让这么重大
的技术标准落入一家把持之下。
在当时，因为《侏罗纪公园》绘制逼真的恐龙场景而闻名于世的SGI当然是这个领域的领
先者，事实上，当时SGI手上有三大法宝——其一是SGI图形工作站，其二是专门针对图
形应用而优化的UNIX变体IRIS，其三是被称为IRIS GL的3D真实感图形API。这个IRIS G
L这是经过在SGI工作的顶尖计算机图形学专家和工程师们数年心血的结晶，干净、清晰
而且非常先进，在当时可谓无人可望其项背。
SGI本来坐居高端图形产业的顶峰，似乎可以高枕无忧。不过当时SGI也发现独孤求败的
滋味并不好受，至少业绩的进一步成长受到了明显的限制。于是SGI决定将IRIS GL开放
出来，让它尽快成为工业标准。SGI完全就是无私奉献吗？它是不是想凭借OpenGL控制图
形工业？我们不得而知，不过无论是当时还是事后来看，这一举动有巨大的进步意义。
相关厂商一拍即合，1992年初，OpenGL体系结构审核委员会（OpenGL Architecture Re
view Board，简称OpenGL ARB）正式成立，当年7月，经过认真审核和提高的OpenGL 1.
0规范正式出炉，标志着3D图形API正式步入开放时代。
实事求是地说，虽然已经冠以 “Open”的名号，不过OpenGL当时很大程度上还是受SGI
影响的。你要在自己的平台上实现OpenGL，就得给SGI缴纳授权金。当然，也不是SGI一
家独大，否则谈何开放？所谓开放，实际上是指OpenGL标准在制订过程中， ARB成员都
可以充分讨论，自由发表意见，就标准的大小问题投票。应该说，这一过程还是能够保
证标准的公平、公正和公开，在当时是相当不错的了。实际上Java刚出道的时候，也差
不多是这个模式，在开源还没有大行其道的时候，这就算是开放了。当然，按照今天的
标准，这个开放的程度还很不够，抚今追昔，今天的计算机用户和程序员，着实应该好
好感谢1990年代末期的开源运动。
在OpenGL ARB的创始成员中，微软的名字赫然在列。那时候的微软，尽管还没有后来那
样不可一世的霸气，但是也已经非常强大，它会甘心全心全意支持OpenGL的发展吗？
我们现在当然无法了解当时微软对于OpenGL的真实态度，但是最初微软的表现还是不错
的。当时Windows NT正在研发当中，其主要的目标之一就是与基于UNIX的图形工作站竞
争，因此微软内部的一个小组积极支持了Windows平台的OpenGL发展。随着PC上图形硬件
的飞速发展，大约在1990年代中期，PC终于可以与高端图形工作站相比，在这个过程中
，Windows与OpenGL之间的关系，即使不能用蜜月来形容，至少也是相当和谐的。
另一个很重要的原因，就是微软此时在图形领域还羽翼未丰，甚至可以说，还相当幼稚
，根本不具备跟SGI相抗衡的实力。著名的WinG事件就暴露了当时微软在图形领域的薄弱
实力。那个时候，Windows 3.0/3.1已经开始大肆流行，可是PC上所有像样子的图形和游
戏程序无一例外是在DOS下直接访问视频缓冲区，Windows的GDI本身就是为静态图形设计
的，在当时的硬件上慢得要死，因此还冒出来一种叫做“Windows图形加速卡”之类的硬
件来帮助Windows GDI图形加速，根本就自身难保，别提还在上面开发高性能动画图形程
序了。不过微软已经明确Windows就是它的未来，因此努力试图证明Windows可以成为合
格的游戏开发平台。大约在1994或1995年，微软推出了一个叫做WinG的图形开发包。这
个开发包的主要功能，就是帮助图形开发者在Windows 3.0/3.1中快速绘制2D图形，从而
实现动画功能。WinG实际上是一组DLL，安装之后，它将替换Win16中CreateDIBSection
()、SetDIBColorTable()、BitBlt()和StretchBlt()等API，并通过提供一种被称为Win
GDC的设备上下文，提供对图形数据双向读写的能力，从而实现快速的像素矩阵Blit。那
个时候的游戏和动画主要是2D的，衡量性能的核心指标就是Blit的速度。所以WinG也算
是门当户对。笔者还记得当年运行WinG中的一些例子，屏幕上的窗口里眼花缭乱地快速
绘制彩色方块和线条，看上去确实不慢。但是很显然，微软那时根本就不理解图形和游
戏程序员的需求，WinG这个东西既没有提供直接访问视频缓冲区的能力，有没有提供高
层的图形API，如同鸡肋，从来就没有流行开，从而也迅速被微软抛弃。事后，微软甚至
根本就不承认WinG的存在，此事被传为“佳话”，为天下笑。在这样的局面下，微软对
OpenGL采取合作态度，也是时势使然。
不管怎么样，这是一段风平浪静的和平年代。
一切看上去都很好，当PC图形硬件进一步发展，传统上用于科学与工程领域的OpenGL在
游戏领域中也开始显现出巨大的潜力，它成熟、强大、干净而且特别适合于教学，似乎
没有什么能阻挡OpenGL成为PC游戏的首选图形API。然而就在同时，随着Windows 95的巨
大成功，微软成为业界霸主，实力空前壮大，心态也就悄悄发生了变化。1996年9月15日
，微软在刚刚发布的DirectX套件中附带了一个被称为Direct3D的新组件，并且开始在各
种场合宣称散步对OpenGL不利的言论，企图让程序员相信Direct3D才是专门针对游戏的
3D图形API。美好的和平时代终结了。
2. Direct3D vs. OpenGL
在Andre LaMothe游戏编程的经典著作《Windows游戏编程大师技巧》中介绍DirectX的时
候，作者以其特有的LaMothian式幽默感叹道：
“我开始感觉自己变成微软的传教士了，总在试图把我所有的朋友们都推向这个黑势力
。但是有什么办法呢？微软这帮坏家伙总是能研究出更好的技术。”
这一说法集中体现了游戏程序员的矛盾心态。当然在今天，特别是在Google的光辉下，
很多人会直截了当地反对“微软技术更好”的说法，但是在1990年代的中后期，微软的
确在软件技术的所有领域都高歌猛进，在3D图形API领域也不例外。
1994年，微软的全部精力都集中在即将发布的Windows 95上。从各个领域传来的声音都
表明，Windows 95将是一款划时代的极为成功的操作系统。但是在一片叫好声中，也存
在一些不和谐音符，这就是来自PC游戏开发领域的质疑声。大部分视频游戏的开发者坚
定地认为，DOS是比Windows 95更好的游戏开发平台。在DOS下，程序员可以独占机器的
全部资源，不用担心同时运行的另外的进程的干扰。更重要的是，DOS允许程序员直接访
问硬件设备，尽管这带来的沉重的负担（需要针对市面上流行的每一款显卡和声卡写驱
动程序），但是却能保证最大的速度。相反，Windows 95采用了保护模式，在硬件之上
建立了层层的抽象，限制了对设备的访问，对于性能敏感的游戏程序员来说，这是难以
接受的。再加上当时Watcom C/C++和DOS4GW等技术已经非常成熟，DOS在PC游戏产业中的
地位看上去是牢不可破的。事实上，这种情况持续到Windows 95发布后的最初几年里，
那时候大部分游戏玩家为了玩高质量的视频游戏，不得不在硬盘上保留一个DOS操作系统
。有人甚至据此断言说，DOS永远都会存在下去。
微软的高层对这种情况并不高兴，但是似乎并没有什么办法，WinG的失败使人不得不对
Windows游戏领域谨慎从事。况且这个时候微软已经将OpenGL置入Windows中，就算是在
Windows上开发游戏，OpenGL应该也是当然之选。一切似乎已成定局，如果不是三名微软
程序员的冒险行动，历史将会是另一番模样。
<!--[if !vml]-->
图1. DirectX 1.0 Logo
大约在1994年的下半年，微软的三名工程师Craig Eisler、Alex St. John和Eric Engs
trom不甘心让Windows 95沦为二流的游戏平台，决心一起努力来解决这个问题。他们冒
险发起了一个项目，目标是让Windows 95平台上的游戏程序员也能够全速访问硬件设备
，Eisler任dev lead，St. John是主开发，Engstrom任程序经理。这个项目开始的时候
，距离Windows 95预定的正式发布时间只有几个月，因此，这个项目的地位非常微妙：
一方面，微软内部许可和支持它，给这三剑客照付工资，另一方面，这并不是一个“一
定要成功”的项目，也没有得到更强力的支持，无论它的结局如何，Windows 95会照常
发布。就在这样的局面下，技术史上又一个无心插柳柳成荫的故事诞生了。三人找到了
解决问题的办法，并且逐渐完善，形成了后来被称为DirectX的解决方案。很显然，这一
成果令包括比尔盖茨本人在内的微软高层大喜过望，立刻倾注大量资源予以全力支持。
<!--[if !vml]--><!--[endif]-->
图2. 1996年发布的Command & Conquer Red Alert CD封面
1995年9月，Windows 95正式发布后仅仅一个月，DirectX的第一个版本以“Windows Ga
mes SDK”的名义发布了。此后一年，微软像旋风般地连发三个DirectX版本。1996年9月
发布的Direct 3.0被认为是DirectX的第一个成熟版本。1996年底当时如日中天的Westw
ood工作室发布即时战略游戏《红色警戒》，这款游戏分为DOS和Windows 95两版，其中
Windows 95版就是基于DirectX开发的。这款2D游戏采用640x480甚至更高的800x600分辨
率，在Windows 95下表现相当出色。当时的大学校园里，奔腾电脑刚刚进入寝室，若干
玩家自建网络，多人联机对战“红警”，一片喊杀声震天，开寝室游戏联机对战风气之
先河。《红色警戒》全球正版销量1200万张，创造了即时战略类游戏的吉尼斯世界纪录
。正是这款游戏的巨大成功，使得整个PC游戏开发产业确信，DOS将成为过去，Windows
和DirectX是游戏开发的未来。
图3. 红色警戒续篇The Aftermath截图
最初的DirectX与OpenGL并不构成明显的竞争关系，两者分工明确。DirectX对硬件要求
低，对应普通家用PC配置，长于开发2D游戏。而OpenGL对显卡要求高，目标是高端图形
工作站平台，主攻CAD市场，倒也算是泾渭分明。从技术上讲，当时微软内部正处于COM
技术的高峰时代，几乎所有东西都要COM化，DirectX也不例外。DirectX以COM组件的方
式暴露API，编程比较繁琐复杂，但也促进了C++在视频游戏中的应用——用C语言去访问
COM实在是一种吃饱了撑的自找麻烦的行为。而OpenGL自始至终保持平坦化的C风格的AP
I，毕竟其本质不过是图形硬件的一个接口，每个API调用最终会变成通过PCI总线对图形
硬件发出的命令。因此，OpenGL编程简洁明了一些，但这并不是说OpenGL简单，3D图形
编程从来也不是一件简单的事情。从图形功能上讲，DirectX中主要的视频模块称为Dir
ectDraw，其主要出发点是向程序员提供对于视频缓冲区（frame buffer）的直接访问能
力，从而能够以写内存的方式在屏幕上绘制图形元素，特别是能够飞快地bitblt图像到
视频缓冲区中，以及快速在屏幕上滚动场景的能力，而这正是高性能2D游戏的关键。Op
enGL虽然也提供了读写视频缓冲区的能力，但是其重点在于3D图形，用户只需要在Open
GL的逻辑空间中把所需要的图形“画出来”就行，至于3D图形怎样投影并栅格化到2D的
屏幕上来，OpenGL会替你代劳。因此，OpenGL是比DirectDraw更高层的图形API，两者之
间没有明确的竞争关系。然而这并不是说DirectDraw对OpenGL没有冲击。事实上，正是
因为DirectDraw的出现，延缓了Windows游戏开发人员接受OpenGL的速度。倘若没有Dir
ectDraw，Windows游戏开发人员最迟在1997年就一定会采用OpenGL作为游戏图形API，那
样的话，OpenGL一统天下的局面就会迅速出现。DirectDraw打了一个时间差，而这个时
间差后来被证明至关重要，因为Direct3D很快就开始与OpenGL正面对垒。
DirectX 3.0发布不久，微软发布了一个更新版，内部版本号从4.04.00.0068增加到了“
4.04.00.0069”。从版本号上看，这次更新小得不能再小了。然而具有讽刺意义的是，
这实际上是一次对整个产业具有决定性影响的重大事件，因为在这个DirectX 3.0更新版
中，附加了一个被称为Direct3D的组件。正是这个组件，在不到五年的时间里成为主宰
整个PC游戏图形工业的标准，也彻底打碎了OpenGL试图在这个产业建立起来的开放而平
等的局面。
Direct3D是怎么冒出来的呢？虽然发明DirectX的三剑客是非常杰出的工程师，但是他们
的强项在于计算机系统，而要开发出可与OpenGL匹敌的3D API，就得有一个精通3D数学
和图形算法，对图形硬件极为熟悉，拥有丰富游戏开发经验，且具备大局观的大师级人
物坐镇背后。即使是在今天，这样的人才也绝对是凤毛麟角，更不用说在1990年代初期
了。在当时，全世界屈指可数的几个高手几乎全在SGI、NASA这类的大机构力高官厚禄，
微软想要发展自己的3D API，就得往小公司身上打主意。这时候，一家成立于1992年的
英国公司RenderMorphics被纳入微软的法眼。这家小公司成立了一个Reality Lab实验室
，专事3D图形技术及API技术研究。在当时，这家公司在当时并不大的3D图形中间件市场
三分天下有其一，已经是很不简单。而其背后的灵魂人物Servan Keondjian几乎是身处
SGI之外最牛的3D开发大师。受到DirectX项目进展的鼓励，微软开始信心膨胀，大约到
2004年底，微软就决定要连人带公司把Servan和他的RenderMorphics一口吃下。谈判进
展飞快，1995年2月，微软收购RenderMorphics，Servan也成功被微软招入麾下，主持D
irect3D项目的开发。这就是Direct3D的源流。
Direct3D最初发布的时候有两个模式，一个称为Retain模式，另一个称为Immediate模式
。Retain模式的大意是用事先建好一个3D模型，让摄像机在里面运动，得到屏幕上的运
动的3D图像。这种方式适合于某些应用和游戏的开发，但严格来说与OpenGL并不是一回
事，仍然不构成直接竞争关系。而Immediate模式则是直截了当地与OpenGL分庭抗礼，其
面向的问题与OpenGL完全相同。除了一些技术细节上的区别（比如OpenGL采用右手系，
Direct3D采用左手系）之外，两者最大的差别就是，一个是跨平台的，开放的，一个是
专供Windows平台的，专有的。
说实话，Direct3D的最初版本远未达到工业级别，成熟度与OpenGL相去甚远。它不但完
全以COM组建方式暴露接口，而且设计的非常繁琐。任何一个简单的操作，哪怕只是一次
状态改变，都需要创建和提交一种称为“execute buffer”的对象。这不仅意味着编程
的复杂性大大提高，代码的可读性大大降低。但是，这毕竟是一个3D图形API，而且站在
它背后的是微软巨人，没人会小看它。相反，正是因为人们十分清楚微软的力量，因此
对于Direct3D的出现将导致的3D图形API大分裂的局面感到非常忧心。一时间，要Direc
t3D还是要OpenGL的争论尘嚣日上。
这个时候，发生了一件在游戏开发历史上非常著名的事件。DOOM的主程序、3D游戏程序
员的精神领袖John Carmack发表了公开发表了一篇文章。他在尝试将Quake游戏移植到两
种API上，并且从功能、性能、驱动程序支持和使用的易用性四方面对Direct3D和OpenG
L进行了对比，得出的结论是，两者功能相当，性能接近，驱动程序方面，Direct3D略有
优势，所以前三项基本旗鼓相当。但是从易用性来看，OpenGL的优势是压倒性的。由于
Direct3D中executive buffer的存在，Direct3D程序非常繁琐晦涩，用它简直是自找麻
烦。在这封公开信的结尾，Carmack坚定地站在了OpenGL的一边，甚至呼吁微软放弃Dir
ect3D，拥抱OpenGL。他最后说：“在接下来的很多年里，我每天都会基于3D API编写程
序。我需要真正能帮助我的东西，而不是给我带来麻烦的东西。”
<!--[if !vml]--><!--[endif]-->
图4. John Carmack，程序员的偶像
这一权威的、理性的声音很大程度上冲销了微软的宣传功效，但显然不可能使微软放弃
自己亲生的Direct3D。相反，John Carmack实际上充当了一个咨询专家，让微软认识到
了Direct3D的缺陷所在。到了1997年6月DirectX 5.0发布的时候，微软在Direct3D中加
入了DrawPrimitive API，消除了创建executive buffer的必要。但实际上，DrawPrimi
tive仍然是一个不怎么样的设计，另一个3D大牛Chris Hecker给微软写了一封公开信，
在信里他说，DrawPrimitive“是OpenGL设计的一个不成熟的、糟糕的抄袭，但却偏偏漏
掉了使OpenGL如此高效的关键的架构决策”。
但是，此一时也彼一时也，这封公开信影响有限。微软强大的宣传机器已经开始全力运
作起来，在整个市场上到处嚷嚷“今年过节不游戏呀不游戏，游戏就用D3D呀D3D”。更
厉害的是，仗着微软在操作系统领域的霸主地位，微软开始与众多硬件厂商谈判，要求
它们优先支持DirectX。不但如此，很多人猜测，微软故意降低了OpenGL在Windows平台
上的性能，采取不正当手段败坏OpenGL的名誉。这种咄咄逼人的攻势之下，OpenGL ARB
这个松散的组织软弱无力的一面就体现出来了，基本上束手无策。
胜利的天平似乎开始向微软倾斜了。怎么办？
这个时候，SGI——OpenGL的娘家人——挺身而出。
3．SGI沦陷
1990年代中期，3D硬件还是昂贵稀罕的东西，无论是OpenGL还是Direct3D，很多时候实
际的渲染是软件实现的。所谓软件渲染，也就是通过CPU计算来实现渲染效果。人们发现
，在微软的Windows平台上，OpenGL的软件渲染速度比Direct3D慢很多倍。微软对此的解
释是，OpenGL本身的设计是面向CAD类应用的，适用于精确严格的渲染，因此必须搭配昂
贵的3D硬件才能表现突出。如果你想只用软件来模拟，对不起，由于OpenGL设计上的某
些“缺陷”，它就是比DirectX慢很多倍，因为后者是从头到脚面向实时渲染而设计的。
然而计算机图形专业人士怀疑，这根本就是不实之词，OpenGL与Direct3D在性能表现上
的差异，根本就与设计无关，完全是因为微软没有用心实现OpenGL。但是光怀疑没用，
你说微软实现得不好，你自己实现一个看看？说实话，这可不是一个容易的事情，没有
两下子是绝对没戏的。
这时候，SGI站出来了。1996年，在新奥尔良举办的SigGraph会议上，SGI展示了他们实
现的OpenGL for Windows，并且把Direct3D的几个流行demo移植到OpenGL上，将两者进
行了针锋相对的比较。结果是显而易见的，OpenGL不但不比Direct3D慢，而且在某些方
面还更胜一筹。API之战的第一回合，OpenGL获胜，结果不但是OpenGL给自己正了名，而
且还迫使微软优化了自己的OpenGL实现。
不过，对于游戏开发来说，软件渲染还是太慢，无论是OpenGL还是Direct3D，软件渲染
做做Demo还可以，要开发好玩的3D游戏，没有硬件支持那是不行的。1990年代中后期，
3D硬件越来越便宜，迅速普及到家用PC上，这才使得高性能视频游戏飞入寻常百姓家。
这时候，哪个API得到更广泛而高质量的硬件支持，哪个API就会表现出色。于是API之战
的第二回合，就成为驱动程序之战了。而在这一方面，微软凭借其强大的产业控制力，
显然占据优势。
战役主要发生在1997年。当时Windows 98正在做大规模的售前宣传，微软宣称，Window
s 98将成为PC游戏玩家的最佳平台，因此，厂商们都在积极开发Windows 98上的游戏，
争取在圣诞节大捞一票。到底是用OpenGL还是Direct3D呢？因为此前发生的Carmack公开
信事件，很多游戏厂商都倾向于采用OpenGL。要在Windows 98上支持OpenGL，最好使用
微软提供的一个驱动程序工具包，这个工具包基于微软开发的Mini-Client Driver（MC
D），从而使得硬件厂商可以很轻松地开发OpenGL驱动程序。在1997年GDC大会上，大部
分主流3D硬件厂商都展示了基于MDC的OpenGL驱动程序，但是由于MDC是微软的产品，而
微软对OpenGL的态度又不明朗，因此游戏厂商还是不敢造次，老老实实地用DirectX开发
。不久之后，游戏厂商的谨慎被证明是正确的，微软在1997年夏天，对那些企图在Wind
ows 98上支持OpenGL的硬件厂商来了一次釜底抽薪，宣布说，除了开发阶段，任何厂商
都不能获得MCD的使用许可。这等于是给那些基于MCD的OpenGL驱动程序判了死刑。一时
间Direct3D无与争锋，仅仅一年时间就成为了3D游戏的事实标准。
来而不往非礼也，SGI再一次挺身而出。早在微软釜底抽薪之前，SGI实际上就提供了自
己的OpenGL驱动程序工具包，在其中，SGI使用了一种完全不同于MCD的驱动程序支持模
型，称为Installable Client Driver（ICD）。要从纯技术角度来看的话，ICD的好处是
性能高，缺点是比较复杂，总体来讲是不如MCD的。可无奈你微软上屋抽梯，让人家硬件
厂商无路可走，于是只好跟着ICD打游击了。渐渐的，基于ICD的OpenGL驱动程序越来越
多，很多有影响力的游戏厂商开始重新考虑支持OpenGL。在这种局面下，微软也只好顺
水推舟，重新放开MCD限制，允许厂商在Windows 98上支持OpenGL。第二回合，微软先赢
后输，虽然一时间称霸3D游戏API领域，但是胜利并不稳定。
两回合下来，微软终于明白硬碰硬并不是好办法，需要另谋高招。1998年的SigGraph上
，人们惊奇地发现，微软与SGI站在一起，宣布要共同开发一个新的、统一的3D图形API
，他们称之为Fahrenheit Project。这个项目是谁构思出来的，微软是如何说服SGI的，
现在已经无据可查。总之，按照当时的承诺，这个项目将在1999年或2000年推出实质产
品。看到几年来拉锯般的3D API之战终于要结束了，合作时代即将到来，几乎所有人都
兴奋不已。和平万岁！未来属于Fahrenheit！
战争结束，合作开始，SGI以满腔热情投入了Fahrenheit的开发之中，不但不再全力支持
OpenGL了，而且连自己的起家之本——基于MIPS的图形工作站，也甩掉一边。公允的说
，SGI的动机也不是那么单纯。对他们来说，MIPS图形工作站的衰亡史不可避免的，这一
点十分清楚。普通Wintel PC很快就会让高端图形工作站变成昂贵的废物。那么如何在P
C市场重现荣光呢？Fahrenheit项目毫无疑问是一个很好的切入点，跟PC软件领域的霸主
合作，使得SGI有机会进入这个超级庞大的市场，并掌握3D图形API的标准，这种好事，
当然不可错过！
问题在于，SGI看错了微软。微软岂能轻易放弃自己在3D领域好不容易获得的霸权，拱手
把半壁江山让与SGI呢？到1999年年中的时候，情形已经非常明显，微软并没有遵守去年
许下的诺言，事实上，微软除了派去几个专家参与制定Fahrenheit标准文档，做做表面
文章之外，根本没有投入开发力量，从而把具体工作一口气全甩给SGI去做，让对手不再
有足够资源投入到OpenGL上。同时，微软自己则继续将大笔资源倾注到DirectX的下一个
版本——也就是日后打赢关键一仗的主力军——DirectX 7.0上。不但如此，微软还使出
对付Borland和其它对手的老招数——挖角，不断以高官厚禄引诱SGI的顶级专家们。这
样的搞法，Fahrenheit能成功才是见了鬼了。
一来二去，全世界都明白了，SGI被忽悠了！不过为时已晚。2000年，DirectX 7.0问世
，一时间横扫3D图形市场。而传说中的Fahrenheit呢？则还只是停留在概念上的东西。
Fahrenheit总架构师David Blythe被微软成功挖角。如今，这个当年OpenGL领域数一数
二的顶级大师已经摇身一变成为DirectX 10的主设计师和Windows Presentation Frame
work的主要设计者之一。好一个Fahrenheit项目！让微软人财两得，而SGI不单是赔了夫
人又折兵，更失去了广大OpenGL社群的尊敬，不可不谓惨。
打输这一仗，SGI算是把老底和老脸都输光了。自那以后，SGI每况愈下，直到2006年，
终于难以支撑，向法院申请破产。一代高科技传奇，竟落得这般田地。
好在毕竟技术底子雄厚，在2007年，SGI成功地经历了一次重组。重组后的SGI，变成了
一个超级计算机、服务器集群和存储的系统厂商，跟图形已经基本没有关系了。不知道
如今SGI的人看到公司名字里的“G”，鼻子会不会酸呢？
好在OpenGL并没有因为SGI的沉沦而完蛋，相反，失去了商业巨头的支撑和控制，OpenG
L反倒真正成了开放的API，获得整个产业的支持。
4．凤凰涅磐
进入21世纪之后，图形软件市场发生了有趣的变革。首先，由于Web的大发展，微软在桌
面操作系统上一统天下的局面出现了松动。如今，人们开发一个桌面应用程序必须考虑
在Windows和Mac，甚至还有Linux三个平台上的可移植性，这就使得OpenGL的标准和开放
性成为一个重大的优势。其次，图形硬件市场实现了整合，nVidia和ATI成为GPU市场的
领袖，它们具有足够的财力和技术实力，可以按照自己的意愿对OpenGL提供第一流的支
持。第三，更重要的变革在于，PC已经不再是唯一的3D图形应用平台，智能家电、游戏
机、手机、PDA、车载计算机、工业设备、机器人等都成为新的图形应用平台。在这些平
台上，OpenGL是独一无二的首选方案。微软不但是后来者，而且恰恰因为微软在PC软件
领域的巨大成功，从而引起整个产业对它四面设防，从而使它很难取得大的成功。
2002年，OpenGL 1.4完成，使OpenGL在固定管线技术上达到了最高峰。2004年，划时代
的OpenGL 2.0推出，引入了GLSL，允许开发者使用可编程管线功能，从而使OpenGL登上
了现代图形硬件发展的快车。2006年8月，OpenGL 2.1发布，成为当前主流的OpenGL版本
。
凤凰涅磐的时刻即将到来。按计划，OpenGL 3.0将于2008年推出。这个新的标准在保留
对传统API支持的前提下，从头开始全新设计，提出了更先进的图形概念和对象模型，从
而走到了图形编程的最前沿。
此外，更令人兴奋的或许是OpenGL ES。这个专供嵌入式系统使用的OpenGL“精简版”如
今已经是手机、PDA、车载设备等嵌入式平台上的标准图形API。只要想想手机的用户量
，我们就不难憧憬OpenGL ES的光明灿烂的前景。给所有人以希望，这就是开放的伟大之
处。
在以后的日子里，我们大概不会再见到十年前那样激烈的API战争了，因为开放已经成为
我们每个人的共识。但是，这段历史却不应该被遗忘。正如马克吐温所说，历史不会简
单的重复，而是会变奏式的重复。我们应该保持警惕，珍视开放和自由带给每个人的价
值。
的投票失败之后，就免不了有一批微软的粉丝们忿忿不平，他们很无辜地质问道，不是
要一个开放文档标准吗？OOXML不是开放文档标准吗？为什么要反对呢？难道微软提出的
开放标准就不是开放标准吗？当然对面阵营的人士也不含糊，他们凭直觉抗拒把微软与
开放并列，并且质疑OOXML厚达数千页的说明规范是一种阴谋，或者至少会反对在ODF之
外另立一个开放文档标准。不过不能否认，仅从法理上看，OOXML的开放性并不存在什么
问题。其唯一的问题就是OOXML背后的名字——微软。在越来越开放的软件产业里，微软
几乎是传统封闭势力的最后一块保留地。尽管做出了一些小的、无足轻重的姿态，但是
在整体上讲，它仍然强硬地抗拒开放的趋势，禁止在自己的几乎任何产品和项目中使用
和参与开放软件，并且在各种场合散布反对开源的观点，试图使人们的思想重新回到十
数年前的状态。这些都不假，但是具体到OOXML这件事情上，微软的“开放性”似乎又确
实无可指责。这就给我们讨论这一话题带来了困难：总不能仅凭臆测就妄断是非曲直吧
。
在这种时候，讲一点实证主义是有好处的，认真地了解一点历史故事，看看历史上微软
在开放标准领域的所作所为，有助于我们更好地理解现在正在发生的事情。
很遗憾的，在微软不长的历史中，每次与开放扯上关系，几乎都是充当反面教员的角色
。人们记忆犹新的，如微软分化和吞噬Java的企图，在Web标准方面与W3C唱对台戏的故
事。然而有一段几乎被人遗忘的精彩故事，其实却能更全面、更深入地揭示微软对于开
放标准的策略和手段。现在就让我们来回顾一下这个充满了权谋、利诱、屈膝投降和最
终悲剧收场的真实往事。
1. 和平年代
这段往事发生在实时3D计算机图形API领域。
计算机图形学就是用数学计算和软硬件手段在计算机输出设备上绘制图形的学问，1970
年代以来，随着相应设备和研究的进展，计算机图形学获得了快速的发展。人是视觉动
物，因此图形毫无疑问是计算机最重要的应用领域之一。一开始，计算机图形的主要应
用是在科学和工程方面，比如统计图表、CAD等。1970年代末期，视频游戏出现了，计算
机图形学很快从壁垒森严的国家实验室和军方研究机构走出来。不过那个时候很少有人
想到，计算机图形最终能够实施绘制以假乱真的三维真实感图形，营造一个虚拟现实。
1992年斯皮尔伯格的《侏罗纪公园》引起全球轰动，计算机绘制真实感图形的能力已经
无人质疑，而这一领域的进展将给游戏、CAD、教育、科学、管理和军事等几乎所有IT应
用领域带来完全革命性的变化。毫无疑问，这个领域是兵家必争之地。
但是怎么个争法呢？做图形硬件？当然好，但是很快就会有竞争对手。做应用软件或者
游戏，不错，不过也是局限于一时之争。在IT领域里，真正高层次的竞争是工业标准的
竞争，那么在计算机图形领域里，最重要的工业标准是什么呢？毫无疑问，就是图形AP
I。所有的开发者都希望用统一的方式编写图形程序，这就给在这个领域里形成工业标准
创造了条件。一旦这样的API标准出现并且被接受，那么所有的硬件设备制造商都得老老
实实地实现这个API标准，并尽量对它实施优化件，所有的平台制造商都得支持这个API
标准，所有软件开发商都得在这个API之上开发图形软件。谁要是掌握这个标准，就可谓
挟天子以令诸侯，一呼天下应。意识到这一点，就不难明白，3D图形API是影响整个计算
机图形工业的重大标准，兹事体大，不可等闲视之。也正是因此，绝不应该让这么重大
的技术标准落入一家把持之下。
在当时，因为《侏罗纪公园》绘制逼真的恐龙场景而闻名于世的SGI当然是这个领域的领
先者，事实上，当时SGI手上有三大法宝——其一是SGI图形工作站，其二是专门针对图
形应用而优化的UNIX变体IRIS，其三是被称为IRIS GL的3D真实感图形API。这个IRIS G
L这是经过在SGI工作的顶尖计算机图形学专家和工程师们数年心血的结晶，干净、清晰
而且非常先进，在当时可谓无人可望其项背。
SGI本来坐居高端图形产业的顶峰，似乎可以高枕无忧。不过当时SGI也发现独孤求败的
滋味并不好受，至少业绩的进一步成长受到了明显的限制。于是SGI决定将IRIS GL开放
出来，让它尽快成为工业标准。SGI完全就是无私奉献吗？它是不是想凭借OpenGL控制图
形工业？我们不得而知，不过无论是当时还是事后来看，这一举动有巨大的进步意义。
相关厂商一拍即合，1992年初，OpenGL体系结构审核委员会（OpenGL Architecture Re
view Board，简称OpenGL ARB）正式成立，当年7月，经过认真审核和提高的OpenGL 1.
0规范正式出炉，标志着3D图形API正式步入开放时代。
实事求是地说，虽然已经冠以 “Open”的名号，不过OpenGL当时很大程度上还是受SGI
影响的。你要在自己的平台上实现OpenGL，就得给SGI缴纳授权金。当然，也不是SGI一
家独大，否则谈何开放？所谓开放，实际上是指OpenGL标准在制订过程中， ARB成员都
可以充分讨论，自由发表意见，就标准的大小问题投票。应该说，这一过程还是能够保
证标准的公平、公正和公开，在当时是相当不错的了。实际上Java刚出道的时候，也差
不多是这个模式，在开源还没有大行其道的时候，这就算是开放了。当然，按照今天的
标准，这个开放的程度还很不够，抚今追昔，今天的计算机用户和程序员，着实应该好
好感谢1990年代末期的开源运动。
在OpenGL ARB的创始成员中，微软的名字赫然在列。那时候的微软，尽管还没有后来那
样不可一世的霸气，但是也已经非常强大，它会甘心全心全意支持OpenGL的发展吗？
我们现在当然无法了解当时微软对于OpenGL的真实态度，但是最初微软的表现还是不错
的。当时Windows NT正在研发当中，其主要的目标之一就是与基于UNIX的图形工作站竞
争，因此微软内部的一个小组积极支持了Windows平台的OpenGL发展。随着PC上图形硬件
的飞速发展，大约在1990年代中期，PC终于可以与高端图形工作站相比，在这个过程中
，Windows与OpenGL之间的关系，即使不能用蜜月来形容，至少也是相当和谐的。
另一个很重要的原因，就是微软此时在图形领域还羽翼未丰，甚至可以说，还相当幼稚
，根本不具备跟SGI相抗衡的实力。著名的WinG事件就暴露了当时微软在图形领域的薄弱
实力。那个时候，Windows 3.0/3.1已经开始大肆流行，可是PC上所有像样子的图形和游
戏程序无一例外是在DOS下直接访问视频缓冲区，Windows的GDI本身就是为静态图形设计
的，在当时的硬件上慢得要死，因此还冒出来一种叫做“Windows图形加速卡”之类的硬
件来帮助Windows GDI图形加速，根本就自身难保，别提还在上面开发高性能动画图形程
序了。不过微软已经明确Windows就是它的未来，因此努力试图证明Windows可以成为合
格的游戏开发平台。大约在1994或1995年，微软推出了一个叫做WinG的图形开发包。这
个开发包的主要功能，就是帮助图形开发者在Windows 3.0/3.1中快速绘制2D图形，从而
实现动画功能。WinG实际上是一组DLL，安装之后，它将替换Win16中CreateDIBSection
()、SetDIBColorTable()、BitBlt()和StretchBlt()等API，并通过提供一种被称为Win
GDC的设备上下文，提供对图形数据双向读写的能力，从而实现快速的像素矩阵Blit。那
个时候的游戏和动画主要是2D的，衡量性能的核心指标就是Blit的速度。所以WinG也算
是门当户对。笔者还记得当年运行WinG中的一些例子，屏幕上的窗口里眼花缭乱地快速
绘制彩色方块和线条，看上去确实不慢。但是很显然，微软那时根本就不理解图形和游
戏程序员的需求，WinG这个东西既没有提供直接访问视频缓冲区的能力，有没有提供高
层的图形API，如同鸡肋，从来就没有流行开，从而也迅速被微软抛弃。事后，微软甚至
根本就不承认WinG的存在，此事被传为“佳话”，为天下笑。在这样的局面下，微软对
OpenGL采取合作态度，也是时势使然。
不管怎么样，这是一段风平浪静的和平年代。
一切看上去都很好，当PC图形硬件进一步发展，传统上用于科学与工程领域的OpenGL在
游戏领域中也开始显现出巨大的潜力，它成熟、强大、干净而且特别适合于教学，似乎
没有什么能阻挡OpenGL成为PC游戏的首选图形API。然而就在同时，随着Windows 95的巨
大成功，微软成为业界霸主，实力空前壮大，心态也就悄悄发生了变化。1996年9月15日
，微软在刚刚发布的DirectX套件中附带了一个被称为Direct3D的新组件，并且开始在各
种场合宣称散步对OpenGL不利的言论，企图让程序员相信Direct3D才是专门针对游戏的
3D图形API。美好的和平时代终结了。
2. Direct3D vs. OpenGL
在Andre LaMothe游戏编程的经典著作《Windows游戏编程大师技巧》中介绍DirectX的时
候，作者以其特有的LaMothian式幽默感叹道：
“我开始感觉自己变成微软的传教士了，总在试图把我所有的朋友们都推向这个黑势力
。但是有什么办法呢？微软这帮坏家伙总是能研究出更好的技术。”
这一说法集中体现了游戏程序员的矛盾心态。当然在今天，特别是在Google的光辉下，
很多人会直截了当地反对“微软技术更好”的说法，但是在1990年代的中后期，微软的
确在软件技术的所有领域都高歌猛进，在3D图形API领域也不例外。
1994年，微软的全部精力都集中在即将发布的Windows 95上。从各个领域传来的声音都
表明，Windows 95将是一款划时代的极为成功的操作系统。但是在一片叫好声中，也存
在一些不和谐音符，这就是来自PC游戏开发领域的质疑声。大部分视频游戏的开发者坚
定地认为，DOS是比Windows 95更好的游戏开发平台。在DOS下，程序员可以独占机器的
全部资源，不用担心同时运行的另外的进程的干扰。更重要的是，DOS允许程序员直接访
问硬件设备，尽管这带来的沉重的负担（需要针对市面上流行的每一款显卡和声卡写驱
动程序），但是却能保证最大的速度。相反，Windows 95采用了保护模式，在硬件之上
建立了层层的抽象，限制了对设备的访问，对于性能敏感的游戏程序员来说，这是难以
接受的。再加上当时Watcom C/C++和DOS4GW等技术已经非常成熟，DOS在PC游戏产业中的
地位看上去是牢不可破的。事实上，这种情况持续到Windows 95发布后的最初几年里，
那时候大部分游戏玩家为了玩高质量的视频游戏，不得不在硬盘上保留一个DOS操作系统
。有人甚至据此断言说，DOS永远都会存在下去。
微软的高层对这种情况并不高兴，但是似乎并没有什么办法，WinG的失败使人不得不对
Windows游戏领域谨慎从事。况且这个时候微软已经将OpenGL置入Windows中，就算是在
Windows上开发游戏，OpenGL应该也是当然之选。一切似乎已成定局，如果不是三名微软
程序员的冒险行动，历史将会是另一番模样。
<!--[if !vml]-->
图1. DirectX 1.0 Logo
大约在1994年的下半年，微软的三名工程师Craig Eisler、Alex St. John和Eric Engs
trom不甘心让Windows 95沦为二流的游戏平台，决心一起努力来解决这个问题。他们冒
险发起了一个项目，目标是让Windows 95平台上的游戏程序员也能够全速访问硬件设备
，Eisler任dev lead，St. John是主开发，Engstrom任程序经理。这个项目开始的时候
，距离Windows 95预定的正式发布时间只有几个月，因此，这个项目的地位非常微妙：
一方面，微软内部许可和支持它，给这三剑客照付工资，另一方面，这并不是一个“一
定要成功”的项目，也没有得到更强力的支持，无论它的结局如何，Windows 95会照常
发布。就在这样的局面下，技术史上又一个无心插柳柳成荫的故事诞生了。三人找到了
解决问题的办法，并且逐渐完善，形成了后来被称为DirectX的解决方案。很显然，这一
成果令包括比尔盖茨本人在内的微软高层大喜过望，立刻倾注大量资源予以全力支持。
<!--[if !vml]--><!--[endif]-->
图2. 1996年发布的Command & Conquer Red Alert CD封面
1995年9月，Windows 95正式发布后仅仅一个月，DirectX的第一个版本以“Windows Ga
mes SDK”的名义发布了。此后一年，微软像旋风般地连发三个DirectX版本。1996年9月
发布的Direct 3.0被认为是DirectX的第一个成熟版本。1996年底当时如日中天的Westw
ood工作室发布即时战略游戏《红色警戒》，这款游戏分为DOS和Windows 95两版，其中
Windows 95版就是基于DirectX开发的。这款2D游戏采用640x480甚至更高的800x600分辨
率，在Windows 95下表现相当出色。当时的大学校园里，奔腾电脑刚刚进入寝室，若干
玩家自建网络，多人联机对战“红警”，一片喊杀声震天，开寝室游戏联机对战风气之
先河。《红色警戒》全球正版销量1200万张，创造了即时战略类游戏的吉尼斯世界纪录
。正是这款游戏的巨大成功，使得整个PC游戏开发产业确信，DOS将成为过去，Windows
和DirectX是游戏开发的未来。
图3. 红色警戒续篇The Aftermath截图
最初的DirectX与OpenGL并不构成明显的竞争关系，两者分工明确。DirectX对硬件要求
低，对应普通家用PC配置，长于开发2D游戏。而OpenGL对显卡要求高，目标是高端图形
工作站平台，主攻CAD市场，倒也算是泾渭分明。从技术上讲，当时微软内部正处于COM
技术的高峰时代，几乎所有东西都要COM化，DirectX也不例外。DirectX以COM组件的方
式暴露API，编程比较繁琐复杂，但也促进了C++在视频游戏中的应用——用C语言去访问
COM实在是一种吃饱了撑的自找麻烦的行为。而OpenGL自始至终保持平坦化的C风格的AP
I，毕竟其本质不过是图形硬件的一个接口，每个API调用最终会变成通过PCI总线对图形
硬件发出的命令。因此，OpenGL编程简洁明了一些，但这并不是说OpenGL简单，3D图形
编程从来也不是一件简单的事情。从图形功能上讲，DirectX中主要的视频模块称为Dir
ectDraw，其主要出发点是向程序员提供对于视频缓冲区（frame buffer）的直接访问能
力，从而能够以写内存的方式在屏幕上绘制图形元素，特别是能够飞快地bitblt图像到
视频缓冲区中，以及快速在屏幕上滚动场景的能力，而这正是高性能2D游戏的关键。Op
enGL虽然也提供了读写视频缓冲区的能力，但是其重点在于3D图形，用户只需要在Open
GL的逻辑空间中把所需要的图形“画出来”就行，至于3D图形怎样投影并栅格化到2D的
屏幕上来，OpenGL会替你代劳。因此，OpenGL是比DirectDraw更高层的图形API，两者之
间没有明确的竞争关系。然而这并不是说DirectDraw对OpenGL没有冲击。事实上，正是
因为DirectDraw的出现，延缓了Windows游戏开发人员接受OpenGL的速度。倘若没有Dir
ectDraw，Windows游戏开发人员最迟在1997年就一定会采用OpenGL作为游戏图形API，那
样的话，OpenGL一统天下的局面就会迅速出现。DirectDraw打了一个时间差，而这个时
间差后来被证明至关重要，因为Direct3D很快就开始与OpenGL正面对垒。
DirectX 3.0发布不久，微软发布了一个更新版，内部版本号从4.04.00.0068增加到了“
4.04.00.0069”。从版本号上看，这次更新小得不能再小了。然而具有讽刺意义的是，
这实际上是一次对整个产业具有决定性影响的重大事件，因为在这个DirectX 3.0更新版
中，附加了一个被称为Direct3D的组件。正是这个组件，在不到五年的时间里成为主宰
整个PC游戏图形工业的标准，也彻底打碎了OpenGL试图在这个产业建立起来的开放而平
等的局面。
Direct3D是怎么冒出来的呢？虽然发明DirectX的三剑客是非常杰出的工程师，但是他们
的强项在于计算机系统，而要开发出可与OpenGL匹敌的3D API，就得有一个精通3D数学
和图形算法，对图形硬件极为熟悉，拥有丰富游戏开发经验，且具备大局观的大师级人
物坐镇背后。即使是在今天，这样的人才也绝对是凤毛麟角，更不用说在1990年代初期
了。在当时，全世界屈指可数的几个高手几乎全在SGI、NASA这类的大机构力高官厚禄，
微软想要发展自己的3D API，就得往小公司身上打主意。这时候，一家成立于1992年的
英国公司RenderMorphics被纳入微软的法眼。这家小公司成立了一个Reality Lab实验室
，专事3D图形技术及API技术研究。在当时，这家公司在当时并不大的3D图形中间件市场
三分天下有其一，已经是很不简单。而其背后的灵魂人物Servan Keondjian几乎是身处
SGI之外最牛的3D开发大师。受到DirectX项目进展的鼓励，微软开始信心膨胀，大约到
2004年底，微软就决定要连人带公司把Servan和他的RenderMorphics一口吃下。谈判进
展飞快，1995年2月，微软收购RenderMorphics，Servan也成功被微软招入麾下，主持D
irect3D项目的开发。这就是Direct3D的源流。
Direct3D最初发布的时候有两个模式，一个称为Retain模式，另一个称为Immediate模式
。Retain模式的大意是用事先建好一个3D模型，让摄像机在里面运动，得到屏幕上的运
动的3D图像。这种方式适合于某些应用和游戏的开发，但严格来说与OpenGL并不是一回
事，仍然不构成直接竞争关系。而Immediate模式则是直截了当地与OpenGL分庭抗礼，其
面向的问题与OpenGL完全相同。除了一些技术细节上的区别（比如OpenGL采用右手系，
Direct3D采用左手系）之外，两者最大的差别就是，一个是跨平台的，开放的，一个是
专供Windows平台的，专有的。
说实话，Direct3D的最初版本远未达到工业级别，成熟度与OpenGL相去甚远。它不但完
全以COM组建方式暴露接口，而且设计的非常繁琐。任何一个简单的操作，哪怕只是一次
状态改变，都需要创建和提交一种称为“execute buffer”的对象。这不仅意味着编程
的复杂性大大提高，代码的可读性大大降低。但是，这毕竟是一个3D图形API，而且站在
它背后的是微软巨人，没人会小看它。相反，正是因为人们十分清楚微软的力量，因此
对于Direct3D的出现将导致的3D图形API大分裂的局面感到非常忧心。一时间，要Direc
t3D还是要OpenGL的争论尘嚣日上。
这个时候，发生了一件在游戏开发历史上非常著名的事件。DOOM的主程序、3D游戏程序
员的精神领袖John Carmack发表了公开发表了一篇文章。他在尝试将Quake游戏移植到两
种API上，并且从功能、性能、驱动程序支持和使用的易用性四方面对Direct3D和OpenG
L进行了对比，得出的结论是，两者功能相当，性能接近，驱动程序方面，Direct3D略有
优势，所以前三项基本旗鼓相当。但是从易用性来看，OpenGL的优势是压倒性的。由于
Direct3D中executive buffer的存在，Direct3D程序非常繁琐晦涩，用它简直是自找麻
烦。在这封公开信的结尾，Carmack坚定地站在了OpenGL的一边，甚至呼吁微软放弃Dir
ect3D，拥抱OpenGL。他最后说：“在接下来的很多年里，我每天都会基于3D API编写程
序。我需要真正能帮助我的东西，而不是给我带来麻烦的东西。”
<!--[if !vml]--><!--[endif]-->
图4. John Carmack，程序员的偶像
这一权威的、理性的声音很大程度上冲销了微软的宣传功效，但显然不可能使微软放弃
自己亲生的Direct3D。相反，John Carmack实际上充当了一个咨询专家，让微软认识到
了Direct3D的缺陷所在。到了1997年6月DirectX 5.0发布的时候，微软在Direct3D中加
入了DrawPrimitive API，消除了创建executive buffer的必要。但实际上，DrawPrimi
tive仍然是一个不怎么样的设计，另一个3D大牛Chris Hecker给微软写了一封公开信，
在信里他说，DrawPrimitive“是OpenGL设计的一个不成熟的、糟糕的抄袭，但却偏偏漏
掉了使OpenGL如此高效的关键的架构决策”。
但是，此一时也彼一时也，这封公开信影响有限。微软强大的宣传机器已经开始全力运
作起来，在整个市场上到处嚷嚷“今年过节不游戏呀不游戏，游戏就用D3D呀D3D”。更
厉害的是，仗着微软在操作系统领域的霸主地位，微软开始与众多硬件厂商谈判，要求
它们优先支持DirectX。不但如此，很多人猜测，微软故意降低了OpenGL在Windows平台
上的性能，采取不正当手段败坏OpenGL的名誉。这种咄咄逼人的攻势之下，OpenGL ARB
这个松散的组织软弱无力的一面就体现出来了，基本上束手无策。
胜利的天平似乎开始向微软倾斜了。怎么办？
这个时候，SGI——OpenGL的娘家人——挺身而出。
3．SGI沦陷
1990年代中期，3D硬件还是昂贵稀罕的东西，无论是OpenGL还是Direct3D，很多时候实
际的渲染是软件实现的。所谓软件渲染，也就是通过CPU计算来实现渲染效果。人们发现
，在微软的Windows平台上，OpenGL的软件渲染速度比Direct3D慢很多倍。微软对此的解
释是，OpenGL本身的设计是面向CAD类应用的，适用于精确严格的渲染，因此必须搭配昂
贵的3D硬件才能表现突出。如果你想只用软件来模拟，对不起，由于OpenGL设计上的某
些“缺陷”，它就是比DirectX慢很多倍，因为后者是从头到脚面向实时渲染而设计的。
然而计算机图形专业人士怀疑，这根本就是不实之词，OpenGL与Direct3D在性能表现上
的差异，根本就与设计无关，完全是因为微软没有用心实现OpenGL。但是光怀疑没用，
你说微软实现得不好，你自己实现一个看看？说实话，这可不是一个容易的事情，没有
两下子是绝对没戏的。
这时候，SGI站出来了。1996年，在新奥尔良举办的SigGraph会议上，SGI展示了他们实
现的OpenGL for Windows，并且把Direct3D的几个流行demo移植到OpenGL上，将两者进
行了针锋相对的比较。结果是显而易见的，OpenGL不但不比Direct3D慢，而且在某些方
面还更胜一筹。API之战的第一回合，OpenGL获胜，结果不但是OpenGL给自己正了名，而
且还迫使微软优化了自己的OpenGL实现。
不过，对于游戏开发来说，软件渲染还是太慢，无论是OpenGL还是Direct3D，软件渲染
做做Demo还可以，要开发好玩的3D游戏，没有硬件支持那是不行的。1990年代中后期，
3D硬件越来越便宜，迅速普及到家用PC上，这才使得高性能视频游戏飞入寻常百姓家。
这时候，哪个API得到更广泛而高质量的硬件支持，哪个API就会表现出色。于是API之战
的第二回合，就成为驱动程序之战了。而在这一方面，微软凭借其强大的产业控制力，
显然占据优势。
战役主要发生在1997年。当时Windows 98正在做大规模的售前宣传，微软宣称，Window
s 98将成为PC游戏玩家的最佳平台，因此，厂商们都在积极开发Windows 98上的游戏，
争取在圣诞节大捞一票。到底是用OpenGL还是Direct3D呢？因为此前发生的Carmack公开
信事件，很多游戏厂商都倾向于采用OpenGL。要在Windows 98上支持OpenGL，最好使用
微软提供的一个驱动程序工具包，这个工具包基于微软开发的Mini-Client Driver（MC
D），从而使得硬件厂商可以很轻松地开发OpenGL驱动程序。在1997年GDC大会上，大部
分主流3D硬件厂商都展示了基于MDC的OpenGL驱动程序，但是由于MDC是微软的产品，而
微软对OpenGL的态度又不明朗，因此游戏厂商还是不敢造次，老老实实地用DirectX开发
。不久之后，游戏厂商的谨慎被证明是正确的，微软在1997年夏天，对那些企图在Wind
ows 98上支持OpenGL的硬件厂商来了一次釜底抽薪，宣布说，除了开发阶段，任何厂商
都不能获得MCD的使用许可。这等于是给那些基于MCD的OpenGL驱动程序判了死刑。一时
间Direct3D无与争锋，仅仅一年时间就成为了3D游戏的事实标准。
来而不往非礼也，SGI再一次挺身而出。早在微软釜底抽薪之前，SGI实际上就提供了自
己的OpenGL驱动程序工具包，在其中，SGI使用了一种完全不同于MCD的驱动程序支持模
型，称为Installable Client Driver（ICD）。要从纯技术角度来看的话，ICD的好处是
性能高，缺点是比较复杂，总体来讲是不如MCD的。可无奈你微软上屋抽梯，让人家硬件
厂商无路可走，于是只好跟着ICD打游击了。渐渐的，基于ICD的OpenGL驱动程序越来越
多，很多有影响力的游戏厂商开始重新考虑支持OpenGL。在这种局面下，微软也只好顺
水推舟，重新放开MCD限制，允许厂商在Windows 98上支持OpenGL。第二回合，微软先赢
后输，虽然一时间称霸3D游戏API领域，但是胜利并不稳定。
两回合下来，微软终于明白硬碰硬并不是好办法，需要另谋高招。1998年的SigGraph上
，人们惊奇地发现，微软与SGI站在一起，宣布要共同开发一个新的、统一的3D图形API
，他们称之为Fahrenheit Project。这个项目是谁构思出来的，微软是如何说服SGI的，
现在已经无据可查。总之，按照当时的承诺，这个项目将在1999年或2000年推出实质产
品。看到几年来拉锯般的3D API之战终于要结束了，合作时代即将到来，几乎所有人都
兴奋不已。和平万岁！未来属于Fahrenheit！
战争结束，合作开始，SGI以满腔热情投入了Fahrenheit的开发之中，不但不再全力支持
OpenGL了，而且连自己的起家之本——基于MIPS的图形工作站，也甩掉一边。公允的说
，SGI的动机也不是那么单纯。对他们来说，MIPS图形工作站的衰亡史不可避免的，这一
点十分清楚。普通Wintel PC很快就会让高端图形工作站变成昂贵的废物。那么如何在P
C市场重现荣光呢？Fahrenheit项目毫无疑问是一个很好的切入点，跟PC软件领域的霸主
合作，使得SGI有机会进入这个超级庞大的市场，并掌握3D图形API的标准，这种好事，
当然不可错过！
问题在于，SGI看错了微软。微软岂能轻易放弃自己在3D领域好不容易获得的霸权，拱手
把半壁江山让与SGI呢？到1999年年中的时候，情形已经非常明显，微软并没有遵守去年
许下的诺言，事实上，微软除了派去几个专家参与制定Fahrenheit标准文档，做做表面
文章之外，根本没有投入开发力量，从而把具体工作一口气全甩给SGI去做，让对手不再
有足够资源投入到OpenGL上。同时，微软自己则继续将大笔资源倾注到DirectX的下一个
版本——也就是日后打赢关键一仗的主力军——DirectX 7.0上。不但如此，微软还使出
对付Borland和其它对手的老招数——挖角，不断以高官厚禄引诱SGI的顶级专家们。这
样的搞法，Fahrenheit能成功才是见了鬼了。
一来二去，全世界都明白了，SGI被忽悠了！不过为时已晚。2000年，DirectX 7.0问世
，一时间横扫3D图形市场。而传说中的Fahrenheit呢？则还只是停留在概念上的东西。
Fahrenheit总架构师David Blythe被微软成功挖角。如今，这个当年OpenGL领域数一数
二的顶级大师已经摇身一变成为DirectX 10的主设计师和Windows Presentation Frame
work的主要设计者之一。好一个Fahrenheit项目！让微软人财两得，而SGI不单是赔了夫
人又折兵，更失去了广大OpenGL社群的尊敬，不可不谓惨。
打输这一仗，SGI算是把老底和老脸都输光了。自那以后，SGI每况愈下，直到2006年，
终于难以支撑，向法院申请破产。一代高科技传奇，竟落得这般田地。
好在毕竟技术底子雄厚，在2007年，SGI成功地经历了一次重组。重组后的SGI，变成了
一个超级计算机、服务器集群和存储的系统厂商，跟图形已经基本没有关系了。不知道
如今SGI的人看到公司名字里的“G”，鼻子会不会酸呢？
好在OpenGL并没有因为SGI的沉沦而完蛋，相反，失去了商业巨头的支撑和控制，OpenG
L反倒真正成了开放的API，获得整个产业的支持。
4．凤凰涅磐
进入21世纪之后，图形软件市场发生了有趣的变革。首先，由于Web的大发展，微软在桌
面操作系统上一统天下的局面出现了松动。如今，人们开发一个桌面应用程序必须考虑
在Windows和Mac，甚至还有Linux三个平台上的可移植性，这就使得OpenGL的标准和开放
性成为一个重大的优势。其次，图形硬件市场实现了整合，nVidia和ATI成为GPU市场的
领袖，它们具有足够的财力和技术实力，可以按照自己的意愿对OpenGL提供第一流的支
持。第三，更重要的变革在于，PC已经不再是唯一的3D图形应用平台，智能家电、游戏
机、手机、PDA、车载计算机、工业设备、机器人等都成为新的图形应用平台。在这些平
台上，OpenGL是独一无二的首选方案。微软不但是后来者，而且恰恰因为微软在PC软件
领域的巨大成功，从而引起整个产业对它四面设防，从而使它很难取得大的成功。
2002年，OpenGL 1.4完成，使OpenGL在固定管线技术上达到了最高峰。2004年，划时代
的OpenGL 2.0推出，引入了GLSL，允许开发者使用可编程管线功能，从而使OpenGL登上
了现代图形硬件发展的快车。2006年8月，OpenGL 2.1发布，成为当前主流的OpenGL版本
。
凤凰涅磐的时刻即将到来。按计划，OpenGL 3.0将于2008年推出。这个新的标准在保留
对传统API支持的前提下，从头开始全新设计，提出了更先进的图形概念和对象模型，从
而走到了图形编程的最前沿。
此外，更令人兴奋的或许是OpenGL ES。这个专供嵌入式系统使用的OpenGL“精简版”如
今已经是手机、PDA、车载设备等嵌入式平台上的标准图形API。只要想想手机的用户量
，我们就不难憧憬OpenGL ES的光明灿烂的前景。给所有人以希望，这就是开放的伟大之
处。
在以后的日子里，我们大概不会再见到十年前那样激烈的API战争了，因为开放已经成为
我们每个人的共识。但是，这段历史却不应该被遗忘。正如马克吐温所说，历史不会简
单的重复，而是会变奏式的重复。我们应该保持警惕，珍视开放和自由带给每个人的价
值。
