(这条文章已经被阅读了 65 次) 时间：2002-01-26 14:38:58 来源：胡元志 (逢一笑) 转载
李维（台湾）
OLE的搅局
不知道是时运不济或是Microsoft的刻意如此，在1994年Borland C/C++和Visual C/C++决战的前夕，Micro-
soft推出了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虽然是LicenseMFC，但是在其时它们License的是MFC 1.x的版本，Microsoft并没有把OLE
实作在MFC 1.x中，而是在实作在MFC2.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年未，Bor-
land终於推出了决战的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的则是以红色为色系，仿佛两大军团终将决战似的。
图6
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和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的挑起的浏览器
大战。
对於Borland而言，在C/C++最后一役之后，基本上我认为开发工具的圣战已然结束，Borland也正式开始走下
坡。更严重的是我认为自此之后Borland不但丧失了C/C++的江山，也失去了对於C/C++开发工具的创意，这是我感
觉最遗憾的地方，到现在为止我仍然认为Borland尚未重拾当初在Borland C/C++ 3.0/3.1时代独领C/C++创意风骚
的精神。也许，也许，要看看C/C++ For Kylix或是C++ Builder 6是否能够重新找回这个失去已久的精神，不要
再让我失望了。
图7
雄霸数年的C/C++的世界冠军-Borland C/C++ 3.1-永远的怀念
永不成气候的C/C++开发工具-IBM Visual C/C++
IBM在C/C++开发工具扮演的角色一直令人啼笑皆非，因为在C/C++编译器战争最激烈的时刻，IBM这个全球资讯
大厂却一直是缺席的。一直到了1995之后，C/C++编译器市场大势已定之后才慢慢的加入战局，推出VisualAge C++
3.0，企图进攻此市场。但是此时市场早已由Microsoft的Visual C/C++称雄。IBM的VisualAge虽然以创新的视觉化
设计家能够定义物件之间的关系，但是在其他方面却乏善可陈，整个整合发展环境也缓慢如蜗牛，需要非常高档的
硬体配备才能够顺利的执行，和Visual C/C++以及Borland C/C++等工具比较起来就像是恐龙一般，因此几乎没有在
市场上引起任何的反应。
在IBM推出VisualAge 3.0并没有在PC的C/C++开发工具市场获得任何的明显成果之后，IBM又再次的集中了许多
的资源，开发下一代3.5的版本，希望能够在此市场佔有一定的比率。我知道IBM在VisualAge投注了大量的资源，
因为从Beta版开始台湾的IBM便有人和我接触，希望我也在RUN!PC上为VisualAge 3.5写一些文章。因此在1996年的
6月我写了一篇C/C++编译器的比较文章，下面的资料便是数年前当时还在Beta版的VisualAge 3.5和其他编译器的
比较：
从上面的数据中可以看到其实VisualAge 3.5的表现还不错，只是对於当时还在使用AMD DX4-100/32M RAM机器
的我来说，实在是跑不太动VisualAge 3.5。后来台湾IBM负责VisualAge的产品经理请我吃饭，在此饭局中这位李
经理同时请了贺元(后来为资迅人的总裁)，薛晓岚(后来为资迅人的副总裁)以及其他两位作者，希望大家在电脑杂
志中继续的为VisualAge 3.5写写东西，一起Promote此产品。在这个饭局中我是第一次和贺元，薛晓岚见面，当时
贺元在中文PC Mag-azine有一技术专栏。记得当时我向这位李经理提起我的机器几乎无法跑VisualAge 3.5，他还
立刻一口答应愿意借我一台当时IBM最高档的PC，同时每写一篇VisualAge的文章，除了RUN!PC原本的稿费之外，
IBM会再付一字2.5元的稿费。乖乖，IBM真是大手笔，我算算当时我的产能，写一篇文章就能够赚2到3万，又有免
费的最高档机器可用，真是太好康了。不过后来我还是觉得IBM在此市场可能不会深耕，在不愿意违背自己写作习
惯和得罪Borland的顾虑下，最后还是没有答应。现在想想当时真是太笨了，放着好赚的稿费不赚，嘻。
IBM的C/C++开发工具之所以在市场无法成功是一是因为并不瞭解在此竞争激烈的市场中使用者到底要什么。另
外一个原因则因为IBM并不以PC上的开发工具软件为重要的事业，即使无法竞争对於IBM来说也没有什么影响，不像
Borland这可是生命之争。因此IBM只是兴起玩玩，随即放下。所以我觉得在PC平台使用IBM的工具是很危险的，因
为IBM可能随时会放弃此市场。例如不知道现在VisualAge C/C++到底如何，是不是还在3.5或是4.0版，已经数年没
有任何的维护和改善了。
稍后IBM为了想在OS2和Window平台上推出能够和Microsoft相抗衡的Basic工具，因此秘密的研发了一个Object
Basic。我也曾看过这个工具，但是Object Basic跑起来慢得跟乌龟一样．后来不知道是不是一直无法改善这个问
题，因此IBM从没有推出此产品，现在IBM似乎只对Java有兴趣，VisualAge For Java还算发展的不错，希望不会有
一天IBM对Visual-Age ForJava的态度会和VisuaAge For C/C++以及Object Basic一样才好．
快速殒落的潜力之星－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
文章出版之后，台湾的Sybase立刻和我连络。由当时的余协理和我见面，也是希望我继续为Optima++写文章，台湾
Sybase也提供额外一字加2元稿费的待遇。但是我告诉余协理，Optima++ 1.0虽然很棒，但是仍然有一些臭虫，而
且和中文环境相冲突，无法处理中文，需要立刻的解决问题才能够在台湾的市场成功。她答应我立刻的向总公司反
应。我也老实的告诉她在问题没有解决之前我无法写一些不确实的东西。后来台湾Borland的总经理方先生也找我
去询问有关Optima++的事情，我告诉他Optima++是好东西，但是中文有问题。如果中文问题能够解决，那么将对
Borland的产品有很大的影响，当时我还不知道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++应该有很好的机会可以成功的，我相信如果当
时Sybase知道C++ Builder后来的成果，可能就不会放弃Optima++了。而C/C++的RAD工具一直要到后来的C++ Builder
来完成这个梦，又是Borland成功的进入这个工具市场。
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++竞争时每一个版本都有大幅的改善。看来垄断的市场的确是不好的。