c++圣战篇.txt

c++圣战 作者 台湾李维 介绍了c++语言的发展和编译工具的竞争历史

最高档的Symantec C/C++，希望我除了为Borland写C/C++的文章之外，也能够为Symantec 
C/C++写一些东西，我想这就是做为写技术文章的一个好处之一，那就是可以拿到许多最Hot
的开发工具。我还记得在当时安装Symantec C/C++之后，的确被它的整合发展环境吸引
的说不出话来，因为实在是太棒了，Borland C/C++和Visual C/C++的整合发展环境和
Symantec C/C++的整合发展环境比较起来，立刻的就变成索然无味，平凡无奇了，到现在我
仍然必须竖起大拇指对Symantec C/C++的整合发展环境说声『讚』。我想Eugene Wang
在这么短的时间内把Symantec C/C++打造的好此之好，除了证明他的不凡功力之外，也有向
Philippe Kahn示警的意思。证明Philippe Kahn让他离开Borland是错误的决定。我之所以 
如此说是因为其时Symantec C/C++最喜欢点名挑战的对象便是Borland C/C++了。对我的
感觉而言，Symantec C/C++就像是一个技艺精良，又装备华丽的C/C++军团。 

Watcom C/C++的发展史 

真是非常有趣的是，Watcom C/C++走的路子和Symantec C/C++几乎是完全相反的。当时出品
WatcomC/C++编译器的是一家加拿大的小公司，不过这家公司却对最佳化编译器有深入的研
究。当时Watcom C/C++是以在DOS下能够产生最好的最佳化程序码闻名於世的，在其时有许
多写游戏和DOS Extender的厂商都是指名要使用Watcom C/C++，因为不论是Borland C/C++
或是Visual C/C++产生的最佳化程序码都比WatcomC/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小组
中研发除错工具.当时Bor-land的Turbo Debugger是DOS下最强的除错工具，即使是Microsoft
也无法推出能够和TurboDebugger抗衡的除错工具。Matt在这个小组中吸收了大量的知识，
并且快速的成为这个领域的专家。后来Turbo Debugger小组的部份成员被Microsoft挖走，
让Microsoft掌握了Borland的核心除错技术，以致后来也能够推出不错的除错工具。而Matt
也出走到NuMega公司成为开发SoftIce，Bounds Checker的关键人物。写到这里还是不禁
要佩服Borland，因为当今许多名满天下的重量级软件工程师都是由Borland培养出来的。 

在Watcom C/C++於DOS市场佔稳了脚步之后，由於Window已经逐渐成为市场的主流，DOS势必
将被逐渐淘汰出局，因此WatcomC/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++开
发工具之一。稍后WatcomC/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，就可以在其他地方和Micro-soft以及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的朋友，也可以从下图和程序代码中观察一下当时的技术以及设计的概念。 

基本上我现在看这些图形架构，会发现它们并没有落后现在太多，可见当时设计 
者的功力(Carl Quinn Again)。 
// 
// Insert an OLE object into the view 
// 
void TOleWindow::CmEditInsertObject() 
{ 
001 PRECONDITION(OcView); 
002 TOcInitInfo initInfo(OcView); 
003 if (OcApp->Browse(initInfo)) { 
004 TRect rect; 
005 GetInsertPosition(rect); 
006 SetSelection(new TOcPart(*GetOcDoc(), initInfo, rect)); 
007 OcView->Rename(); 
008 InvalidatePart(invView); 
} 
} 
程序1 OWL的TOleWindow支持OLE插入对象之成员函数 
// 
// Handle left double-click message 
// 
void TOleWindow::EvLButtonDblClk(uint modKeys, TPoint& point) 
{ 
PRECONDITION(GetOcDoc() && GetOcView()); 
TOleClientDC dc(*this); 
dc.DPtoLP(&point); 
TOcPart* p = GetOcDoc()->GetParts().Locate(point); 
if (modKeys & MK_CONTROL) { 
if (p) 
p->Open(true); // Ctrl key forces open editing 
} 
else { 
SetSelection(p); 
if (p && p == GetOcView()->GetActivePart()) { // resync the active flag 
p->Activate(false); 
} 
GetOcView()->ActivatePart(p); // In-place activation 
} 
} 
程序2 OWL的TOleWindow支持左键双击之成员函数