生这种情形，因此许多人便认为Microsoft隐瞒了一些技术没有让其他的厂商知道。
由于OLE是如此的复杂，因此Borland无法立刻在OWL之中实现这种功能，于是就造成
厂市场上负面的影响。至于Symantec和Wat虽然授权使用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 ponent
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 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）；
｝
｝
程序2 OWL的TOleWindow支持左键双击的成员函数
//
// 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
｝
虽然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的
华丽军团经过了整军经武，Wat的白色劲旅枕戈待旦，而且都从Microsoft授权使
用了MFC之后，蓝、红、花、白四大军团决战的日子终于来临。
首先，当Symantec和Wat分别取得了MFC之后，Symantec便推出了C/C＋＋ 7。x的版本，
和Wat C/C＋＋混战了起来。两个使用系出同门的C/C＋＋ Framework产品战得不亦
乐乎，随后Borland C/C＋＋ 4。5和Visual C/C＋＋的新版本也加入了这场最重要的决战。
但是，让Symantec和Wat 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和Wat军团很快就败下阵来。
至于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和Wat来说，这场战役就如同〃长平之战〃秦军坑杀40多万赵军一样。
杀得Symantec和Wat全军覆没，大败而归。至此Symantec弃守PC的C/C＋＋开发工具
市场，转而开始研发Java开发工具，进而在稍后推出了著名的Visual Cafe。至于
Eugene Wang，则离开了Symantec，也离开了PC开发工具的领域。
而Wat则更为凄惨。整个公司在DOS的市场逐渐式微，而Windows平台的开发工具又
大败而归，两头落空。不久之后，Wat便被新兴而起的Sybase并购，从此在竞争激
烈的开发工具市场中消失了。
归纳Symantec和Wat失败的原因，是因为C/C＋＋的Framework MFC掌握在Microsoft
手中，在决战时刻Microsoft居然手握比Symantec和Wat更新的MFC利器，而且在
Visual C/C＋＋精进最佳化编译器技术并且改善集成开发环境之后，Symantec和Wat
诉求的重点功能完全被Microsoft封死。因此在产品、技术、市场和气势上完全不如对
手的情形下，自然只能任人宰割了。
对于Borland，虽然没有像Symantec和Wat那么溃不成军，但也再次败下阵来。虽
然平心而论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的文章，除