第二章 C／C++的圣战"在惨烈的、大规模的C/C++战役中，注定只有最强者才能生存下来!"Borland C／C++的反击当Visual C++1.0在C/C++开发工具市场获得空前的成功之后，Borland才从Borland C/C++3.1的胜利梦中惊醒，思考如何面对Visual C++的猛烈攻势。

正在装载数据……

事实上，Borland如果脑袋清醒一点，好好看清当时C/C++开发工具的市场，那么Borland应该会发现虽然Visual C++经过两年多的整军经武，实力已经大胜以前。但是，Borland C/C++3.1在许多方面仍然是可以和Visual C++一争长短的。首先，当时Visual C++的最佳化编译器仍然落后Borland C/C++3.1；第二，MFC仍然没有完整地封装Windows API，而且MFC是以较低阶的方式封装Windows API的，面向对象做得并不好，也不是很容易使用。事实上以我的观点来看，正是因为MFC不好用，所以Visual C++才需要在集成开发环境中提供以可视化方式产生MFC程序代码的功能。第三是Visual C++当时并没有很好的封装数据结构的Container Class，而Borland C/C++却有非常好用的BIDS类别库。第四，也是最重要的，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 Windows一役中被吓着了，因此急于在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决定全新升级集成开发环境；第二是把OWL完全重写；第三是大幅修改最佳化编译器；第四是整合当时棘手的VBX，Borland居然让16位和32位的Windows程序同时使用16位的、丑陋的VBX。上面所说的每一项都是大工程。Borland早应该在Borland C/C++3.1之后便开始进行这些工作，现在要在短短的一年多时间内重新开发这么复杂的一个C/C++开发工具，几乎是不可能的。但是在Philippe Kahn的强力要求下，这些Borland的工程师还是硬着头皮做了出来。不过我必须很沉痛地说，当时在Borland C/C++4.0 Beta测试时，我便和台湾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/C++ 4.0，这个肩负和Visual C++1.0对抗的新一代C/C++开发工具。在Borland C/C++4.0刚推出之际，Borland确实为4.0做了极大的造势，我记得在当时所有重要的计算机杂志中，例如Byte、PC Magazine、Dr. Dobb's等，都有4.0整页的广告。这个广告的内容是以一个巨大的猫头鹰为主，再搭配蓝色底系的Borland C/C++4.0，选用巨大的猫头鹰当然是因为OWL的原因，只可惜我现在找不到那幅广告的画面了。当时Borland C/C++4.0使用了如下的广告用词：Visual Is Only A Facial Facade来讽刺Visual C/C++只提供了产生MFC程序代码的基本精灵，而Borland除了提供相对应的AppExpert精灵(能够提供类似的功能，以产生使用者选择的OWL程序代码)之外，Borland C/C++4.0的集成开发环境还提供了可视化的三面版窗口，能够让程序员完整地掌握整个项目的情形。下图便是当初令人眼睛为之一亮的AppExpert：下图则是当时Borland C/C++的注册商标，三面版窗口开发环境。看到此图又令我想起当初使用C/C++撰写程序的日子，下方程序页面清楚地显示了我1995年在鼎新工作时写的智能型Windows排程系统，时间过得真快啊。当时Borland C/C++4.0的三面版集成开发环境真正开创了一个新的局面，因为这个集成开发环境允许程序员知道每一个应用程序定义的窗口信息，并且能够立刻把它显示在下方的程序代码窗口中，的确是非常的方便，也比当时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的品质实在不好，就像前面我在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 l.x使用了不标准的C/C++编译器技术的问题，但是这造成了原来Borland C/C++3.x程序员极大的困扰，因为升级不易。对于新的C/C++使用者来说，又因为Borland C/C++4.0本身不稳定的因素而却步，因此造成了OWL 2.0叫好不叫座的下场，真是可惜了OWL小组的努力。还记得当时我的项目使用了FarPoint的SdivadSheet VBX组件，由于一直无法顺利地在Borland C/C++4.0中使用，并且会造成应用程序的当机，最后追踪执行程序代码却发现应该是Borland C/C++4.0的问题，因此最后只好在咒骂中放弃使用BorlandC/C++4.0，而回到Borland C/C++3.1。当时想，对于我这个长期使用Borland产品的人都无法忍受4.0的品质，其他的程序员又怎能使用这个产品呢？我想这就是为什么后来4.0全面溃败的原因，因为Borland推出了根本不堪使用的产品。我在Borland工作时，有一次在新加坡和现任Borland开发者关系部门副总裁的David Intersimone谈起这一段往事，David也很感慨，他直呼"We screwed it up!(我们把事情搞砸了)"，"It's a mess(那实在是一团混乱)"。David还说当时整个Borland C/C++开发小组都很混乱，和以往Borland C/C++3.0/3.1的开发小组比起来实在是差太多了。除了因为一些重要的人物相继离开Borland以及Microsoft也挖走一大票人之外，与Philippe Kahn的直接介入，造成人事不和也有很大的原因。在Borland C/C++4.0快速失利之后，Borland也认识到问题的严重性，因此立刻着手开发Borland C/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在三个主要的应用市场接连败退，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++和Watcom 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推出第一个Windows上的C/C++开发工具。1993年左右，在Eugene Wang的掌舵之下，Symantec推出了第一个Symantec C/C++版本，立刻便获得了市场的好评。自此之后Symantec C/C++军心大振，不断地继续改善，也逐渐获得了不小的C/C++市场，俨然成为可以对抗Borland C/C++、Visual C/C++的另一山头。当时Symantec C/C++是以最华丽、先进的集成开发环境获得了市场的高度认同，在C/C++编译器最佳化方面的表现也不输给其他的编译器。当时我正为《RUN!PC》撰写有关C/C++的文章，因此Symantec台湾分公司的人也和我联络过，并且送给我一套最高档的Symantec C/C++版本，希望我除了为Borland写C/C++的文章之外，也能够为Symantec C/C++写一些东西。我还记得，在当时安装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"的总监。而PharLap公司是当时出版DOS Extender软件最成功的软件公司。当时由Matt Pietrek撰写的Windows Internals也是轰动一时的巨著。谈到Matt Pietrek，熟悉Windows Programming的读者应该很少有不知这位大师级人物的。Matt长期在Microsoft System Journal撰写Under The Hood专栏，专门写一些深入系统的程序设计技术，在数年前便和Andrew Schulman、David Maxey成为Windows System Programming的三大巨头之一。Matt也是著名的Windows除错工具SoftIce、BoundsChecker的主要研发工程师。Matt本身是从Borland出道的，他初至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市场站稳了脚跟之后，由于Windows已经逐渐成为市场的主流，DOS势必将被逐渐淘汰出局，因此，Watcom C/C++如果要继续生存下去，也就-定要推出Windows平台的C/C++开发工具。大约是在1993、1994年左右，Watcom终于推出第一个Windows下的C/C++开发工具。不过，当时Watcom C/C++在Windows推出的C/C++开发工具实在是平淡无奇。其集成开发环境和另外三个对手比较起来简直像是远古的产品，-点特色都没有。不过Watcom C/C++仍然是以它的最佳化编译器作为号召。因此当时发生了一个非常有趣的现象，那就是许多软件公司会同时买Borland C/C++，或是Visual C/C++，Symantec C/C++之一，再搭配一套Watcom C/C++。在开发应用系统时使用其他三套开发工具之一，最后要出货时再使用Watcom C/C++来编译以产生最佳的程序代码。在Watcom C/C++推出了Windows平台的开发工具之后，也吸引了-群使用者。虽然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++逐渐站稳了脚跟之后，C/C++四大编译器决战的时刻也逐渐逼近了，一些其他出产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，例如ZApp和Zinc等，但是这些C/C++ Framework终究没有产生很大的影响。如果Symantec和Watcom要自己发展新的C/C++ Framework，那他们还没有如此雄厚的资源，也无法在短时间之内完成。因此Symantec和Watcom必须决定，到底是要使用Microsoft的MFC还是使用Borland的OWL来作为他们开发工具的C/C++ Framework。1993年初，Symantec和Watcom分别和Microsoft签约授权使用MFC作为他们的开发工具的C/C++ Framework，至此大局已定，在C/C++ Framework的市场已经形成三家夹击一家的形势。当时许多人便预测Borland会成为输家，因为市场已经成为一面倒的现象，MFC看起来已经是胜券在握了。当时，Borland的内部也展开了激烈的辩论，讨论是否也要授权使用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，那么还需要修改Borland的C/C++编译器来编译MFC。对于这一点，我认为Borland是做了一个正确的决定。因为，如果当时Borland也授权使用MFC，那么不但在气势上输了一截，而且，由于MFC的发展完全掌握在Microsoft的手里，采用MFC就等于脖子被掐在别人的手里，动弹不得。可惜的是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可以让Windows平台的文件内嵌在不同的应用程序中，并且能够让文件在应用程序中被即地编辑(In Place Editing)。说实在的，Microsoft的OLE和Apple以及IBM的技术比较起来实在是差多了，在稍后也被证明是失败的技术。不过，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虽然授权使用MFC，但是在其时它们授权使用的是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的OWL2.5中支持OLE。当时Borland推出的对应解决方案便是OCF(Object Component Framework)。Borland当初在设计OCF时有几个重大的目标，这些目标包括：第一、如何使OLE琐碎、复杂的接口单纯化。第二、如何使OLE在窗口环境下写程序的思考方式一致化--即使用"事件驱动"的方式来开发。第三、如何在微软占尽天时、地利(但未必人和)的情况下使Borland的产品具备OLE的功能。第四、如何让大多数C/C++的程序员都能够享受OLE的功能而不局限于OWL。由于上述的设计目标，从而造就了典雅而具有弹性的OCF。由于OCF本身是一完整而独立的Framework，因此它可适用于各种C/C++ Framework之中，包含了OWL、MFC以及ZApp/Zinc等Framework。不知道各位使用过Borland C/C++的朋友们是否还依稀记得下图所示的OCF架构图之一，以及下面的OCF范例程序代码？这些可是我把1994年写的文章挖出来之后找到的，真是令我感慨，不禁回想起了当时的情景，在此也让各位回忆一下OWL和OCF。对于不熟悉OWL和OCF的朋友，也可以从下图和程序代码中观察一下当时的技术以及设计的概念。我现在看这些图形架构，会发现基本上它们并没有落后现在太多，可见当时设计者的功力(当然又是Carl Quinn定义的佳作之一)。程序1 OWL的TOleWindow支持OLE插入对象的成员函数 // // Insert an OLE object into the view // void TOleWindow::CmEditInsertObject() { 001 divCONDITION(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); } } 程序2 OWL的TOleWindow支持左键双击的成员函数 // // Handle left double-click message // void TOleWindow::EvLButtonDblClk(uint modKeys, TPoint& point) { divCONDITION(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 } 虽然Borland及时地在OWL2.5中加入了OLE的支持，无奈Microsoft随后又在OLE中加入了许多其他的功能。因此让OCF还是无法完整地支持OLE所有的功能，Borland又无法不延后Borland C/C++的推出，因此直到l994年末，Borland才终于推出了决战性的Borland C/C++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的则是以红色为色系，仿佛两大军团终将决战似的。不过，这次的战役不仅仅是Borland的蓝军和Microsoft的红军相对抗。在Symantec的华丽军团经过了整军经武，Watcom的白色劲旅枕戈待旦，而且都从Microsoft授权使用了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居然比他们使用的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++新版本真的并不比Borland C/C++4.5好：虽然4.5也有OCF，但是在市场上只有Borland和Novell、WordPerfect选择使用OCF。在和Microsoft的Visual C/C++经过将近一年的缠斗之后，其他大部分的厂商都选择了Microsoft的MFC 2.x版，真是形势比人强。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的市场逐渐式微，而Windows平台的开发工具又大败而归，两头落空。不久之后，Watcom便被新兴而起的Sybase并购，从此在竞争激烈的开发工具市场中消失了。归纳Symantec和Watcom失败的原因，是因为C/C++的Framework MFC掌握在Microsoft手中，在决战时刻Microsoft居然手握比Symantec和Watcom更新的MFC利器，而且在Visual C/C++精进最佳化编译器技术并且改善集成开发环境之后，Symantec和Watcom诉求的重点功能完全被Microsoft封死。因此在产品、技术、市场和气势上完全不如对手的情形下，自然只能任人宰割了。对于Borland，虽然没有像Symantec和Watcom那么溃不成军，但也再次败下阵来。虽然平心而论Borland C/C++4.5的确是一个非常好的产品，无论在OWL、最佳化编译器、集成开发环境方面都有一流的表现。和Borland C/C++4.0比较起来简直犹如脱胎换骨一般，到现在Borland C/C++4.5仍然是我最喜欢的版本之一。但是无奈当初Borland C/C++4.0给人挥之不去的负面印象，以及无法完整支持当时如火如荼的OLE技术，因此还是在决战之中败了下来。好在蓝色的Borland大军毕竟是训练有素，虽然自此让Microsoft占据了超过50％的市场，成为C/C++开发工具的老大，但是Borland仍然掌握了超过30％的市场，稍做喘息，并且支撑Borland在各重要战役失败之后维持公司的运作，等待Delphi的浴火重生，再重新出发。经过这关键的一役之后，Microsoft终于清除了大部分的对手。对于Microsoft，程序语言开发工具的战争已经结束，这个市场注定将被Microsoft占据大部分的市场。在Microsoft手握操作系统、Office软件和开发工具三大获利市场之后，Microsoft也开始将矛头对准下两个竞争目标：关系数据库以及主从架构开发工具。在Microsoft正式进军这两个市场之后，当然也展开了连番的好戏，尤其是在主从架构开发工具方面又开启了VB、PowerBuilder、Gupta/Centura和Delphi的惊天动地大会战。另外一个意外开启的战争则是Microsoft在1995年和Netscape的浏览器大战。在C／C++最后一役之后，我认为开发工具的圣战已然结束，Borland也正式开始走下坡路。更严重的是我认为自此之后Borland不但丧失了C/C++的江山，也失去了对于C/C++开发工具的创意，这是我感到最遗憾的地方，到现在为止我仍然认为Borland尚未重拾当初在Borland C/C++3.0/3.1时代独领C/C++创意风骚的精神。也许，也许，要看看C/C++ For Kylix或是C++Builder的后继产品是否能够重新找回这个失去已久的精神，不再让大家失望了。永不成气候的C/C++开发工具：IBM VisualAge C/C++IBM在C/C++开发工具市场扮演的角色一直令人啼笑皆非，因为在C/C++编译器战争最激烈的时刻，IBM这个全球信息大厂却一直是缺席的。一直到了1995年之后，C/C++编译器市场大势已定后才慢慢地加入战局，推出VisualAge C/C++ 3.0，企图进攻此市场。但是此时市场早已由Microsoft的Visual C/C++称雄。IBM的VisualAge虽然能够以创新的可视化设计家定义对象之间的关系，但是在其他方面却乏善可陈，整个集成开发环境也缓慢如蜗牛，需要非常高的硬件配置才能够顺利运行，和Visual C/C++以及Borland C/C++等工具比较起来就像是恐龙一般，因此几乎没有在市场上引起任何的反应。在推出的VisualAge C/C++3.0并没有在PC的C/C++开发工具市场获得任何的明显成果之后，IBM又再次集中许多资源，开发下一代3.5版本，希望能够在此市场占有一定的比率。我知道IBM在VisualAge投注了大量的资源，因为从Beta版开始台湾的IBM便有人和我接触，希望我也在《RUN!PC》上为VisualAge C/C++3.5写些文章。因此在1996年的6月我写了一篇C/C++编译器的比较文章，下面的资料便是数年前当时还是Beta版的VisualAge 3.5和其他编译器的比较结果(见下页)。从图中的数据可以看到，其实VisualAge C/C++3.5的表现还不错，只是对于当时还在使用AMD DX4-100/32M RAM机器的我来说，实在是跑不动。后来台湾IBM负责VisualAge的产品经理请我吃饭，在此饭局中这位李经理同时请了贺元(后来成为资迅人的总裁)、薛晓岚(后来成为资迅人的副总裁)以及其他两位作者，希望大家在计算机杂志中继续为VisualAge C/C++3.5写写东西，一起Promote此产品。在这个饭局中我是第一次和贺元、薛晓岚见面，当时贺元在中文PC Magazine有一技术专栏。记得当我向这位李经理提起我的机器几乎无法跑得动VisualAge C/C++3.5时，他还立刻一口答应借我一台当时IBM最高档的PC。同时每写一篇VisualAge C/C++3.5的文章，除了《RUN!PC》原本的稿费之外，IBM会再付一字2.5元的稿费。乖乖，IBM真是大手笔。我算算当时我的产能，写一篇文章就能够赚2到3万，又有免费的最高档机器可用，真是太好了。不过后来我还是觉得IBM在此市场可能不会深耕。在不愿意违背自己写作习惯和得罪Borland的顾虑下，最后还是没有答应。现在想想当时真是太笨了，放着好赚的稿费不赚，嘻。IBM的C/C++开发工具之所以在市场无法成功，是因为IBM并不了解在此竞争激烈的市场中使用者到底要什么。另外一个原因则是IBM并不以PC上的开发工具软件为重要的事业。即使无法竞争和获利，对于IBM来说也没有什么影响，因为IBM主要是靠硬件和大型软件为主，不像Borland这可是生命之争。因此IBM只是兴起玩玩，随即放下。所以我觉得在PC平台使用IBM的工具是很危险的，因为IBM随时都可能会放弃这个市场。不知道现在VisualAge C/C++到底下场如何?是不是还在3.5或是4.0版？IBM已经数年没有任何的维护和改善了。快速殒落的潜力之星：Sybase的C/C++RAD工具Optima++1996年左右，Sybase并购了Watcom之后终于推出了石破天惊的C/C++开发工具：Optima++。Optima++是当初结合了Watcom的最佳化编译器以及类似Delphi的组件拖曳开发环境的第一个RAD C/C++开发工具。更棒的是Optima++的组件架构(类似Delphi的VCL)完全是以纯正的C/C++程序代码撰写的。这可不得了，因为这代表Optima++是一个融合了Visual C/C++和Delphi两大王者开发工具为一身的超级赛亚人工具。在我知道这个工具、并且尝试实际使用之后，极为震惊。因为对于我这个使用了C/C++ 5、6年的人来说，它比Delphi更具有吸引力。因此我立刻在《RUN!PC》上介绍了这个不可置信的工具。果然，Optima++很快开始风卷市场，虽然没有立刻占据很大的市场份额，但是已经造成了一股气势，开始为Visual C/C++和Delphi带来压力。我记得当时台湾Sybase办的产品发表会也吸引了数百人与会，不可一世。我的文章在《RUN!PC》6上发表之后，台湾的Sybase立刻和我联络，由当时的余协理和我见面，也是希望我继续为Optima++写文章，台湾Sybase也提供额外一字加2元稿费的待遇。但是我告诉余协理，Optima++1.0虽然很棒，但是仍然有一些臭虫，而且和中文环境相冲突，无法处理中文，需要立刻解决这个问题才能够在台湾的市场成功。她答应我立刻向总公司反应。我也老实地告诉她，在问题没有解决之前，我无法写一些不确实的东西。后来台湾Borland的总经理方先生也找我去询问有关Optima++的事情，我告诉他Optima++是好东西，但是中文有问题。如果中文问题能够解决，那么将对Borland和Microsoft的产品有很大的影响，当时我还不知道Borland由于Optima++的影响，已经开始准备开发C++Builder。在1996年底左右吧，Optima++1.5终于进入Beta的阶段。但是在我拿到Beta版时非常失望，因为中文的问题仍然没有解决。后来台湾Sybase又找我去，这次和我见面的是台湾Sybase总经理郭俊男先生，以及Sybase的新加坡技术总裁，不过我忘记这位先生的名字了。见了面之后，我立刻把Optima++1.5中文的问题以及许多的臭虫告诉他们，希望他们能够解决，如此Optima++1.5才能够在中文市场成功。可是出乎我意料之外的是，他们似乎并不着急这些问题，反而询问我是否有意愿为Sybase工作，做PowerBuilder的产品经理。也许是因为我为Delphi写了太多的东西，让PowerBuilder在台湾受了很大的影响，因此他们希望我到Sybase工作，以打击Delphi并且Promote PowerBuilder。当时他们提出的待遇条件实在是非常、非常的诱人，比我当时的薪水高出一倍左右(我当时在资策会工作)。不过由于我对PowerBuilder实在没有什么兴趣，因此我告诉他们，如果是做Optima++的产品经理，那么我将会考虑并且接受。没有想到，Sybase的新加坡技术总裁告诉我Optima++在1.5推出之后就可能会停止，因为Sybase要把资源移去为当时愈来愈红的Java研发一个新的Java RAD开发工具，那就是后来的PowerJ。于是他询问我如果不愿意做PowerBuilder的产品经理，那么是不是愿意做PowerJ的产品经理？由于当时我已经知道Borland开始了Open JBuilder的研发，而我对Open JBuilder的兴趣远大于PowerJ，因此没有答应Sybase。果然，在Optima++1.5推出之后，不但中文的问题没有解决，Sybase之后也没有继续对Optima++研发下去。Optima++一个如此有潜力的产品就这样消失了，真是令人遗憾。Optima++应该有很好的机会可以成功的。我相信，如果当时Sybase知道C++Builder后来的成果，可能就不会放弃Optima++了，而C/C++的RAD工具一直要到后来的C++Builder来完成这个梦。C/C++的开发工具之争到此算是告一段落了，虽然后来Borland继续推出了Borland C/C++5.0，但是品质仍然不够好，市场反应也不佳。后来Borland终于在Borland C/C++5.02之后宣布停止此条产品线的开发，Borland C/C++的光荣历史也就从此打住，真是令人不胜感叹，而Visual C/C++从此在C/C++开发工具市场中再也没有对手。不过没有竞争的市场的确会让人松懈，后来的Visual C/C++进步的幅度愈来愈小，MFC也数年没有什么大进步，不像当时和Borland C/C++竞争时每一个版本都有大幅的改善。看来寡占的市场的确是不好的。