用。事实上以我的观点来看，正是因为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的SpreadSheet VBX组件，由于一直无法顺利地
在Borland C/C＋＋4。0中使用，并且会造成应用程序的当机，最后追踪执行程序代码却
发现应该是Borland C/C＋＋4。0的问题，因此最后只好在咒骂中放弃使用Borland
C/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＋＋、Wat C/C＋＋和Symantec C/C＋＋的缠斗
自Borland C/C＋＋4。0一役大败之后，Borland在C/C＋＋市场上建筑的巨大堡垒似乎再也
不是牢不可破了。Visual C/C＋＋固然在不断地接收Borland C/C＋＋失去的市场，这时
在C/C＋＋市场上也开始出现另外两个坚强的对手，那就是Symantec C/C＋＋和Wat
C/C＋＋。
Symantec C/C＋＋的发展史
Symantec C/C＋＋和Wat 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＋＋军团。
Wat C/C＋＋的发展史
非常有趣的是，Wat C/C＋＋走的路子和Symantec C/C＋＋几乎是完全相反的。当时出
品Wat C/C＋＋编译器的是一家加拿大的小公司，不过这家公司却对最佳化编译器有
深入的研究。当时，Wat C/C＋＋是以在DOS下能够产生最好的最佳化程序代码闻名
于世的，许多写游戏和DOS Extender的厂商都指名要使用Wat C/C＋＋，因为不论是
Borland C/C＋＋还是Visual C/C＋＋，它们产生的最佳化程序代码都比Wat C/C＋＋的
最佳化程序代码差上一截。再加上当时最有名的DOS Extender厂商PharLap公司也是
使用Wat C/C＋＋，因此Wat C/