C/C++圣战李维

congfeng02

浏览: 200049 次
性别:
来自: 北京

最近访客更多访客>>

u012363178

心杀心

2782506871

lichdb

博主相关

博客

微博

相册

留言

关于我

文章分类

全部博客 (183)

社区版块

存档分类

2009-07 ( 7)
2009-06 ( 111)
2009-05 ( 59)
更多存档...

C#C++C Borland MFC

C/C++圣战李维

Borland C/C++的反击

当Microsoft Visual C++ 1.0 在C/C++开发工具市场获得了空前成果的之后，Borland 才从Borland C/C++ 3.1的胜利梦中惊醒，思考如何面对Visual C++的猛烈功势。事实上当时的Borland如果脑袋清醒一点，好好看清当时C/C++开发工具的市场，那么Borland应该会发现虽然 Visual C++ 经过2年多的整军经武，实力已经大不前。不过Borland C/C++ 3.1仍然在许多方面可以和Visual C++一争长短的。例如其时Visual C++的最佳化编译器仍然落后Borland C/C++ 3.1一些，第2点是MFC仍然没有完整的封装Window API，而且MFC是以较低阶的方式封装Window API，并不是很对象导向，也不是很容易使用。事实上以我的观点来看，我认为就是因为 MFC 不好用，因此 Visual C++ 才需要在整合发展环境中提供以可视化方式产生 MFC 程序代码的功能，第3是Visual C++当时并没有很好的封装数据结构的Container Class，而Borland C/C++却有非常好用的BIDS类别库。第4，也是最重要的，Borland C/C++ 3.1仍然拥有绝大的市场，而且几乎所有的外围公用程序，Shareware等都是使用Borland C/C++ 3.1开发的。因此如果Borland不要急，好好的开发下一代的C/C++开发工具，即使Microsoft Visual C++能够掠夺一些市场占有率，但是如果下一代的Borland C/C++能够像Borland C/C++ 3.0一样立刻拉开和Visual C/C++的距离，那么Borland在C/C++市场仍将拥有王者的地位。

可惜的是，也许Philippe Kahn在和Microsoft的FoxPro For Window一役中被吓到了，因此急于在Visual C/C++ 1.0之后立刻推出新的Borland C/C++以扳回颜面。但是Philippe Kahn忘了，在这段时间之内Borland失去了许多的人材，Eugene Wang也离开了，更重要的是在过去近3年的时间之内，Borland几乎没有持续的开发下一代的Borland C/C++，在短时间之内如何能够仓促的推出产品呢?

但是Philippe Kahn可管不了这么多了，急忙找来了Carl Quinn等人便要求立刻开发出下一代的Borland C/C++，于是Borland C/C++ 4.0就在这么鸭子赶上架下匆忙的开发了。Borland在开发Borland C/C++ 4.0时犯了许多的大忌。首先在这么短的时间内Borland决定全新发展整合发展环境，第2是把OWL完全重写，第3是大幅修改最佳化编译器，第4是整合当时棘手的VBX，Borland居然让16位和32位的程序能够同时使用16位，丑陋的VBX。
上面所说的每一项都是大工程，Borland早应该在Borland C/C++ 3.1之后便开始做这些工作，现在要在短短的一年多的时间内重新开发一个这么复杂的C/C++开发工具，几乎是不可能的工作。但是在Philippe Kahn的要求之下，这些Borland的工程师还是硬着头皮做了出来。

不过我必须很沈痛的说，当时我在Beta测试Borland C/C++ 4.0时便和台湾Borland的人说，如果Borland仓促推出Borland C/C++ 4.0的话，那么不但不会对Visual C++产生任何的影响，反而是自杀的行为，因为臭虫实在太多了，整个整合发展环境的反应也很缓慢，它的最佳化编译器更是笑话，错误百出，真是像当时恶名昭彰的Microsoft C 4.0一样。我还开玩笑的说，是不是因为Microsoft从Borland挖了大量的Borland C/C++人才，因此好胜的Philippe Kahn也还以颜色，从Microsoft反挖Microsoft C的人，却不幸的挖到了Microsoft C 4.0的人。

但是很显然的Borland并没有听到我的，或是其它Beta测试人的心声，在Visual C++ 1.0推出后的1年多，Borland C/C++ 3.1后的4年，Borland终于推出了新一代的Borland C/++ 4.0，这个肩负和Visual C++ 1.0对抗的C/C++开发工具。
在Borland C/C++ 4.0刚推出之际，Borland确实为4.0做了极大的造势，我记得在当时所有重要的计算机杂志中，例如Byte，PC Magazine，Dr. Bob等，都有4.0整页的广告。这个广告的内容是以一个巨大的猫头鹰为主，再搭配蓝色底色系的Borland C/C++ 4.0为主，选用巨大的猫头鹰当然是因为OWL的原因，只可惜我现在找不到那幅广告了。

痛失江山的Borland C/C++ 4.0

当时Borland使用了如下的广告用词 :

『Visual Is Only A Facial Facade』

来讽刺Visual C/C++只提供了产生MFC程序代码的基本精灵，而Borland除了也提供相对应的AppExpert精灵能够提供类似的功能以产生使用者选择的OWL程序代码之外，Borland C/C++ 4.0的整合发展环境还提供了可视化的3面版窗口，能够让程序员完整的掌握整个项目的情形。
例如在下图中便是当初令人眼睛为之一亮的AppExpert：

还记得Borland提供的AppExpert吗?

下图则是当时Borland C/C++的注册商标，3面版窗口开发环境。看到下图又令我想起当初使用C/C++写程序的日子，下方程式码面版清楚的显示了我在1995年于鼎新工作时写的智能型Window排程系统，时间过得是真快啊。

令人怀念的Borland C/C++ 4.0整合发展环境，三面版窗口

当时Borland C/C++ 4.0的3面版整合发展环境真是开创了一个新的局面，因为这个整合发展环境允许程序员知道每一个应用程序定义的窗口讯息，并且能够立刻的显示在下方的程序代码窗口中，的确是非常的方便，也比当时Visual C/C++的整合发展环境来得先进。再加入Borland较为先进的编译器技术和架构更好的C/C++ Framework-OWL，照理说Borland C/C++ 4.0应该会获得极大的胜利，那么为什么最后会以失败收场呢？

没错，在Borland C/C++ 4.0刚推出之后订单的确如雪片般飞来，销售情形非常好，因为这毕竟是Borland在睽违了数年之后的大作，许多Borland的用户都迫不及待的升级，就像当初我也是拚命的要求台湾Borland要第一个给我Borland C/C++ 4.0。但是在Borland C/C++ 4.0推出一段时间之后，市场的反应就急速的冷却下来，因为各种负面的批评不断涌现，这主要的原因当然是因为Borland C/C++ 4.0的质量实在不好，就像前面我在Beta测试时说的，由于Borland太急于推出4.0，因此并没有在最后阶段修正许多的错误，又没有经过最后系统微调的工作，又太大胆的加入太多先进的技术，造成了整个产品的不稳定，而造成了大错。下面几点应该是造成当初Borland C/C++ 4.0滑铁卢的主要原因：

*整合发展环境方面-臭虫太多，容易当掉而且反应速度缓慢
*编译器方面-最佳化玩得过火，产生错误的编译程序代码
*OWL方面-采用全新的多重继承架构，虽然是正确的做法，却和Borland C/C++ 3.1中的OWL不兼容，造成许多程序员无法升级C/C++项目
*VBX方面-大胆的采用在16/32位都能使用VBX的技术，造成一些VBX无法顺利的在Borland C/C++ 4.0中使用

我想其中最可惜的就是OWL了，因为OWL 2.0在各方面都有一流的表现，实在是MFC强劲的竞争对手，OWL 2.0也获得了各方一致的肯定和称赞。无奈的是由于OWL 2.0做了从基本架构的改变，这是为了解决当初OWL 1.x使用了不标准的C/C++编译器技术的问题，但是这造成了原本Borland C/C++程序员极大的困扰，因为升级不易。对于新的C/C++使用者来说又因为Borland C/C++ 4.0本身不稳定的因素而却步，因此造成了OWL 2.0叫好不叫座的下场，真是可惜了 OWL小组的努力。

我记得当时我的项目有使用FarPoint的SpreadSheet VBX组件，由于一直无法顺利的在Borland C/C++ 4.0中使用，并且会造成应用程序的当掉，最后追踪执行程序代码却发现应该是Borland C/C++ 4.0的问题，因此最后只好在咒骂中放弃使用4.0，而回到Borland C/C++ 3.1。我当时想，对于我这个长期使用Borland产品的人都无法忍受4.0的质量，其它的程序员又怎能使用这个产品。我想这就是为什么后来4.0全面溃败的原因，因为Borland推出了根本不堪用的产品。

在我于Borland工作的时间，有一次在新加坡和现在Borland开发者关系部门的副总裁David Intersimone谈起这一段往事，David也很感慨这一段往事，David直呼『We screwed it up!』，『It’s a mess』。David并且说当时整个Borland C/C++开发小组都很混乱，和以往Borland C/C++ 3.0/3.1的开发小组比起来实在是差太多了，除了因为一些重要的人物相继离开Borland，而且Microsoft也挖走一大票人之外，Philippe Kahn的直接介入，造成人事不和也有很大的原因。

David I.说『We Screwed it up!』，『It’s a mess』

在Borland C/C++ 4.0快速失利之后，Borland也体认到问题的严重性，因此立刻的着手开发Borland C/++ 4.0的Patch，当时是称为Service Pack。但是在稍后的4.01版中并没有完全的解决问题，一直要到4.02才稍为解决一些严重的问题，无奈时不我予，拖的时间太长，市场已经起了巨大的变化。

在Borland C/C++ 4.0失利之后，立刻造成了严重的后果，首先是Borland C/C++的市场大量且快速的流失，让Visual C/C++快速的成长。第二点是当初Borland C/C++ 3.1在公用程序市场打下的江山也拱手让人，原本许多硬件厂商也使用Borland C/C++ 3.0/3.1撰写驱动程序也开始转换到Visual C/C++，而严重的是在应用程序市场方面由于4.0的质量以及稍后OLE的关系，也开始大量的开始转为使用Visual C/C++来撰写应用程序。
Borland在3个主要的应用市场接连败退，C/C++的江山注定将易主，其势已不可挽。

Borland C/C++，Visual C/C++，Watcom C/C++和Symantec C/C++的缠斗

自Borland C/C++ 4.0一役大败之后，Borland在C/C++市场上建筑的巨大堡垒似乎再也不是牢不可破了。Visual C/C++固然在不断的接收Borland C/C++失去的市场，此时在C/C++市场上也加入了另外两个坚强的对手，那就是Symantec C/C++和Watcom C/C++。

Symantec C/C++的发展史

说起这两个对手也都是个个来头不小，先说Symantec C/C++吧。它的Think C/C++在Macintosh上便是非常有名的编译器，因此早在C/C++领域便有深厚的基础。在Symantec并购了PC上第一个C/C++编译器Zortech C/C++之后，Symantec进入PC的开发工具市场也是箭在弦上了，只可惜的是其时Symantec还未找到一个在PC上有丰富经验的开发工具领导者。
也许是上天注定要引起稍后的C/C++编译器大战吧，此时Borland C/C++ 3.1的幕后支柱Eugene Wang刚好和Philippe Kahn闹翻，离开了Borland。Symantec见此时不可失，立刻重金延揽Eugene Wang到Symantec，为Symantec推出第一个C/C++开发工具。在1993年左右吧，Symantec C/C++在Eugene Wang的掌舵之下推出了第一个Symantec C/C++版本，立刻便获得了市场的好评。自此之后Symantec C/C++军心大振，不断的继续改善，也逐渐的获得了不小的C/C++市场，隐然成为可以对抗Borland C/C++，Visual C/C++的另一山头。当时Symantec C/C++是以最华丽，先进的整合发展环境获得市场的高度认同，在C/C++编译器最佳化方面的表现也不会输给其它的编译器。

当时我在RUN!PC上写C/C++的文章，因此Symantec 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++几乎是完全相反的。当时出品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的朋友，也可以从下图和程序代码中观察一下当时的技术以及设计的概念。基本上我现在看这些图形架构，会发现它们并没有落后现在太多，可见当时设计者的功力(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支持左键双击之成员函数

虽然Borland及时的在OWL 2.5中加入了OLE的支持，无奈Microsoft随后又在OLE中加入了许多其它的功能，因此让OCF并无法完整的支持OLE所有的功能，Borland又无法不断的延后Borland C/C++的推出，因此在1994年未，Borland终于推出了决战的4.5版本。

C/C++开发工具的最后圣战

『虽然已经过去了许久的时间，但是我仍然忘不了那场最惨烈的战役!』

1994年未, 1995初Borland在痛定思痛之后，终于清除了Borland C/C++ 4.0中所有的问题，也开发出了自Borland C/C++ 3.1以来最稳定，最快速的Borland C/C++ 4.5的版本，准备和Microsoft决一死战。我还记得当时在书籍市场中许多有关Borland C/C++和Microsoft C/C++的书籍都是使用十字军的封面，而Borland C/C++的系列丛书都是以蓝色为色系，而Microsoft的则是以红色为色系，仿佛两大军团终将决战似的。

C/C++四大天王决战一役的Borland主将-Borland C/++ 4.5

不过这次的战役不光是Borland的蓝军和Microsoft的红军相对抗，在Symantec的华丽军团经过了经军经武，Watcom的白色劲旅枕戈待旦，而且都从Microsoft License了MFC之后，蓝，红，花，白四大军团决战的日子终于到了。首先当Symantec和Watcom分别取得了MFC之后，Symantec便推出了C/C++ 7.x的版本，和Watcom C/C++混战了起来。两个使用系出同门的C/C++ Framework产品战得不亦乐乎，随后Borland C/C++ 4.5和Visual C/C++的新版本也加入了这场最重要的决战。但是让Symantec和Watcom C/C++大吃一惊的是Microsoft使用的MFC居然比它们的版本高出了一个版本(1.x对2.x)，而且新版本的MFC包含了完整的OLE支持能力。而Borland虽然也有OCF，但是仍然不敌新版MFC中的OLE能力。由于当时几乎所有的应用程序都需要支持OLE，但是却只有使用Visual C/C++最新的版本才能够开发完整OLE能力的应用程序，因此不管OLE到底有没有用，反正先加入再说。因此市场上的情势很快的就发生了巨大的变化，几乎大部份的应用程序开发因为OLE的原因都选择使用Visual C/C++，Symantec和Watcom军团很快的就败阵下来。

至于Borland C/C++ 4.5虽然是一流的产品，如果没有OLE的因素，Visual C/C++新版本真的并没有比4.5好。虽然4.5也有OCF，但是在市场上只有Borland和Novell，WordPerfect选择使用OCF，在和Microsoft的Visual C/C++经过将近一年的缠斗之后，其它大部份的厂商都选择了Microsoft的MFC 2.x版，真是形势比人强。基本上OCF的架构真的是个好东西，只是OCF无法完整的支持OLE，因为OLE的发展是掌握在Microsoft手中，因此虽然OCF的架构良好，终究在功能上不及对手。Microsoft结合操作系统，开发工具和应用程序的手段真是无往不利。击败Lotus，Borland是如此，歼灭Netscape也是如此。

对于Symantec和Watcom来说，这场战役就如同『长平之战』，秦军坑杀40多万赵军一样。杀得Symantec和Watcom全军覆没，大败而归，至此Symantec弃受PC的C/C++开发工具市场，转而开始研发Java开发工具，进而在稍后推出了著名的Visual Cafe, 至于Eugene Wang则离开了Symantec，自此也离开了PC开发工具的领域。

而Watcom则是更为凄惨，整个公司在DOS的市场逐渐式微，而Window平台的开发工具又大败而归，两头落空。不久之后Watcom便被新兴而起的Sybase并购，从此消失于竞争激烈的市场。

归纳Symantec和Watcom失败的原因是C/C++的Framework MFC掌握在Microsoft手中，在决战时刻Microsoft居然手握比Symantec和Watcom更新的MFC利器，而且在Visual C/C++精进最佳化的技术并且改善整合发展环境之后，Symantec和Watcom诉求的重点功能完全被Microsoft封死。因此在产品，技术，市场和气势上完全不如对手的情形下，自然只能任人宰割了。

对于Borland而言，虽然没有像Symantec和</s