主题：【文摘】C/C++圣战！ -- aircobra

Watcom C/C++的发展史

真是非常有趣的是，Watcom C/C++走的路子和Symantec C/C++几乎是完全相反的。

当时出品Watcom C/C++编译器的是一家加拿大的小公司，不过这家公司却对最佳化

编译器有深入的研究。当时Watcom C/C++是以在DOS下能够产生最好的最佳化程序

代码闻名于世的，在其时有许多写游戏和DOS Extender的厂商都是指名要使用

Watcom C/C++，因为不论是Borland C/C++或是Visual C/C++产生的最佳化程序代

码都比Watcom C/C++的最佳化程序代码差上一截。再加入当时最有名的DOS

Extender厂商PharLap公司也是使用Watcom C/C++，因此Watcom C/C++在专业的

C/C++程序员以及系统程序员心中是第一品牌的C/C++开发工具。

不知道还有多人记得PharLap这家公司，或是有没有人记得Andrew Schulman这位伟

大的软件技术人员。当时Andrew Schulman的Undocumented Windows一书红遍了半

边天，也惹得Microsoft要告Andrew Schulman。而Andrew Schulman便是PharLap公

司的首席工程师，也是当时最著名的『The ANDREW SCHULMAN Programming

Series』的总监，例如当时由Matt Pietrek撰写的Windows Internals也是轰动一

时的巨著。而PharLap公司是当时出版DOS Extender软件最成功的软件公司。

谈到Matt Pietrek，熟悉Window Programming的人应该很少有不知这位大师级人物

的。Matt长期在Microsoft System Journal撰写Under The Hood专栏，专门写一些

深入系统的程序设计技术，在数年前便和Andrew Schulman，David Maxey成为

Widow System Programming的三大巨头之一。Matt也是著名的Window除错工具

SoftIce，BoundsChecker的主要研发工程师。Matt本身也是从Borland出道的，当

Matt初至Borland工作时便是在Turbo Debugger小组中研发除错工具。当时

Borland的Turbo Debugger是DOS下最强的除错工具，即使是Microsoft也无法推出

能够和Turbo Debugger抗衡的除错工具。Matt在这个小组中吸收了大量的知识，并

且快速的成为这个领域的专家。后来Turbo Debugger小组的部份成员被Microsoft

挖走，让Microsoft掌握了Borland的核心除错技术，以致后来也能够推出不错的除

错工具。而Matt也出走到NuMega公司成为开发SoftIce，Bounds Checker的关键人

物。写到这里还是不禁要佩服Borland，因为当今许多名满天下的重量级软件工程

师都是由Borland培养出来的。

在Watcom C/C++于DOS市场占稳了脚步之后，由于Window已经逐渐成为市场的主流

，DOS势必将被逐渐淘汰出局，因此Watcom C/C++要继续的生存下去，也一定要推

出Window平台的C/C++开发工具。大约也是在1993，1994年左右Watcom终于推出第

一个Window的开发工具。

不过当时Watcom C/C++在Window推出的C/C++开发工具实在是平凡不已，其整合发

展环境和另外三个对手比较起来简直像是远古的产品，一点特色都没有，不过

Watcom C/C++仍然是以它的最佳化编译器做为号召。因此在当时发生了一个非常有

趣的现象，那就是许多软件公司会同时买Borland C/C++，或是Visual C/C++，

Symantec C/C++之一，再搭配一套Watcom C/C++。在开发应用系统时使用其它三套

开发工具之一，最后要出货时再使用Watcom C/C++来编译以产生最佳的程序代码。

在Watcom C/C++推出了Window平台的开发工具之后，仍然吸引了一群使用者，虽然

Watcom C/C++的市场比起其它的三家来说是最小的，但是也在一方撑起了一片天，

成为四大C/C++开发工具之一。稍后Watcom C/C++被Sybase并购，并且成为后来

Sybase的Optima++的前身。

对我的感觉而言，Watcom C/C++就像是一个穿著朴素，但是却拥有最佳训练的白色

C/C++军团。

关键的时刻-MFC Or Not

在Symantec C/C++和Watcom C/C++逐渐的站稳了脚步之后，四大编译器决战的时刻

也逐渐逼近了。在1994年未的决战之前，Symantec和Watcom同时面对了一个非常严

厉的考验，那就是C/C++ Framework的选择。

虽然Symantec和Watcom都以各自的特色占得了市场，不过在当时对于一个C/C++开

发工具来说，最重要的因素之一就是C/C++ Framework。因此Symantec和Watcom也

都必须提供使用者一套C/C++ Framework。不过这对于Symantec和Watcom都是一个

难以解决的问题，因为当时的C/C++ Framework已由Borland的OWL和Microsoft的

MFC所占领，如果要自己发展新的C/C++ Framework，那么Symantec和Watcom并没有

如此雄厚的资源，也无法在短时间之内完成。因此Symantec和Watcom必须下一个决

定到底是要使用MFC或是OWL做为它们的开发工具C/C++ Framework。

在1993年初Symantec和Watcom分别和Microsoft签约License MFC做为它们的开发工

具的C/C++ Framework。至此大势以定，在C/C++ Framework的市场已经形成三家夹

击一家的形式。当时许多人便预估Borland将成为输家，因为市场已经成为一面倒

，MFC看起来已经是胜券在握了。在当时于Borland的内部也展开了激烈的辩论，讨

论是否也要License MFC做为C/C++的Framework，停止继续开发OWL。不过后来

Borland还是决定继续开发OWL，而不使用MFC，因为Borland的C/C++技术小组认为

MFC不论是在架构上或是设计上都比不上OWL。而且由于Visual C/C++在当时对于

C/C++的标准支持不如Borland C/C++，因此在MFC内部使用了大量的Macro以及不标

准的语法，因此如果Borland C/C++要使用MFC，那么还需要修改编译器来编译MFC

。

对于这一点我认为Borland还是做了一个正确的决定，因为如果当时Borland也

License MFC，那么不但在气势上便输了一截，而且当MFC的发展是完全掌握在

Microsoft的手里，那么就等于脖子是掐在别人的手里，动弹不得了。可惜的是

Symantec和Watcom并没有看清这一点，以为有了和Microsoft一样的Framework，就

可以在其它地方和Microsoft以及Borland一决雌雄，Symantec和Watcom却没有想就

是这一点决定让后来的决战一败涂地，终究完全推出PC的C/C++开发工具市场。

时序到了1994年未，C/C++开发工具的四大天王决战的日子终于愈来愈近了。

OLE的搅局

不知道是时运不济或是Microsoft的刻意如此，在1994年Borland C/C++和Visual

C/C++决战的前夕，Microsoft推出了OLE(Object Linking And Embedding)技术。

OLE是Microsoft为了对抗Apple的文件技术以及IBM OS2的Workplace和文件技术应

运而生的。OLE可以让Window平台的文件能够内嵌在不同的应用程序中并且能够让

文件在应用程序中被即地编辑(In-Place Editing)。说实在的，Microsoft的OLE和

Apple以及IBM的技术比较起来实在是差多了，OLE在稍后也被证明是失败的技术，

不过不管是Microsoft的OLE或是Apple/IBM的文件技术也都是失败的技术，都没有

造成巨大的成功。虽然这些文件技术都没有成功，但是OLE却足以成为Borland，

Symantec和Watcom失败的重要因素。

我还记得当时OLE似乎成为了一个令人趋之若鹜的时髦功能，因为Word的文件能够

内嵌在Excel之中，并且可以点选此Word文件，应用程序又立刻成为Word来编辑它

，实在是令人觉得非常的神奇。不过在其时所有的软件厂商中只有Microsoft的应

用程序有如此的功能，其它的厂商例如Lotus，WordPerfect等都无法实作出这种功

能。这造成了不公平的竞争，因为OLE技术是由操作系统厂商Microsoft推出的，但

是却让它的应用程序部门同步拥有这种技术，而其它的软件厂商都无法获得第一手

的OLE技术来实作，这是为什么当时其它的软件厂商如此火大的原因。

虽然后来其它的软件公司在取得了OLE的技术信息之后也推出了具备OLE功能的应用

程序，但是毕竟是慢了Microsoft许久，市场也流失了许多。不过我也很奇怪的是

在当时内建OLE功能的应用程序之中，几乎所有的软件厂商推出的应用程序在激活

数个应用程序而且使用OLE之后，就非常容易的当掉，只有Microsoft的应用程序不

太会发生这种情形，因此许多人便认为Microsoft有隐瞒一些技术没有让其它的厂

商知道。

由于OLE是如此的复杂，因此Borland无法立刻在OWL之中实作出这种功能，于是就

造成了市场上负面的影响。至于Symantec和Watcom虽然是License MFC，但是在其

时它们License的是MFC 1.x的版本，Microsoft并没有把OLE实作在MFC 1.x中，而

是在实作在MFC 2.0之中。在MFC 2.0推出时最重要的功能就是Microsoft加入了

20000多行支持OLE的程序代码，但是MFC 2.0却仅限于Visual C/C++使用，就是这

关键的一点让其它三家厂商吃了亏。

对于OLE这个关键技术的影响，Borland是深知在心的，因此在计划在Borland

C/C++ 4.5的OWL 2.5中支持OLE。当时Borland推出的解决方案便是OCF(Object

Component Framework)。

Borland当初在设计OCF时有几个重大的目标。这些目标包括了: 一、如何能够使得

OLE琐碎 、复杂的接口能够单纯化; 第二、如何能够使得OLE在窗口环境下写程序

的思考方式 一致化--即使用「事件驱动」的方法。第三、如何能够在微软占尽天

时、地利(未必人和) 的情况下使得Borland的产品具备OLE的功能。第四、如何能

够让大多数C++的程序员都能够享受OLE的功能而不局限于OWL的程序员。由于上述

的设计目标, 而造就了典雅而具有弹 性的OCF。由于OCF本身是一完整而独立的

Framework, 因此它可适用于各种应用程序发展Framework。

不晓得各位使用过Borland C/C++的朋友们是否还依稀记得下图OCF的架构图之一，

以及下面的OCF范例程序代码，这些可是我把1994年写的文章挖出来之后找到的，

真是令我感慨，也回想起了当时的情景，也让各位回忆一下OWL和OCF。对于不熟悉

OWL和OCF的朋友，也可以从下图和程序代码中观察一下当时的技术以及设计的概念

。

（待续）