按键盘上方向键 ← 或 → 可快速上下翻页，按键盘上的 Enter 键可回到本书目录页，按键盘上方向键 ↑ 可回到本页顶部！
————未阅读完？加入书签已便下次继续阅读！
下图则是当时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/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培养出来的。
Wat C/C＋＋在DOS市场站稳了脚跟之后，由于Windows已经逐渐成为市场的主流，DOS
势必将被逐渐淘汰出局，因此，Wat C/C＋＋如果要继续生存下去，也就…定要推出
Windows平台的C/C＋＋开发工具。大约是在1993、1994年左右，Wat终于推出第一个
Windows下的C/C＋＋开发工具。
不过，当时Wat C/C＋＋在Windows推出的C/C＋＋开发工具实在是平淡无奇。其集成开
发环境和另外三个对手比较起来简直像是远古的产品，…点特色都没有。不过Wat
C/C＋＋仍然是以它的最佳化编译器作为号召。因此当时发生了一个非常有趣的现象，
那就是许多软件公司会同时买Borland C/C＋＋，或是Visual C/C＋＋，Symantec C/C＋＋
之一，再搭配一套Wat C/C＋＋。在开发应用系统时使用其他三套开发工具之一，最
后要出货时再使用Wat C/C＋＋来编译以产生最佳的程序代码。
在Wat C/C＋＋推出了Windows平台的开发工具之后，也吸引了…群使用者。虽然Wat
C/C＋＋的市场比起其他的三家来说是最小的，但是总算撑起了一片天，成为四大C/C＋＋
开发工具之一。稍后Wat C/C＋＋被Sybase并购，成为Sybase Optima＋＋的前身。
对我的感觉而言，Wat C/C＋＋就像是一个穿着朴素、但是却拥有最佳训练的白色
C/C＋＋军团。
关键的时刻MFC Or Not
在Symantec C/C＋＋和Wat C/C＋＋逐渐站稳了脚跟之后，C/C＋＋四大编译器决战的时
刻也逐渐逼近了，一些其他出产C/C＋＋工具的软件公司早已自动退出了这个在当时竞
争最为激烈的软件市场。在1994年末的决战之前，Symantec和Wat同时面对了一个
非常严厉的考验，那就是C/C＋＋ Framework的选择。
虽然Symantec和Wat都以各自的特色占得了一定的市场，不过在当时对于一个C/C＋＋
开发工具来说，最重要的功能之一就是C/C＋＋ Framework。因此Symantec和Wat
也都必须为使用者提供一套C/C＋＋ Framework。不过这对于Symantec和Wat来说都
是一个难以解决的问题，因为当时的C/C＋＋ Framework已由Borland的OWL和Microsoft
的MFC所占领，虽然市场上也存在一些跨平台的C/C＋＋ Framework，例如ZApp和Zinc等，
但是这些C/C＋＋ Framework终究没有产生很大的影响。如果Symantec和Wat要自
己发展新的C/C＋＋ Framework，那他们还没有如此雄厚的资源，也无法在短时间之内
完成。因此Symantec和Wat必须决定，到底是要使用Microsoft的MFC还是使用Borland
的OWL来作为他们开发工具的C/C＋＋ Framework。
1993年初，Symantec和Wat分别和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和Wat
并没有看清这一点，以为有了和Microsoft一样的Framework，就可以在其他地方和
Microsoft以及Borland一决雌雄，Symantec和Wat却没有想到，就是这一点决定让
自己在后来的决战中一败涂地，最终完全退出了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和Wat失败的重要因素。
我记得当时OLE似乎成为了一个令人趋之若鹜的时髦功能。Word的文件能够内嵌在Excel
之中，而且使用者可以点选此Word文件，应用程序又立刻成为Word来编辑它，实在令
人觉得非常的神奇。不过，在其时所有的软件厂商中，只有Microsoft的应用程序有
如此的功能，其他的厂商例如Lotus、WordPerfect等都无法实现这种功能。
这明显地造成了不公平的竞争，因为OLE技术是由操作系统厂商Microsoft推出的，但
是却让它的应用程序部门同步拥有这种技术，而其他的软件厂商都无法获得第一手的
OLE技术来编写应用程序，这也是为什么当时其他的软件厂商如此火大的原因。
虽然后来其他的软件公司在取得了OLE的技术资料之后，也推出了具备OLE功能的应用
程序，但毕竟是慢了Microsoft许久，市场也流失了许多。不过，我觉得很奇怪的是，
在当时内建OLE功能的应用程序之中，几乎所有软件厂商推出的应用程序在激活数
个应用程序而且使用OLE之后，就非常容易死机，只有Microsoft的应用程序不太会发
生这种情形，因此许多人便认为Microsoft隐瞒了一些技术没有让其他的厂商知道。
由于OLE是如此的复杂，�