borland传奇
borland传奇
声明．．．．．．．．．．．．．．．．．．．．．．．．．．．．．． 1
第一章 Borland的诞生和发展
Borland的兴起 ．．．．．．．．．．．．．．．．．．．．．．． 3
关键产品--SideKick．．．．．．．．．．．．．．．．．．．．． 5
和Borland的缘由 ．．．．．．．．．．．．．．．．．．．．．． 10
C/C++的光荣战役 ．．．．．．．．．．．．．．．．．．．．．． 13
火线全开．．．．．．．．．．．．．．．．．．．．．．．．．． 19
数据库市场的失误．．．．．．．．．．．．．．．．．．．．．． 2l
ODBC和IDAPI之争 ．．．．．．．．．．．．．．．．．．．．．． 23
第二章 C/C++的圣战
Borland C/C++的反击 ．．．．．．．．．．．．．．．．．．．． 27
Borland C/C++、Visual C/C++、Watcom C/C++
和Symantec C/C++的缠斗．．．．．．．．．．．．．．．．．．． 34
C／C++开发工具的最后圣战．．．．．．．．．．．．．．．．．． 44
第三章 传奇的开始--Delphi
造传奇故事的主角--Delphi．．．．．．．．．．．．．．．．．． 54
大规模的开发行动和Philippe Kahn的下台 ．．．．．．．．．．． 58
Anders的计划以及Zack的想法．．．．．．．．．．．．．．．．． 65
天才的损失和新英雄的接棒．．．．．．．．．．．．．．．．．． 76
第四章 未完之传奇
Chuck的秘密计划 ．．．．．．．．．．．．．．．．．．．．．． 110
回到未来．．．．．．．．．．．．．．．．．．．．．．．．．． 117
Delphi风云榜．．．．．．．．．．．．．．．．．．．．．．．． 121
第五章 逆转的奇迹--Borland JBuilder的战斗发展史
Java开发工具初期的争战．．．．．．．．．．．．．．．．．．． 135
Borland的Java艰辛奋斗 ．．．．．．．．．．．．．．．．．．． 138
第六章 失去的王冠--Borland数据库工具的战役
IntraBuilder的诞生．．．．．．．．．．．．．．．．．．．．． 201
命运坎坷的dbase ．．．．．．．．．．．．．．．．．．．．．． 212
Paradox ．．．．．．．．．．．．．．．．．．．．．．．．．． 224
后言．．．．．．．．．．．．．．．．．．．．．．．．．．．． 229
第七章 中途岛之战--Borland和组件技术
Golden Gate Strategy．．．．．．．．．．．．．．．．．．．． 231
到EJB的阵地吧!．．．．．．．．．．．．．．．．．．．．．．． 238
第八章 Borland的成长和改变
Philippe Kahn，产品和技术为主的Borland．．．．．．．．．．． 243
Delbert Yocam，强势Marketing为主的Borland ．．．．．．．．． 245
Dale Fuller，高效率Sale Force的Borland．．．．．．．．．．． 248
第四波的演变．．．．．．．．．．．．．．．．．．．．．．．． 254
软件高科技公司的命运．．．．．．．．．．．．．．．．．．．． 256
Borland Conference．．．．．．．．．．．．．．．．．．．．． 258
并购、自保和集团战．．．．．．．．．．．．．．．．．．．．． 261
第九章 软件技术和平台的大竞赛
Microsoft的COM组件模型．．．．．．．．．．．．．．．．．．． 273
SUN的EJB组件模型．．．．．．．．．．．．．．．．．．．．．． 276
Data Access Technology．．．．．．．．．．．．．．．．．．． 286
.NET对于开发工具厂商的影响．．．．．．．．．．．．．．．．． 292
第十章 令人焦虑的时代
信息技术多元化的发展．．．．．．．．．．．．．．．．．．．． 297
快速的开发周期．．．．．．．．．．．．．．．．．．．．．．． 306
程序语言的战争．．．．．．．．．．．．．．．．．．．．．．． 309
知己知彼，百战百胜．．．．．．．．．．．．．．．．．．．．． 313
结论．．．．．．．．．．．．．．．．．．．．．．．．．．．． 315
第十一章 EJB对抗CORBA？有趣的假设
.NET核心组件技术．．．．．．．．．．．．．．．．．．．．．． 320
巨人终将对决？．．．．．．．．．．．．．．．．．．．．．．． 327
第十二章 回到C/C++的王国
日不落帝国．．．．．．．．．．．．．．．．．．．．．．．．． 330
蓬勃发展的新兴C/C++力量 ．．．．．．．．．．．．．．．．．． 338
C/C++开发工具的未来 ．．．．．．．．．．．．．．．．．．．． 345
第十三章 软件科技的发展和Borland的未来
不都是整理和抽丝剥茧吗？．．．．．．．．．．．．．．．．．． 349
Web Service Works ．．．．．．．．．．．．．．．．．．．．． 359
面向对象技术的平民化．．．．．．．．．．．．．．．．．．．． 363
准备迎接.NET时代的来临．．．．．．．．．．．．．．．．．．． 370
Borland的未来 ．．．．．．．．．．．．．．．．．．．．．．． 372
结论．．．．．．．．．．．．．．．．．．．．．．．．．．．． 377
第十四章 传奇的篇章仍将继续！
过长的产品线？．．．．．．．．．．．．．．．．．．．．．．． 380
进入.NET的时机．．．．．．．．．．．．．．．．．．．．．．． 381
Java市场即将进入成熟期．．．．．．．．．．．．．．．．．．． 383
软件产业即将进入各拥山头的竞争模式？．．．．．．．．．．．． 384
但是传奇的故事仍将继续．．．．．．．．．．．．．．．．．．． 387
附录 Borland大事记 ．．．．．．．．．．．．．．．．．．．．．． 389
序
公元2000年，当笔者的第一篇有关Borland的回忆录在"Programmer深度论坛(http:/
/forum.vclxx.org)"发表之后，立刻得到了极为热烈的回响。在"Programmer深度论
坛"上，这篇回忆立刻成为当时点击率最高、阅读量最大的文章。随后笔者也意外地
发现这篇文章被许多人在网上转载。很多读者不断地写信给我，希望能继续阅读随后
的回忆文章。更有许多不认识我的大陆朋友也不断询问这篇文章的来源、作者。这么
热烈的回馈，是我没有想到的。最早撰写和发表这篇回忆文章的原因之一是笔者已经
离开了Borland，但觉得Borland的许多故事非常精彩、非常值得回味，因此才动了写
些小故事的念头。另外的一个原因，则是当时"Programmer深度论坛"成立未久，为了
吸引网友到"Programmer深度论坛"共襄盛举，因此当时的创始坛主之一、也是我的好
友李匡正先生希望我写一些吸引人的东西来帮帮忙。于是，这才促成了这篇回忆文章
的诞生。
不久之后，大陆的《程序员》杂志也和笔者联络上了。《程序员》除了希望我能够为
他们写一些Borland产品的技术文章之外，也对这些Borland的故事非常感兴趣，因此
2001年的7月份在《程序员》杂志刊登了"Borland的故事"一文。没有想到这篇已经在
Internet/Intranet上广为流传的文章，刊登之后仍然引起了广泛的响应，许多读者
都好评有加，强烈地希望《程序员》杂志能够继续刊登后续的文章。当然，《程序员》
杂志也立刻和笔者联络，希望我能立刻撰写随后的故事。在此之后，台湾的《RUN!PC》
也刊登了这篇文章，读者的反应也是如出一辙，热切地要求后续的内容。
我想，这篇文章之所以会引起巨大的反应，大概是因为许多软件人员都使用过Borland
的开发工具，最明显的就是Borland的Turbo系列。相信Turbo Pascal是当初许多人学
习数据结构(Data Structure)的必备工具，笔者就是其中之一。而Turbo C、Turbo
C++、Borland C/C++等更是许多人学习C/C++语言的启蒙工具。不管这些人现在使用
的是什么工具，即便已经不再使用Borland工具，但这些成长和学习的记忆仍然埋藏
于每一个程序员的心底，而这篇回忆文章可能勾起了许多人早已消失许久的回忆，顿
时之间这些曾经苦涩和欢乐的记忆又激荡在许多人的脑海里。当然这篇回忆文章也能
让许多人了解到当年许许多多隐藏在背后的故事答案：为什么软件历史会这样发展？
寻求答案的好奇心从不会因为时间的消逝而磨灭。当这篇回忆文章揭开了许多故事背
后的答案之后，当然会引起读者更大的回响，因为这会让我们想要知道的更多。而更
多封尘在我们内心深处的问题，会开始在脑中再次询问--接下来的发展会是什么样子？
在撰写第一篇回忆文章时，我的感觉比较轻松，因为那时我已经离开了Borland，没
有什么负担。但是"世事难料"，也许是和Borland的缘分未了，在2001年底，我又回
到了Borland工作。再次成为Borland的员工之后，在写作时就有了顾忌，不知道结果
会怎样，所以在这方面写作的进度使停顿了下来，甚至有很长一段时间没有任何的进
展。不过后来仔细一想，这些只不过是一些历史的事迹以及笔者个人的想法和观察，
如果Borland连这些都无法面对，那又要如何面对未来呢？于是我又开始断断续续地
拾起了进度，慢慢地写了一些后续的内容，并且同步地发表于大陆《程序员》杂志和
台湾的《RUN!PC》杂志。
集结这些回忆记录、发表我对未来软件趋势发展的观察和看法，是因为许多读者都希
望能痛痛快快一次看完这些精彩的故事，而不是"望穿秋水"地等待我时断时续，因此
不断地建议我集结出书。当时，我的第一个反应是这些故事内容的长度可能不够成为
一本书，而且我的工作太忙，因此并没有把这个建议放在心上。不过在后来不断地撰
写后续文章时，我才发现，以往的回忆不断地随着笔尖涌出。原本只打算写三四篇的
计划，竟不可收拾地愈写愈多。而且随着叙述过往的回忆故事，我也开始思索一些更
深的问题，并且开始观察软件趋势的发展以及Borland的演变等重要问题。我开始想，
能否通过Borland的成长、衰退以及东山再起等发展史实，了解软件开发对于每一个
软件人员的影响？如果换作我或读者来担任Borland的CEO，那又会如何经营？如何面
对挑战？如何帮Borland走出困境？在这些年的奋斗过程中，Borland经历了哪些改变？
Borland要如何面对未来的竞争？软件开发的趋势对于Borland的影响又是如何？或许
是因为笔者深爱着Borland吧，这些问题开始不断地在我的脑海中出现，不断地询问
着自己。也许读者看完本书之后，也会开始遭遇和我一样的情形，开始思索这些复杂
又有趣的问题。当然这些后续的发展是当初我所没有预想到的，但对于自己而言，这
也是额外的收获。
事实上，我认为这些问题是提升自己最好的锻炼，因为可以培养我们对于事情的观察
能力，去思考问题和背后的意义，并掌握未来的发展。当软件人员开始注意到这样的
思考之后，往往也就预示着开始要更上层楼，这也是笔者这么多年和许多工程师工作
时观察到的现象。只可惜事实证明，这些毕竟是只有少数人才会注意到的事情。七八
年前，当我为鼎新计算机工作时，当时的副总要求我除了开发产品和技术之外，每个
星期必须向他报告笔者对于未来市场、产品和技术趋势的意见和报告。也就从这个时
期开始培养了笔者思索这些问题的习惯。数年后，当我开始为Borland工作，并成为
产品经理之后，我又开始观察产品和技术趋势。这些训练都让我很自然地在撰写文章
和书籍时开始观察过往的历史并且开始询问自己相关的问题。
因此，当《程序员》杂志的蒋涛先生也询及我出书的意愿之后，笔者开始认真地考虑
这个可能。除了叙述Borland各项重要的战役故事、产品开发的幕后史以及精彩的故
事之外，笔者也想写写这些年观察到的Borland的转变史，以及转变之后的影响。另
外还想写出Borland未来面对的挑战、软件开发的趋势等有趣的讨论。当然，Borland
强韧的生命力仍然在继续不断创造她的历史，对于笔者和喜爱Borland的人来说，这
些可都是可歌可泣的故事。
对于本书的架构，我也经历了一个从起初模糊的概念到最后清楚地表达自己想要描述
的内容的过程。大致上，我将本书分为三个部分，这分别是：
● Borland产品开发的精彩故事。在这些章节中，我将就记忆所知为读者娓娓道来
许多或精彩、或动人、或令人惋惜的故事。它们包括了Borland本身的故事、C／C++
开发工具、Delphi、Jbuilder、Visual dbase、IntraBuilder和组件以及中间件的发
展故事，让读者了解产品开发的艰辛史以及Borland如何在激烈的竞争中力求生存之
道。
● Borland的转变发展。许多人都知道Borland，但是可能没有注意到Borland在将
近20年来的变化。其实，每一个阶段的变化都是由于特定的人物和时势所造成。这部
分笔者将为读者介绍这些微妙的变化并且叙说其背后的原因和故事。
● 软件趋势的发展以及未来的Borland。如今的软件技术多得令人目不暇给，软件
技术的发展也是以10倍的速度向前推进。在现在多元化的软件技术中，到底未来的主
流技术或是平台将由谁胜出？软／硬件厂商之间的合纵连横又将对软件技术产生什么
影响？Borland在未来又将如何竞争？未来的Borland产品又将如何占有一席之地？这
都是笔者想要和读者一起分享并讨论的内容。
本书算是相当有趣的一个代表，因为她融合了精彩的故事、发人省思的竞争过程、最
新的软件技术趋势以及对未来的思考。在阅读本书的过程中，读者可能会有不同的感
受：可能会勾起许多人封尘已久的记忆；也可能会让读者感受快乐、惋惜、沮丧和振
奋；也可能会让读者感觉焦虑，因为面对现在和未来多元化软件技术的发展，许多读
者可能都不知所措。不过在阅读完本书之后，相信读者应该会对未来信息产业的发展
有一定的掌握。
因此，这本书的内容可能会成为一些读者对自己职业生涯的纪念；成为一些读者学习
信息历史的明镜；抑或成为大多数读者掌握现在和来来信息技术发展趋势的参考。对
于笔者而言，此书的整理算是对自己以往工作和回忆的记录以及面对未来的准备。
我不是以写作为生，因此撰写时间非常有限。什么时候能够完成这本书?我并没有把
握，只能尽力而已。在写作的过程中，我也历经了数个阶段：从一开始的兴奋莫名，
到强求自己一定要在什么时候出书，再到现在随缘，做好了再说的阶段。
最后，我要谢谢所有鼓励过我的朋友，这毕竟是我第一本非纯技术类的书籍，心中难
免心虚。自己所能做的便是尽量提供丰富的内容，至于最后的结果，当然交由各位读
者来评判了。
李维
2002.10于台北新店
目录
声明．．．．．．．．．．．．．．．．．．．．．．．．．．．．．． 1
第一章 Borland的诞生和发展
Borland的兴起 ．．．．．．．．．．．．．．．．．．．．．．． 3
关键产品--SideKick．．．．．．．．．．．．．．．．．．．．． 5
和Borland的缘由 ．．．．．．．．．．．．．．．．．．．．．． 10
C/C++的光荣战役 ．．．．．．．．．．．．．．．．．．．．．． 13
火线全开．．．．．．．．．．．．．．．．．．．．．．．．．． 19
数据库市场的失误．．．．．．．．．．．．．．．．．．．．．． 2l
ODBC和IDAPI之争 ．．．．．．．．．．．．．．．．．．．．．． 23
第二章 C/C++的圣战
Borland C/C++的反击 ．．．．．．．．．．．．．．．．．．．． 27
Borland C/C++、Visual C/C++、Watcom C/C++
和Symantec C/C++的缠斗．．．．．．．．．．．．．．．．．．． 34
C／C++开发工具的最后圣战．．．．．．．．．．．．．．．．．． 44
第三章 传奇的开始--Delphi
造传奇故事的主角--Delphi．．．．．．．．．．．．．．．．．． 54
大规模的开发行动和Philippe Kahn的下台 ．．．．．．．．．．． 58
Anders的计划以及Zack的想法．．．．．．．．．．．．．．．．． 65
天才的损失和新英雄的接棒．．．．．．．．．．．．．．．．．． 76
第四章 未完之传奇
Chuck的秘密计划 ．．．．．．．．．．．．．．．．．．．．．． 110
回到未来．．．．．．．．．．．．．．．．．．．．．．．．．． 117
Delphi风云榜．．．．．．．．．．．．．．．．．．．．．．．． 121
第五章 逆转的奇迹--Borland JBuilder的战斗发展史
Java开发工具初期的争战．．．．．．．．．．．．．．．．．．． 135
Borland的Java艰辛奋斗 ．．．．．．．．．．．．．．．．．．． 138
第六章 失去的王冠--Borland数据库工具的战役
IntraBuilder的诞生．．．．．．．．．．．．．．．．．．．．． 201
命运坎坷的dbase ．．．．．．．．．．．．．．．．．．．．．． 212
Paradox ．．．．．．．．．．．．．．．．．．．．．．．．．． 224
后言．．．．．．．．．．．．．．．．．．．．．．．．．．．． 229
第七章 中途岛之战--Borland和组件技术
Golden Gate Strategy．．．．．．．．．．．．．．．．．．．． 231
到EJB的阵地吧!．．．．．．．．．．．．．．．．．．．．．．． 238
第八章 Borland的成长和改变
Philippe Kahn，产品和技术为主的Borland．．．．．．．．．．． 243
Delbert Yocam，强势Marketing为主的Borland ．．．．．．．．． 245
Dale Fuller，高效率Sale Force的Borland．．．．．．．．．．． 248
第四波的演变．．．．．．．．．．．．．．．．．．．．．．．． 254
软件高科技公司的命运．．．．．．．．．．．．．．．．．．．． 256
Borland Conference．．．．．．．．．．．．．．．．．．．．． 258
并购、自保和集团战．．．．．．．．．．．．．．．．．．．．． 261
第九章 软件技术和平台的大竞赛
Microsoft的COM组件模型．．．．．．．．．．．．．．．．．．． 273
SUN的EJB组件模型．．．．．．．．．．．．．．．．．．．．．． 276
Data Access Technology．．．．．．．．．．．．．．．．．．． 286
.NET对于开发工具厂商的影响．．．．．．．．．．．．．．．．． 292
第十章 令人焦虑的时代
信息技术多元化的发展．．．．．．．．．．．．．．．．．．．． 297
快速的开发周期．．．．．．．．．．．．．．．．．．．．．．． 306
程序语言的战争．．．．．．．．．．．．．．．．．．．．．．． 309
知己知彼，百战百胜．．．．．．．．．．．．．．．．．．．．． 313
结论．．．．．．．．．．．．．．．．．．．．．．．．．．．． 315
第十一章 EJB对抗CORBA？有趣的假设
.NET核心组件技术．．．．．．．．．．．．．．．．．．．．．． 320
巨人终将对决？．．．．．．．．．．．．．．．．．．．．．．． 327
第十二章 回到C/C++的王国
日不落帝国．．．．．．．．．．．．．．．．．．．．．．．．． 330
蓬勃发展的新兴C/C++力量 ．．．．．．．．．．．．．．．．．． 338
C/C++开发工具的未来 ．．．．．．．．．．．．．．．．．．．． 345
第十三章 软件科技的发展和Borland的未来
不都是整理和抽丝剥茧吗？．．．．．．．．．．．．．．．．．． 349
Web Service Works ．．．．．．．．．．．．．．．．．．．．． 359
面向对象技术的平民化．．．．．．．．．．．．．．．．．．．． 363
准备迎接.NET时代的来临．．．．．．．．．．．．．．．．．．． 370
Borland的未来 ．．．．．．．．．．．．．．．．．．．．．．． 372
结论．．．．．．．．．．．．．．．．．．．．．．．．．．．． 377
第十四章 传奇的篇章仍将继续！
过长的产品线？．．．．．．．．．．．．．．．．．．．．．．． 380
进入.NET的时机．．．．．．．．．．．．．．．．．．．．．．． 381
Java市场即将进入成熟期．．．．．．．．．．．．．．．．．．． 383
软件产业即将进入各拥山头的竞争模式？．．．．．．．．．．．． 384
但是传奇的故事仍将继续．．．．．．．．．．．．．．．．．．． 387
附录 Borland大事记 ．．．．．．．．．．．．．．．．．．．．．． 389
Page 1
声 明
本书的内容主要基于我个人的回忆和看法，没有任何特别的偏见。许多历史资料来自
我的记忆以及很多相关人的叙述和诉说，也许细节之处不是百分之百的正确，不过我
可以保证这些内容的可信度。也许有一些历史事件确定的发生时间和顺序不一定与我
的记忆完全一致，但相信大部分应该出入不大。当然，如果有读者知道更确切的史实，
非常欢迎您的指正。
希望这些故事的经历能够一直陪伴我，陪伴所有对软件开发有兴趣的读者们一路走下
去，成为大家共同奋斗的记忆，这也是我写作本书的最大心愿，谢谢。
^v^v^v^v^v^v^v^v^v
第一章 Borland的诞生和发展
一直想写篇文章，讲述我个人在过去10多年来工作中经历的一些事情，以及这些日子
中那些我心目中的伟大的工程师们对于信息界的贡献。如果读者和我的年龄差不多，
那对于这些内容可能会更有兴趣，因为它们揭示了当时许多软件兴起和没落的过程以
及原因。虽然这些事情距离我们很遥远，但我相信许多人仍然对于背后的故事感兴趣。
即便没有经历过那段美好的回忆，那也可以把这些内容当成一个有趣的故事来读吧。
不过我想，更重要的是让我们一起认识一些伟大的人物，我个人对于其中的许多人都
非常佩服，也非常羡慕。甚至我常常在想，如果自己也有他们的环境，是不是也能够
和他们一样这么有成就呢？这些人对于以往都有着重要的贡献，对未来也仍将有着重
要的影响，因为他们都有一身不凡的技术。对于许多重要的人物，我都尽量收集了他
们的照片，让各位也能够认识这些优秀的工程师、杰出的人物。
当然，如果各位能够从这些内容中学习到失败的教训以及成功的经验，那么本书就更
有价值了。
Borland的兴起
记得大学时，第一个在PC上使用的软件就是SideKick。这个至今让我仍然无法忘记的
软件，也曾让许多人津津乐道，而Borland当时也就是以SideKick成为全球知名的软
件公司。不过Borland第一个奠立创业基础的软件，却是我大二用来交作业的Turbo
Pascal，而Turbo Pascal也是我听到的第一个关于Borland的有趣的故事。
当年Philippe Kahn(Borland的创始人)和Anders Hejlsberg到美国创业时，便由Anders
以汇编语言撰写了Turbo Pascal的编译器，而Philippe则包办了Turbo Pascal其他的
部分。在这两位仁兄开发完Turbo Pascal之后，穷得快连登广告的钱都没有了。Philippe
为了在Byte杂志(还记得这个著名的杂志吗？)刊登Turbo Pascal的广告，和Anders商
量了一个方法，那就是直接约Byte杂志的人到当时Borland的办公室讨论刊登广告的
事情。
当Byte的人到了Borland之后，Philippe、Anders和公司的助理小姐故意忙着接电话，
接受Turbo Pascal的订单，并且告诉Byte杂志的人等一下。过了一阵之后Philippe
才进入房间向Byte的人道歉，说他们的Turbo Pascal受到市场的热烈欢迎，订单源源
不断地到来，因此可能不需要在Byte杂志刊登广告了，接着Philippe向Byte的人展示
Turbo Pascal这个产品。由于在当时的机器中Turbo Pascal能够在极少的RAM中常驻
执行，又提供闪电般的编译速度，这立刻让Byte杂志的人当场震惊。凭着专业知识和
丰富的经验，Byte的人立刻知道这将是一个革命性的软件，因此马上希望Philippe能
够在Byte杂志刊登Turbo Pascal的广告，并且愿意以半价刊登。当然，Philippe也立
刻爽快地答应了，于是一个革命性的软件Turbo Pascal终于在Byte杂志刊登出来了。
当时售价49.99美元的Turbo Pascal立刻为Borland带来了大量的财富，Turbo Pascal
也马上成为PC上除了基本的Basic之外最畅销的开发工具，由此正式揭开了Borland影
响PC开发工具近20年的历史的序幕。
Turbo Pascal是由Anders Hejlsberg亲自开发的，并且和Philippe Kahn谈好的条件
是Borland每卖出一套Turbo Pascal，Anders便从中抽取一份版权费。由于当时软件
的价格不算便宜，能够写编译器的人更是少之又少，所以编译器工程师通常都能够获
得优厚的报酬。因此当时Anders Hejlsberg在完成了Turbo Pascal、并且和Philippe
Kahn谈好了合作条件之后，Anders理所当然地认为一套Turbo Pascal会定价数百元
美金，因为这不但是当时一般编译器的价格，而且Turbo Pascal还内含了一个开发环
境和编辑器(Editor)，这是当时许多工具没有提供的。
没有想到极具商业头脑的Philippe Kahn了解到：如果把Turbo Pascal定价在数百美
金，那么Turbo Pascal可能只会卖出数百到数千套，无法冲出大量的销售额。因此，
Philippe Kahn
以极大的勇气，瞒着Anders Hejlsberg只把Turbo Pascal定价为49.95美金。这种价
格在当时对于编译器和开发工具来说简直是不可思议的低价。当Anders Hejlsberg知
道了Philippe Kahn的定价后，简直快气昏了。因为在这么低的价格下Anders的版税
金一定少得可怜，因此当时Anders说他把最好的Pascal开发工具拿去让一个白痴销售。
没有想到的是，Philippe Kahn的定价策略获得了极大的成功。Turbo Pascal以极佳
的品质和令人不可思议的低价格成为当时最具吸引力的Pascal开发工具。当然，在
Turbo Pascal卖出了让人难以置信的成绩之后，Anders便再也不提他把专业Pascal编
译器让白痴去卖这件事了。
关键产品--SideKick
虽然Turbo Pascal快速地让Borland在当时全世界的程序员中成为最响亮的软件新星，
但是真正让Borland打人一般计算机使用人群、快速成长为软件巨人的大功臣的，却
是Borland早期最重要的产品--SideKick。
在Turbo Pascal之后，Borland接着推出了SideKick这套软件。SideKick可以说是随
后著名的内存常驻软件(Terminate and Stay Resident-TSR)的始祖，也是Borland跨
出开发工具领域、让几乎所有PC使用者认识Borland的关键软件。SideKick在当时以
许多丰富的小工具和记事功能让它成为每一个程序员爱不释手的工具。还记得当时我
每天都会使用SideKick的ASCII对照表和计算器的功能，因为在汇编语言(Assembly)
盛行的时期，查阅ASCII对照表和在2进制、10进制以及16进制之间进行转换是每日必
要的工作。
当然SideKick也很快成为了畅销软件，在全球狂卖数10万套，继续把Borland往顶尖
的软件公司推进。
所谓的TSE代表Terminate and Stay Resident。这个意思是说，这类软件在执行后会
隐藏在内存的某个位置中，但是并没有出现在屏幕上。不过使用者通过一个快捷键就
可以立刻调出这类软件让使用者使用，在使用完毕之后又可以按一个快捷键再度隐藏
它。这样的软件运行方式在当时是一项全新的创举。
以我的眼光来看，SideKick这个软件对于Borland来说是非常关键的作品，因为我将
SideKick归类成"消费型软件"产品。所谓消费型软件，是指可以被所有计算机使用者
使用的软件，而不是只给程序员或是开发者使用的软件。凡是现今比较会赚钱或是规
模比较大的软件公司大都属于开发"消费型软件"的公司。例如Microsoft除了有和Borland
竞争得你死我活的开发工具之外，最重要的是Microsoft拥有两大"消费型软件"：Windows
操作系统和Office。这两类软件才是Microsoft最赚钱的产品。Oracle是另外一个很
好的例子，数据库几乎是现在任何应用都需要使用的软件。同样，SideKick就属于这
一类型的软件，因为SideKick可以被所有的开发者使用来增加生产力，而不管开发者
使用的是什么语言。因此当Borland推出SideKick之后，立刻在全世界狂卖，也成为
继Turbo Pascal之后Borland最赚钱的产品。我认为在后来的数年之中Borland走得比
较辛苦，便是因为Borland再也没有推出像SideKick一样属于"消费型软件"的重量级
产品，而只有属于程序员和开发者小众市场的产品，这是非常可惜的事情。而"消费
型软件"也是到现在我仍然认为Borland应该推出的产品。
由于SideKick的TSR技术是当时独一无二的，而且是如此的好用，这引起了当时许多
人的好奇，并且成了所有软件厂商模仿的对象，我还记得稍后许多的计算机信息书籍
都以如何学习TSR技术作为卖点。也是因为SideKick和TSR太成功了，因此Borland立
刻进行了两个工作。第一当然是马上开发下一版的SideKick，让SideKick继续执类似
软件的牛耳，以防止其他软件公司推出类似的软件来分食SideKick打下的天下。
很快地，Borland便推出了SideKick的后续版本，不但功能更多，而且SideKick从原
本完全以开发者为中心的软件转变为适合所有计算机使用者使用的消费型软件。看看
左图，从产品封面以"Desktop Organizer"为主题便可以了解到SideKick在当时的定
位。果然，后续的SideKick又持续地大卖，这让Philippe Kahn非常振奋，也让他雄
心大盛，开始想要通过SideKick的成功主导PC软件的标准，这当然就是SideKick一举
成名的TSR技术。
在Borland通过Turbo Pascal和SideKick大获成功之后，也因TSR技术成为大多数开发
者津津乐道的软件公司，许多软件公司都开始模仿Borland的TSR技术开发大量的TSR
软件。不过当TSR技术大量被运作之后。最后却造成众多的TSR软件彼此冲突，无法正
确地相互共存，这主要是因为许多TSR软件都使用了相同的快捷键来调出/关闭软件，
或是隐藏在相同的内存位置。我还记得，当时同时使用几个TSR软件时，必须遵照一
定的运行次序才可以正常使用。
为了解决这个扰人的问题，Borland开始广邀软件公司，想要以Borland为首制定TSR
的标准。如此一来，只要所有的软件厂商遵照Borland制定的标准，那么所有的TSR软
件就可以彼此正确地运行在PC之中。当Borland公布了这个想法并且发表了初步的TSR
标准规格之后，却立刻引起了Microsoft的紧张。因为当时TSR是如此的流行，Microsoft
害怕TSR技术由Borland主导之后会让Borland成为PC软件的霸主，进而严重影响Microsoft
想主宰PC的计划。
因此在Borland开始正式制定TSR标准之际，Microsoft便站出来反对Borland定义的TSR
标准，并且声明Microsoft将在未来的DOS操作系统中加入对于TSR的支持，因此没有
必要再额外制定TSR标准。当时的软件公司，包括Borland在内，都无法和Microsoft
对抗。在操作系统厂商表明了反对立场之后，Borland的这个构想很快便迫于形势而
放弃了。关于TSR的争议应该算是Borland和Microsoft之间的第一场战争。虽然在没
有引起太大的烽火之前便很快收场，不过也算是Borland和M1crosoft第一次真正的交
手。也正是由于这次的相争，让Microsoft惊讶于Borland快速的兴起，并开始正视
Borland这家在当时还算小的软件公司。
虽然在有关TSR的技术之争中Microsoft赢得了胜利，不过很奇怪的是，此后TSR软件
反而开始慢慢地退烧。除了一些少数的公用程序软件仍然使用TSR之外，之后便没有
什么重量级的软件是使用TSR技术开发的，这算不算是另一桩Microsoft介入之后搞砸
的技术呢？
最后再叙述一个从Borland老员工处听来的有趣故事。许多人一直想要知道：Borland
的总部在哪里？或是想要知道：为什么Borland会选择Scott Valley作为总部？事情
的经过是这样的：
当年Philippe Kahn和Anders Hejlsberg到美国准备开始创业时，由于没有资金，
Philippe Kahn就在西餐厅打工，负责端盘子的工作，而Anders Hejlsberg则努力的
在开发Turbo Pascal。
当Philippe Kahn存了一笔小钱之后，两个人便开始了创业大计。首先他们必须找到
一个公司的总部，可是要在哪里实现Philippe Kahn和Anders Hejlsberg心中的理想
呢？虽然当时他们住在L.A.附近，但是光凭Philippe Kahn存的一点小钱是绝不够在
L.A.大展鸿图的，因此Philippe Kahn和Anders Hejlsberg决定到比较偏远的地方试
试。于是这两位仁兄便开着Philippe Kahn的破车往南出发了。听说当Philippe Kahn
把车开到Scott Valley附近时刚好没有汽油了，眼看四周的环境觉得还不错，就决定
在这个地方展开Philippe Kahn和Anders Hejlsberg的创业之梦。就是这个决定让原
本默默无闻的Scott Valley在数年之后竟成为一个家喻户晓的高科技盛地。
和Borland的缘由
Turbo Pascal是我在大二、大三撰写作业时的最爱，几乎所有的作业都是使用Turbo
Pascal完成的。当然其时Horowise的Data Structure这门课也是使用Turbo Pascal
过关的，因此从那个时候开始，我便非常喜欢Borland这家公司，慢慢地也开始对Borland
有了特别的感情。
在我大二时，Microsoft推出了Microsoft Pascal，但是它和Turbo Pascal的确有一
段差距，我使用了一次之后便把它丢到垃圾桶。稍后Borland也推出了Turbo Basic
1.0。我记得这个编译器非常的棒，编译速度就和Turbo Pascal一样快，是一个非常
有前途的产品。但是不知道为什么它只有1.0，之后便和Microsoft Pascal一样消失
了。后来听说是Microsoft和Borland互相交换条件，Microsoft不进入Pascal的市场，
而Borland则退出Basic的市场。至于是不是真的确有其事，我就不得而知了。
我在大二初次接触到了C语言，第一本阅读的书便是王兴隆先生写的C语言书籍，也从
此开始和C语言结下了渊源。平生第一个使用的C编译器便是Lattice C，不知道还有
没有读者记得？当时使用两个5吋磁盘抽换以便编译C程序的情景，真是麻烦得不得了。
稍后Borland终于推出了风行天下的Turbo C编译器，从此之后Turbo C便成了我不离
身的工具，而Borland也通过Turbo C这第三项畅销产品迈向了世界前10名的项尖软件
公司。
当完2年的兵之后，我在中研院首次使用了C++语言。第一个使用的C++编译器则是Zortech
C/C++，这家公司稍后被Symantec收购成为Symantec C/C++的核心部门，这个故事稍
后再说明。后来Borland也推出了它的第一个C/C++编译器Turbo C/C++1.0，但是和
Zortech C/C++比较之后，我还是觉得Zortech C/C++比较好，因此就继续使用Zortech
C/C++。一直到Borland的Turbo C/C++2.0编译器推出之后，才逐渐成为C/C++语言的王
者，而我也像以往一样把Zortech C/C++换成了Turbo C/C++。
在我1991年到Georgia Institute of Technology念硕土时，终于使用自己的零用钱
49.99美金购买了生平第一套正版软件Turbo C/C++4.5，随后又购买了Borland
Pascal。在毕业前的一个Quarter，Microsoft推出了Microsoft C/C++6.0以及MFC 1.0，
由于MFC是第一个C/C++的Framework，因此也花了一些钱购买了一套Microsoft C/C++以
便学习MFC。但是在收到Microsoft C/C++之后，我却很失望，因为Microsoft C/C++
6.0仍然没有Windows图形集成开发环境，还是在DOS下的集成开发环境。而且以我的
眼光来看，MFC 1.0并不好用。Microsoft C/C++6.0的C/C++最佳化编译器在当时也是
一个笑话，不但产生的程序代码效率不好，甚至会产生错误的程序代码。许多IT杂志
也称Microsoft C/C++6.0是一个平庸的(Mediocre)产品。因此我就把它丢在一边再也
没有使用。在Microsoft C/C++6.0推出之后不久，Borland终于发布了Borland
C/C++3.0，而这套软件也开启了Borland雄霸C/C++编译器长达五六年之久的序幕。
Borland C/C++3.0推出之后，由于拥有第一个在Windows下稳定的图形集成开发环境，
而且它产生的最佳化程序代码也是Microsoft C/C++6.0望尘莫及的，因此，很快地几
乎所有的C/C++程序员都转而使用Borland C/C++3.0。那个时候几乎所有的公用程序
或是Shareware都是使用Borland C/C++开发的，许多硬件厂商的驱动程序也是使用
Borland C/C++3.0来撰写的。
1992年我取得Georgia Institute of Technology的硕士学位之后，最想进入的公司
便是Borland和Microsoft，不过最后我还是决定回台湾工作。在此时Borland也逐渐
进入了最巅峰的时期，因为Borland推出了Borland C/C++3.1。
Borland在Borland C/C++3.0获得空前的胜利之后，并没有松懈下来，因为Borland知
道Borland C/C++3.0还缺一个最重要的胜利因子，那就是如同Microsoft的MFC一样的
C/C++ Framework，因为Borland也看出了Framework将会是未来C/C++产品中最重要的
一环。不过Borland此时来到了一个重要的十字路口，那就是到底要自己开发一个和
MFC抗衡的Framework，还是直接采用Microsoft的MFC？如果要使用MFC的话，那么
Microsoft会愿意授权给Borland吗？如果Borland要自己开发Framework，那么势必要
花上一些时间，但是Borland想趁Borland C/C++3.0如虹的气势再下一城，以便彻底击
溃Microsoft C/C++。因此，最后Borland决定向一家叫White Water的公司购买一套由
这家公司开发的一个Framework，这套Framework便是后来鼎鼎大名的OWL的源流。而
Borland也因为向White Water购买了这套Framework，因而也引进了一个日后非常重
要的人物，那就是后来负责开发Delphi的一员大将--Zack Urlocker。
C/C++的光荣战役
Borland购买了White Water的C/C++ Framework之后，便更名为OWL(Object Windows
Library)，并且很快地推出了以OWL 1.0为核心的Borland C/C++3.1。由于OWL比当
时的MFC 1.0封装得更为完整且好用，再加入Resource Workshop可视化能力，以及
Borland C/C++3.1本身最强劲的编译器和集成开发环境，因此立刻风靡了全世界，
其受欢迎的程度更是远远的超过了它的前一版本Borland C/C++3.0。
Borland C/C++3.1的畅销，立刻让Borland在C/C++市场一举击溃Microsoft C/C++，
市场占有率超过了50%，是全球第一的C/C++产品，也把Borland推上了最高峰，成为
全世界第三大的软件公司。
在当时，我所工作的开发小组也立刻改用Borland C/C++ 3.1来开发Windows下的MRP
系统，而Borland C/C++3.1也是我使用过的Borland最稳定的C/C++版本之一。由于那
个时候一天到晚都使用C/C++工作，因此就有了一些小心得。稍加整理后我便投稿到
刚成立不久的《RUN!PC》杂志，也许是我的运气不错，《RUN!PC》很快发表了我的文
章。就在这篇文章发表之后，台湾的Borland分公司注意到了我，开始和我联络，并
且从此展开了我和Borland的互动。而Borland C/C++3.1也是第一套Borland免费送我
的软件，当然代价就是希望我多写一些Borland产品的文章。
接着Borland又计划推出Windows版的Borland Pascal。不过在Borland开发Pascal For
Windows时，当时(现在也还是)最具盛名的Charles Petzold(我看的第一本Windows
程序设计的书就是这位仁兄写的，相信许多人也是看他的书一路学来的)就说除了
C/C++之外，Borland不可能做出能够在Windows下执行的Borland Pascal。不过很明
显地，即使是Windows API的大师Charles也错了，Borland不但做了出来，而且
Borland Pascal For Windows还非常的畅销，当然Borland Pascal For Windows也是
后来Delphi的根基。
当时的Borland可说是不可一世，不但产品大卖，而且日进斗金。Borland在Scott
Valley豪华的总部也是在那个时候由Philippe Kahn大手笔地花了一亿多美金搭建的
(想想10年前的60多亿台币可以盖什么样的房子？)。不过也许是Borland太成功了，
因此也开始让Philippe Kahn渐渐地养成了好大喜功、目中无人的态度，这也种下了
Borland开始走向衰退的因子。
在Borland最强盛的时期，当然也就是Microsoft最痛恨Borland的时候，发生了一个
著名的事件和一个著名的虚拟人物。由于当时Microsoft的开发工具一直打不过Borland
的产品，因此在Microsoft的开发工具刊物上便出现了一个作者，不断地以文章嘲笑
Borland，这个作者的笔名是Buck Forland。由于这位作者的文章内容以及他的笔名
引起了当时Borland的不满以及大量Borland使用者的强烈抗议，稍后这位作者突然消
失。因此有许多人推测这个作者应该是Microsoft的某位工程师，由于一直无法打败
Borland的产品，恼羞成怒，因此才会以这个笔名来发泄。如果各位读者到现在还摸
不着头脑，不知道为什么这个笔名会引起轩然大波，那么请试着把Buck Foland这两
个英文字的第一个字母一对调就知道为什么了。现在各位是否会心一笑了？
■ 在Borland C/C++3.1大获成功之后，Borland却开始松懈了，并且开始走下坡路。
当然这有许多的原因，我所知的其中最重要的原因有数项：Philippe Kahn和当时
Borland C/C++的产品经理闹翻了。这位Borland C/C++的产品经理的名字是Eugene
Wang，Eugene是一位非常聪明的越南人。他一手把Borland C/C++带到了世界第一的
地位，并且在Borland C/C++3.1成功之后有了更伟大的想法，那就是想在下一个
Borland C/C++版本中完整地以OWL封装所有的Windows APl。因为OWL 1.0虽然比
MFC 1.0来得优秀，但是OWL的隐忧就是尚未完整封装所有Windows的APl。此外Eugene
还计划以OWL为核心，开发一个类似今日Borland C/C++ Builder以可视化组件为开发
方式的开发工具。请各位读者想一想，如果在当时Borland能够开发出这种C/C++开发
工具，那将会是一个多么可怕的产品，稍后Microsoft的Visual C/C++1.0只是能够在
集成开发环境中自动产生MFC的程序代码就立刻轰动了C/C++市场，造成了大量程序员
转入Microsoft的阵营。而且，即使是目前的Borland C/C++ Builder，使用的
Framework仍然是以Object Pascal为核心的组件Framework，而不是纯粹的C／C++程
序代码。如果当时Eugene能够做出他心中的下一版Borland C/C++，那么我想，到现
在Borland C／C++可能还是市场中第一的C/C++开发工具。
不过很不幸的是，Eugene稍后和Philippe Kahn发生了激烈的争执。一气之下，Eugene
离开了Borland。而Philippe Kahn则认为Borland C/C++的地位已不可动摇，因此也
没有想立刻开发下一版的Borland C/C++。这样一拖竟然浪费了将近2年的时间，更大
的麻烦是Microsoft可没有白白浪费这2年的时间。Microsoft Visual C/C++1.0在
Borland C/C++3.1发布两年之后推出，并且立刻获得市场好评。Visual C/C++不但在
编译器方面能够和Borland C/C++3.1相抗衡，在集成开发环境方面更大幅领先了Borland
C/C++3.1，还能够自动产生MFC的程序代码，再也不是昔日的吴下阿蒙。直到此时，
Philippe Kahn才从梦中惊醒而急于开发下一代的Borland C/C++4．0。但此时为时已晚，
C/C++的开发工具已经发生了剧烈的变化，Borland的C/C++开发工具市场从此就开始逐渐
地被Microsoft蚕食了。
Eugene在离开Borland之后，立刻被Symantec所网罗，稍后Eugene也在非常短的时间
之内为Symantec开发出了著名的Symantec C/C++。Symantec C/C++在当时被所有的技
术刊物评比为拥有最棒的集成开发环境和最有创意的C/C++开发工具，由此可见Eugene
的功力。不过Symantec C/C++稍后也终究不敌Microsoft Visual C／C++，这个故事
的原因在稍后"四大C/C++ 编译器之争"的章节中再详细地说明。最后听说Eugene跑去
做生意了，并且在前几年写了一本教导科技人员如何面试的书籍。一直很痛心Borland
失去了这么一位优秀的人材。我常常想，如果当初Eugene没有离开Borland，那么历
史可能就不是现在的这样了，Sign！！！
■ Philippe Kahn大手笔地花了400多Million美金买下了Ashton-Tate公司和dbase。
当时许多人都批评Philippe Kahn做了不值当的事情，因为Ashton-Tate不值这么多钱。
但是由于当时Borland多的是现金，因此Philippe Kahn也不在意。不过Borland逐渐
走向衰败的主因并不在此，而是在Borland买下了dbase之后，并没有立刻积极地开发
dbase For Windows，反而把dbase丢在一旁。Philippe Kahn会如此做的原因便是当时
Borland的另外一个和数据库有关的产品Paradox卖得也很好，因此Philippe Kahn并不
急于开发dbase For Windows。不过Philippe Kahn忘记了一件事情，那就是当时市场
上拥有大量使用者数目的dbase程序员需要一个好的Windows版dbase，但是Philippe
Kahn购买了dbase却不提供Windows版的解决方案，因此当稍后Microsoft以极小的代
价买下Fox这家公司，并且在数年之后推出FoxBASE For Windows，吸引了大量原先的
dbase程序员以及Paradox的程序员之后，Philippe Kahn才警觉事情不对而匆匆忙忙
地开发dbase For Windows。但是当dbase For Windows推出之后，Microsoft早已推
出了两个FoxBASE For Windows的版本，占据了大部分的市场，dbase For Windows其
势已不可为了。
■ Microsoft开始向Borland挖角。由于Microsoft在许多的开发工具战役中一直被
Borland打得灰头土脸，更何况Borland C/C++3.1几乎抢占了大部分的市场，因此
Microsoft便开始准备好好地对付Borland。但是由于其时Borland在编译器的技术领
域领先了Microsoft数年之久，Microsoft无法在短时间之内赶上Borland，所以
Microsoft决定使用最有效的方法立刻追上Borland的技术，那就是直接从Borland挖角。
结果，后来Microsoft的Visual C/C++小组有60％的成员是从Borland挖来的，这个举
动不但立刻让Borland流失了大量的优秀技术人才，也在数年之后造成了Borland控告
Microsoft的导火线。各位读者看到这里是否有什么感觉呢？不过我总觉得Microsoft
并不是光明正大地击败Borland，而是使用了不公平的竞争手段。
Philippe Kahn在这段时间不但让Borland C/C++被Microsoft Visual C/C++反败为胜，
也痛失了几乎所有dbase的市场，更浪费了大量的金钱，流失了大量的优秀人员。在
这些重要的因素之下，Borland已经不可避免地开始走下坡了。
我最后一次看到Philippe Kahn，是在1994年末于亚特兰大(Atlanta)参加国际
Conference时，还和他打了一声招呼。后来Philippe Kahn离开了Borland，另外创立
了StarFish这家公司，稍后StarFish也被Motorola并购。虽然Borland由于Philippe
Kahn一些错误的决策而逐渐地从巅峰开始走下坡，但是Philippe Kahn也不愧为一个人
物。因为Philippe Kahn能够和Bill Gates一直周旋数年之久，而同一时期的许多公司
(例如Lotus)都一一被Microsoft所击败，因此Philippe Kahn还是有一套的。此外
Philippe Kahn也是唯一一个拥有工程师特性的Borland CEO，Philippe Kahn仍然
重视技术产品和技术人员。但是Borland随后的CEO几乎都是Marketing、Finance或
是Sales出身的人，这真让我怀念以往以产品和技术为优先的CEO了。
看完了上面这段今人伤心的历史，再让我们看看当Borland受到Microsoft Visual
C/C++的强大冲击之后，如何思索反击之道。在这段历史中出现了令我敬佩的第一个
Borland技术工程师Carl Quinn。
Carl Quinn在Microsoft Visual C/C++1．0推出之后，立刻奉命开发一个能够和MFC
相抗衡的全新OWL，而Carl Quinn也是数年后JBuilder的JBCL Framework的灵魂开发
人物。Carl Quinn不但负责开发OWL，也为Borland在组件Framework的技术领域做出
了重要的贡献。由于Carl Quinn的投入，开启了OWL大战MFC、Borland C/C++缠斗
Visual C/C++数年精彩好戏的序幕。
Carl Quinn是我至今还记得并敬佩的人物，让我再一次的向他致敬，并且介绍他让大
家认识。
火线全开
Borland在开发工具市场和Microsoft激战之时，Microsoft和Lotus也正在电子表格工
具以及文字处理工具市场进行大战。这时Borland不思好好地集中资源开发新的开发
工具和数据库工具(稍后本书会详细说明Borland在数据库市场的战役)，也不甘寂寞
地投入了大量的资源进入这个惨烈的市场。也许是当时Borland太有钱了，或者是
Philippe Kahn的脑袋出了问题，居然决定进入这个Borland陌生的市场，更何况在
Borland投入时Lotus已现败象，Office市场已经慢慢地被Microsoft所一步一步地掌
握了。
Borland进入Office市场的第一个产品是著名的Quattro Pro电子表格。虽然Quattro
Pro是一个相当不错的产品，而且当时，由Borland C/C++编译器所开发的Quattro
Pro在执行效率上几乎是最好的，但是Borland没有想到使用电子表格的使用者是一般
的办公室人员，这些人注重的是方便性和功能性，而不是执行速度，这和开发人员是
不一样的。Borland以开发者的心态来开发电子表格工具基本上是走错了方向。因此
我记得在那段时间中，杂志评比Microsoft的Excel、Lotus的1-2-3和Borland的
Quattro Pro时，在功能方面领先的都是Excel和Lotus，在执行效率方面领先的则是
Excel和Quattro Pro。到了电子表格热战的末期，1-2-3甚至比不上Quattro Pro，因
此Lotus败走电子表格市场已是不可避免的结果了。
不过Borland虽然赢了1-2-3，但是和Excel仍然有一大段的距离，Microsoft一统电子
表格江山之势已不可动摇，因此最后Borland在损失了大量的资源之后，Quattro Pro
只能卖给Novell。
除了Quattro Pro之外，Borland也投入了很多的资源秘密地开发一个代号为Spring的
文字处理程序(Word Processor)准备和Microsoft的Word以及WordPerfect竞争，这可
能是许多人不知道的。但是这个产品最后仍然无法问市而胎死腹中，在文字处理市场
Borland不但浪费了时间，更虚掷了大量的资源。
Philippe Kahn在Office产品方面消耗了Borland大量的金钱和时间，却落得铩羽而归，
更连累了开发工具市场以及最有可能成功的数据库产品市场。
另外一个和Borland无关的故事是关于Microsoft Excel是如何兴起的。话说当Lotus
1-2-3最盛的时期，Microsoft一直在觊觎这个市场，但是苦于无法开发出一个能够
和1-2-3相竞争的产品。有一次Lotus举办了一个Lotus 1-2-3的技术研讨会，由当时
Lotus 1-2-3的首席工程师主讲。Microsoft知道了这个技术研讨会之后，立刻派出了
最好的程序设计师，现场询问Lotus是如何开发1-2-3的，并且趁机询问这位首席工程
师如何克服1-2-3在许多技术方面的难点，而这些困难处正是Microsoft的工程师无法
克服的。
当时，在现场中的Lotus首席工程师虽然知道这些人是Microsoft派来的，而且询问的
问题正是1-2-3许多关键的技术点。但是这位首席工程师凭借着多年的开发经验，认
为Microsoft不可能在短期之内追上1-2-3，因此就没有多作保留地回答了许多重要的
问题。没有想Microsoft的这些程序员也是非常聪明的人才，一经指点之后，立刻畅
然全通，在短短的1、2个版本之后不但马上追上了1-2-3，许多功能方面更是青出于
蓝，1-2-3便逐渐失去优势了。我想这位1-2-3的首席工程师一定很后悔当时回答了关
键的技术问题吧。
结论：千万不要小看Microsoft，他们是非常精于模仿的。也永远不要小看你的竞争
对手。
数据库市场的失误
Borland全盛的时期，事实上也是开发数据库产品最好的机会。因为在当时Borland手
握DOS最畅销的Paradox，并购了Ashton-Tate而拥有世界大部分dbase的市场，又取得
了Ashton-Tate从HP购买的真正关系数据库(RDBMS)--InterBase，可以说是当时全世
界数据库工具实力最雄厚的厂商。
当时的Oracle和Borland比起来，简直是小巫见大巫，而Sybase更不知道在哪里。如
果Borland能够好好地掌握这个机会，极力开发数据库产品，那么现在Borland就算不
是世界第一的软件公司，也将是世界第二的软件厂商。可惜Philippe Kahn并没有看
到这个从80年代末到90年代成长最快速的产品市场。说句笑话，如果当时Philippe
Kahn的死对头Bill Gates早一点说出"Information At Your Finger-Tip"这句话，点
醒Philippe Kahn数据库市场的重要性，那么Borland就可能是现在的Oracle了。
说到数据库市场，就不得不对Microsoft的眼光佩服，也不得不佩服Microsoft行销能
力的强悍。当Microsoft以FoxBASE For Windows强占了Windows开发者的数据库工具
市场之后，又了解到一般计算机使用者也需要使用简易好用的数据库管理工具，因此
开发出了更简易的Access。但是当时在类似的市场中，Borland的Paradox占有开发者
数据库大部分的江山，而一般使用者的数据库管理工具市场则由Lotus的Approach博
得先机。
Microsoft为了进入由Lotus Approach主宰的市场，采取了很多方法。我还记得在当
时Visual Basic 3的软件包中Microsoft附了一张优惠卷，只要800新台币就可以买一
套Access。这简直就是流血大拍卖。不过它的目标很明显，就是击败当时卖1万多元
的Lotus Approach。果然，Microsoft此招一出，Approach便被Access打得落花流水，
很快失去了市场，也很快地退出了市场。从此一般使用者的数据库管理工具市场便由
Access所独占。
但是Borland并没有警觉到Access会继续往开发者市场进攻，因此仍然没有加紧在
Paradox产品上的开发。Borland总觉得Paradox的市场地位是无法轻易撼动的，而且
Access的目标市场也不是Paradox的市场。
但是Borland忘记了Microsoft非常擅长模仿。在随后的Access版本中，Microsoft不
断地加入可程序设计的功能，因此也逐渐地吸引了一些Paradox入门使用者的市场。
再加上FoxPro For Windows又持续地强攻开发者数据库市场，Paradox终于在腹背受
敌之下逐渐败下阵来。虽然在末期Philippe Kahn对Paradox投下重兵，希望能够挽回
劣势。奈何时不我予，Paradox在奋斗了Paradox 6和Paradox 7的2个版本之后，终究
难逃失败的命运。
当时在看到Microsoft如何打击竞争对手时，我就和朋友开玩笑说，Microsoft有天下
无敌的三大绝招，那就是"打不过你就模仿你(这让我想起电影秘密客)。再打不过就
和你比流血，看谁流得久(这让我想起吸血鬼)。最后如果再不行的话，那就挖光你的
人(这让我想起电影Other People's Money)"。Lotus就在Microsoft的前两个绝招下
倒地不起，而Borland还算是功力深厚，连中三大绝招，虽然不像Lotus和许多其他公
司一样从此Bye-Bye，但也是受伤极重的了。
ODBC和IDAPI之争
当Microsoft逐渐地击败竞争对手、并且拥有了大部分PC数据库市场之后，便慢慢地
了解到掌握标准的重要性。此外，Microsoft为了统一各应用程序之间不同数据的存
取，开始制定存取数据的统一标准--ODBC。Microsoft更大的目的是为了准备和瞄准
下一场的大战，那就是PC上的关系数据库产品的市场。
当然，Microsoft要一统数据存取的江山，除了Borland不会同意之外，其时一心想从
Microsoft扳回一城的IBM也不同意。而Novell更是害怕，因为Novell怕Microsoft成
功之后，Netware会消失得更快。于是IBM、Novell和Borland以及一些其他的小厂便
聚集在一起，决定也制定一套存取数据的标准接口来和Microsoft对抗，这个制定的
数据存取标准便是IDAPI。这正式揭开了ODBC和IDAPI竞争的序幕。
不过IBM、Novell和Borland的结合很快就被证明是失败的，因为就像稍后说明的一样，
IBM在PC软件上的开发一直是三心二意，反反复复。因此当IDAPI 1.0的规格出来之后，
IBM这位老兄又失去了和Microsoft对抗的兴趣，于是退出了IDAPI联盟。至于Novell
就更不用说了。Novell对于和Microsoft竞争一向是"说说可以，真打不行"，一定要
找到一群厂商才敢和Microsoft对抗。Novell眼看IBM退出之后，也马上不战而降，很
快地就也退出IDAPI联盟，这个现象和稍后Novell对于和Borland秘密合作的
Appware/AppBuilder计划如出一辙，都是虎头蛇尾，草草收场。
在两个大同盟临阵脱逃之后，Philippe Kahn仍然不畏惧Microsoft的竞争，还是以
IDAPI 1.0的规格实现数据存取引擎，这就是我们现在使用的BDE/IDAPI和SQL Links的
前身。当时IDAPI 1.0的功能规格比ODBC 1.0好得多了。我记得Delphi 1.0使用的
BDE/IDAPI和SQL Links驱动程序也比当时慢得像乌龟的ODBC快得太多了。只可惜在
IBM和Novell退出之后，其他的小厂也是一哄而散。因此Borland只能靠自己独自和
Microsoft对抗。Borland能够以少量的资源一直对抗到Delphi 3的BDE/IDAPI才逐渐
地被ODBC追过，也算是非战之罪了，怪就只能怪Borland意志不坚的盟友们。
当然，由于IBM和Novell的行事作风如此，所以在稍后许多能够和Microsoft一较长短
的机会也因为如此而消逝，最后自食恶果，逐渐失去了PC的软件市场，再也无力和
Microsoft抗衡了。
^v^v^v^v^v^v^v^v^v
第二章 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的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++、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 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的
华丽军团经过了整军经武，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++竞争时每一个版本都有大幅的改
善。看来寡占的市场的确是不好的。
^v^v^v^v^v^v^v^v^v
第三章 传奇的开始--Delphi
"是惊世之作的Delphi让Borland重新站了起来，没有当初的Delphi，就没有今日的
Borland！"
"是Turbo Pascal诞生了Borland，但却是Object Pascal给予了Borland重生的机会！"
创造传奇故事的主角--Delphi
没有人会知道在两年后Borland C/C++会遭遇到这么大的失败，也没有人会预料到
Borland又会再次因为Pascal而东山再起。Borland奋斗史精彩的地方就在于每当似乎
要不支倒地之际，Borland的R&D人员就会创造出一个明星级的产品来拯救Borland。
在其他和Microsoft对抗的软件公司纷纷消失的时候，Borland却一次又一次地站了起
来。"打不死的勇者"这句话贴切地形容了Borland的韧性。Borland靠Pascal起家，通
过C/C++绽放光芒，进而达到了巅峰的状态，随后又再次靠着Pascal浴火重生。Borland
这个从C/C++跌倒，再通过明星工具Delphi重回战场的过程可以说是惊心动魄，其中更
牵涉到了Borland两位创始人Philippe Kahn以及Anders Hejlsberg相继离开Borland
的密闻，也激活了Borland逐渐转型的历史轮轴。对于Borland来说，这段发展史可以
算是非常关键的里程碑，更重要的是，Delphi的崛起也在软件工具业界产生了巨大的
影响。Delphi不但激活了Windows平台上RAD战争的序幕，开启了Windows平台主从架
构的改变，同时也对组件技术做出了巨大的贡献。直到现在，Delphi创造的组件技术
仍然深深地影响了JavaBeans以及.NET的组件思想和技术，这在稍后的内文中读者可
以逐渐地了解。而故事的起源便在1993年左右……
Delphi的发展起源
当Borland以Turbo Pascal获得了成功，并且令Charles Petzold等人跌破眼镜之后，
到了1992/1993年的Borland Pascal 7.x，Borland似乎已经把传统的Pascal开发工具
发展到了极限，再往下还能做什么呢？Borland Pascal在销售了数百万套之后，程序
语言的焦点已经从Pascal转移到了C/C++，Borland Pascal无法继续快速成长，进而
转入了递减的状况，Borland必须做些新的东西才能够延续这条产品线。
当时Borland Pascal产品的Architect，即Anders Hejlsberg，眼看Microsoft Visual
Basic的成功，觉得当时Visual Basic是比较初级的开发工具，是一个学习Windows
程序设计的好工具，但是尚无开发真正应用系统的能力。因此，Anders和Borland
Pascal的小组决定展开一个规模前所未有的项目计划，这个开发工具项目在一开始便
设定了数个目标，希望能够达成并且超越Visual Basic。这些初始的目标是：
● 延续Borland Pascal的传统，提供一个快速编译的开发环境
■ Borland/Turbo Pascal的高明之处便是由Anders使用汇编语言撰写的Pascal
编译器不但编译快速，而且能够产出极为有效率的机器码。当时的Visual Basic只是
解译器(Interpreter)，无法产生真正的执行机器码，因此在这一方面Borland决定要
远远地超过VB，但是Borland的挑战是要开发出一个编译速度能够媲美解译器速度的
新一代编译器。
■ Anders另外一个重要的决定便是改善Borland Pascal程序语言，让这个新的
开发工具程序语言具备面向对象的功能。这在当时是非常重要的决定，因为不但需要
大幅修改编译器，也正式将Borland Pascal超越Pascal之父对Pascal定义的结构，让
Pascal拥有现代语言最新的功能。虽然这个决定有很大的因素是因为Borland决定通过
面向对象的方式建立新一代的Framework和组件架构，因此需要程序语言方面的支持。
不过，这在当时整个信息界对于面向对象技术还很陌生的阶段，的确是一个很大胆的
决策。这个程序语言的决策虽然可以吸引专业人士的激赏，不过也可能会让许多程序
员无法跨越这个障碍。后来的发展也证明了这一点。
● 建立一个新的Windows Framework组件架构
■ 当时VB使用的组件是VBX。不过VBX架构非常的复杂，只能使用在16位的环境，
并且在可视化拖曳设计方面又不是很方便。因此Borland希望在OWL之后建立一个全新
的Framework，这个Framework能够让程序员快速开发Windows应用程序，并且完整地封
装Windows操作系统中的对象。此外，Borland也希望定义一个标准的组件架构，让使
用这个开发工具的程序员能够通过Framework和组件架构来开发各种组件，包括可视
化和非可视化组件。这个Framework就是后来的VCL(Visual Component Library)。在
这方面，Borland做得非常成功。如果各位读者有VBX的经验，就会知道当时，Microsoft
定义的VBX规格简直是一团混乱，根本像是拼凑出来的东西。在当时开发VBX组件痛苦
不堪，后来Microsoft也彻底放弃了VBX。
● 拖曳、可视化的开发环境
■ Borland的想法是开发一个全新的集成开发环境，在这个开发环境中程序员可
以使用可视化的方法拖曳Framework的组件来设计图形界面，再在其中的编辑器中使用
面向对象程序语言来撰写应用程序。
这个开发工具项目的名称就是：Delphi！
Delphi的核心成员
在Delphi决定开工之后，Philippe Kahn还不放心动用太多的资源来开发这个产品，
因为当时Borland正集中所有的资源，希望能够打赢C/C++开发工具一役。因此
Philippe Kahn一开始只答应拨给Anders四个开发人员，先进行产品雏型的开发工作。
因此，Delphi在当时被笑称为像Apple计算机一样，是在地下室开发的。
当时加入Delphi开发小组的当然就包含了Anders，第二人是Chuck Jazdzewski。其中
Anders负责撰写新的Object Pascal编译器以及核心程序，而Chuck则负责设计Delphi
使用的组件Framework，即VCL。在经过了6个月的初始雏型阶段之后，当Anders把开
发的结果呈现给Philippe Kahn看时，Philippe立刻被它所吸引。因为当时在Borland
内部也希望为Borland C/C++开发一个类似这样能够以可视化拖曳方式开发应用系统
的C/C++开发工具。没有想到在短短不到一年的时间内，Anders已经从基本的构想开
发出了雏型产品。于是Philippe马上批准了这个产品的开发计划，并且投入研发资源。
许多后来举足轻重的人才便是从开发Delphi项目培养出来的。当时在这个项目中，各个
重要的部分分别由下面的重要人员负责：
● Anders Hejlsberg：编译器，Object Pascal程序语言，产品架构
● Chuck Jazdzewski：Framework，组件架构设计/实现
● Allen Bauer：集成开发环境的开发工具，Open Tools API
● Danny Thorpe：RTL (Run-Time Library)
● Zack Urlocker：产品开发方向，产品规划
有兴趣的读者可以打开下面的链接，这篇文章是由Danny Thorpe(现在是Borland .NET
的Architect)撰写的，详细地说明了Delphi这个名称的由来以及开发的缘由。
http://community.borland.com/article/0,1410,20396,00.html
而批准Delphi的开发，则是Philippe Kahn在因为Borland营运不佳而辞去Borland CEO
之前做出的最重要而且正确的决策。没有Philippe Kahn的同意，便不会有两三年后
浴火重生的Borland。
大规模的开发行动和Philippe Kahn的下台
在Borland如火如荼地进行C/C++最后决战的同时，Delphi也在快速的开发之中。1994
下半年，Delphi 1.0几乎已经开发完毕，最后剩下的工作就是Beta测试的阶段。同年，
Borland决定为Delphi展开一项从未进行的尝试计划，因为Borland对于Delphi信心
满满。这个计划就是为Delphi进行前所未有的大规模测试，以确保Delphi的品质，避
免重蹈Borland C/C++发生的覆辙。Borland为Delphi发出了成千上万的测试版本，邀
请了广大的程序员为Delphi进行长期的测试。这可是空前绝后的，因为自Delphi 1.0
之后Borland再也没有任何的产品能够拥有这种气魄和规模。我记得在1994年底左右，
收到了来自当时Borland台湾产品经理张书良先生寄来的神秘圣诞节礼物。当时打开包
裹一看，是六七片磁盘，没有任何的文件和说明。张书良先生请我安装看看这个"东
西"，并且请提供一点意见。
在安装了这些"磁盘"之后，映入眼帘的是一个陌生的软件。"这是什么啊？"这是我当
时的第一个想法。后来玩玩此软件，发现乖乖不得了。不但大部分的Windows对象都
可以拉拉就产生程序代码，更绝的是编译应用程序的速度比使用Borland C/C++的编
译器快了数十倍，而且产生的是一个体积不大的原生EXE文件，执行速度更是媲美
C/C++的程序代码。这让我这个惯用C/C++的程序员当场傻眼。
"这怎么可能?"在我发出呓语般的声音之后，旁边的同事也觉得怪怪的，于是一个一
个地跑到我的计算机旁，看看我到底在做什么？其中当然包括了《Delphi学习手册》
的作者、也是笔者的好友李增坤先生。在大家玩了之后，每个人都急着拷贝我的
Delphi Beta版以便回家继续玩。后来李增坤先生更是玩得出神入化，还能够让Delphi
连接到当时相当封闭的Informix数据库(因为他们的开发小组是使用Informix的)，真
是厉害。他是我所知的第一个Delphi好手。
"这绝对是一个Super Star！"，当时我这样对张书良先生说。"真的?那么你可不可以
在杂志上帮Borland写一些介绍它的文章？"张书良先生对我这么说。就是因为这段对
话，让我开始和Delphi结下了不解之缘。至于我开始写Delphi书籍的缘由也是无心插
柳造成的。在台湾Borland准备力推Delphi 1.0之际，张书良先生准备亲自下海，也
亲自出面找到了旗标出版社合作出书，以推广Delphi。后来由于张先生工作太忙，因
此又找了我和李增坤先生帮忙。本来的约定是我和李增坤先生只负责一小部分，其他
的部分都由张先生完成。没有想到，签约之后张书良先生完全没有时间投入，因此只
好由我和李增坤先生完成《Delphi 1.0学习手册》。由于我和李增坤先生以前没有写
书的经验，投入撰写书籍的时间也不多，因此《Delphi 1.0学习手册》是台湾所有有
关Delphi 1.0书籍中最晚出的一本书，远远超过当时我们规划的时程。好在当时
Delphi 1.0的气势简直如星火燎原般的炙手可热，因此这本书还是卖得不错的。
1995年对于Borland来说是悲喜交加的一年。1995年1月11日，Philippe Kahn正式因
为经营不善而辞去Borland CEO的职位，不过Philippe Kahn仍然是Borland董事会的
成员之一。接任的Gary Wetsel的任务是大幅删减Borland的员工数，开始进行瘦身计
划。因为当时Borland的员工数是为营收500M美金的Borland所打造的，但是在1995年
Borland的营收已经下滑为不及200M美金的公司，而且一直在亏损之中，当时许多业
界人土都认为Borland已经撑不过1995年。不过1995年2月14日的情人节似乎一夜之间
改变了Borland的命运。
一炮而红的Delphi 1.0
1995年2月14日，是Borland永远会记得的日子，因为这一天是Delphi正式诞生的日子，
也是Borland扭转命运的转折点。由于Delphi先前大规模的Beta测试计划已经在全
球吸引了极大的兴趣和好评，信息业界也知道了Borland正准备推出一个跨时代的新
开发工具产品。当然，更重要的是全信息界也都在静观，这个产品是否真的好到能够
拯救Borland免于破产或是被并购的命运。决定生与死的日子终于在这一天揭晓。
1995年2月14日，也就是Borland在全球发表Delphi 1.0当天，我在Scott Valley会见
了当时的Delphi主舵手，产品经理Lance Devin先生。Lance是一位非常亲切、有活力
的人。Delphi在他的主掌之下，立刻在全球吸引了所有的焦点，当时媒体甚至称
Delphi l.0是VBK(Visual Basic Killer)。
Delphi 1．0发表之后，立刻造成了全球的狂卖。由于Borland并没有预料到Delphi的
反应会如此的好，因此一时造成了Delphi的全球大缺货。Borland从Borland C/C++3.1
之后已经很久没有享受过这么美好的滋味了。
在台湾，由于早已预料到Delphi将会是一个成功的产品，因此，台湾几乎和美国同一
时间发表了Delphi 1.0。而且台湾Borland不惜血本，直接从美国空运了少数的
Delphi，而台湾能够取得的Delphi的数量也只是从美国抢破头才拿到的少量货。台湾
Borland是在信义路的震旦行2楼会议室发布Delphi的。当天整个会议室几乎被塞爆了，
因为有太多急于想一睹Delphi庐山真面目的软件人员。我还清楚地记得在发布会结束
之后，会议室的门口排满了抢购Delphi的人潮。很快，所有的Delphi都被抢光了。记
得当时李匡正先生没有抢到Delphi 1.0，一直到2个多礼拜之后才取得。而我呢？很幸
运的是在Delphi 1.0发表之前，张书良先生就已经送了一套正式的Delphi 1.0
Client/Server版让我玩。当然我也迫不及待地把Delphi介绍给我当时的老板，希望
我们的软件包能够赶快使用Delphi来写Windows的版本，但是我的老板还是坚持使用
Visual Basic来写。后来我就离开这家公司，找寻愿意使用Delphi开发的软件公司。
当时Delphi在台湾书市造成的旋风真可用"洛阳纸贵"来形容，任何和Delphi 1.0有关
的书籍都立刻大卖，看得每一个出版社都眼红不已。我也还记得当时第一本Delphi
1.0的书是由波全出版社推出的。根据台湾最有名的天珑书局老板彭先生说，最热门
的时候一天几乎可卖500本的数量。我想这一本Delphi书籍应该是台湾有史以来销量
最好的Delphi书了，估计当时这本波全的书有数万本的销量。更夸张的是后来我居然
在天珑书局看到由2本影印的合集Delphi书籍，由塑料套包起来，要价是"1500"块台
币，居然也很快卖完，真是令人不可思议。这即使不是绝后，也绝对是空前的。
Delphi 1.0的成功也许早在信心满满的Anders的预料之中，看看下面在Delphi 1.0中
秘密内藏的Easter Egg中，Anders笑得如此的灿烂似乎就已经预见了Delphi光明的未
来。
Delphi 1.0有多成功呢？根据非正式的统计，Delphi 1.0当时在全球狂卖了50多万套，
这实在是一个惊人的数字。读者如果没有什么概念的话，那么我可以举一些例子来
比较一下。Borland最成功的Borland/Turbo C/C++系列卖到了3.1最巅峰的时候，全
球的销量才超过100多万套，这可是累积了数年、数个版本后才达到的套数。而Delphi
一个版本就到达了C/C++几乎一半的销量，从这就可以知道当时Delphi有多成功了。
Delphi 1.0的大卖，立刻拯救了财务困难的Borland。Delphi的收入不但让Borland立
刻再投入更多的资源到Delphi开发小组，以准备下一个版本的开发，也让当时Borland
内部的Latte(就是后来的JBuilder)小组获得了更多的研发资源，成就了数年后JBuilder
再次接棒；把Borland推向另一个高峰。
再见了，Borland创始人，Philippe Kahn
1995下半年，Borland发生了一件重大的事情，那就是Philippe Kahn正式被逐出他一
手创建的Borland。这真是令人震惊又难过的事情，相信许多关心Borland的读者都知
道这件事情。但是为什么Philippe Kahn会被踢出Borland董事会、又离开Borland呢？
这可是一个秘密。
事情都是从Philippe Kahn辞下Borland的CEO后开始发生的。在Philippe Kahn被逼下
CEO之后，他觉得Borland的一些开发方向他并不是很认同，因此在外面又开了一家新
的公司StarFish，从Borland买走了SideKick、DashBoard等产品，并且开始研发移动
和无线等方面的软件。
1995年Java兴起之后，Philippe Kahn觉得Java很有前途，并且希望结合Java以及移
动和无线软件技术。其时Borland内部也在开始研发Java的产品，包含了代号是Latte
的Java开发工具以及Java的JIT编译器等技术。而Borland没有预料到，由于Java的萌
萌芽竟会造成Philippe Kahn和Anders的离开以及Borland Visual dBase小组的解体。
话说在Borland于Java方面逐渐有了成果之后，Philippe Kahn的StarFish公司也开始
步上轨道。1995年，Philippe Kahn眼看Borland内部Java的人才素质精良，于是就开
始想挖一些好手到自己的StarFish公司。在Philippe Kahn的挖角动作愈来愈大之后，
Borland的董事会终于无法忍受Philippe Kahn这种挖Borland墙角的做法。于是，
Borland的董事会成员一致投票决定，将Philippe Kahn逐出Borland的董事会和
Borland。这对于Philippe Kahn是一个极为重大的打击，Philippe Kahn被迫离开了他
一手创办和心爱的Borland。即使后来Philippe Kahn的StarFish经营得不错，以致后
来由Motorola以数千万美金并购了StarFish，让Philippe Kahn大大地赚了一笔，但是
他仍然无法释怀，也永远无法忘记Borland给他的成功、光荣、骄傲和屈辱。虽然
Philippe Kahn一直想像苹果计算机的Steve Jobs一样有朝一日能够重返Borland，但
是，很显然Philippe Kahn没有Steve Jobs那样的运气，Philippe Kahn一直无法完成
这个愿望。
Anders的计划以及Zack的想法
在Delphi 1.0大获成功、如日中天之后，雄心勃勃的Anders立刻开始了下一版Delphi
的开发计划。此时Delphi研发小组的资源更多，因此可以做更多的东西。不过，在1995
年Delphi 1.0推出之后，信息业界有了几项重要的改变，那就是随着Microsoft
Windows 95的成功，企业使用Windows平台开发应用系统已经成为既定的趋势，再加上
当时数据库市场的快速发展，因此许多企业开始在Windows平台寻找Client/Server的
解决方案。正由于这些需求快速而大量的兴起，造成了当时PowerBuilder和Gupta这两
个主从架构开发工具的盛行。当时，PowerBuilder是Window平台下占有率超过50％的
主从架构开发工具，而Gupta则拥有超过30％的市场。这真是可怕，因为光是两个工具
就占据了80％多的市场。由于当时主从架构几乎由这两个工具所寡占，因此，
PowerBuilder和Gupta的价格相当昂贵，我记得当时一套PowerBuilder要价40几万新台
币，而Gupta也要30几万，真是令人无法相信。
在Microsoft方面，由于Delphi 1.0的成功，给了VB相当大的压力。因此Microsoft在
Delphi 1.0推出之后立刻也推出VB 4.0正面迎战。VB 4.0强调的重点是VB应用程序也
可以编译成可执行文件，不过，由于VB 4.0的编译器品质尚不成熟，编译出来的效果
并不好。再加上它的臭虫非常多，因此VB4.0算是一个相当不成功的产品。正由于这
些因素，在当时也传出了VB双数版本品质不如奇数版好的传闻。不过，在当时由于
PowerBuilder和Gupta的获利非常丰富，而Microsoft也看到了主从架构将会是未来数
年重要的信息架构，因此VB 4.0开始，Microsoft也开始逐渐为VB加入更多开发数据库
以及主从架构的能力，并且搭配Microsoft的ODBC规格向主从架构市场进攻。
Anders在Delphi 1.0成功之后，曾经接受媒体的访问，叙述他心中的Delphi 2.0想做
的功能。当时Anders就说他希望为Delphi加入Garbage Collection的功能，因为
Object Pascal在建立对象方面是使用Heap-Based的方式，因此为了减少Delphi程序员
可能发生的错误并简化Delphi程序代码的撰写，他希望加入Garbage Collection。现
在的Microsoft的．NET就内建了Garbage Collection的功能，而这个想法在7年前便已
经存在于Anders的脑中了。
除了Garbage Collection之外，Anders也想为Delphi加入更多Stack-Based的能力(是
巧合吗？.NET的IL也是Stack-Based的语言)，并且持续地改善Delphi的编译器，加入
更多的编译器最佳化功能，让Delphi的程序代码执行速度能够超越C/C++。
从Anders的想法中，读者应该可以感觉到Anders想做的都是属于比较语言、系统和低
阶方面、影响层面较大的功能。但是，由于信息市场是逐渐走向主从架构，因此
Zack Urlocker等人则希望Delphi 2.0能够在主从架构方面进行大幅的强化，再搭配
Borland力倡的BDE/IDAPI技术，以便和PowerBuilder/Gupta等竞争，进入获利较为丰
富的工具市场，这是第一次Anders和Zack意见分歧的时间点。
后来Delphi研发小组达成了共识，那就是下一个版本的Delphi将由Anders在编译器方
面主导，为Delphi开发一个真正的32位编译器，而且具备最佳化的功能(因为
Delphi 1.0是16位的开发工具)。但是Delphi 2.0也将大幅加入主从架构的功能，并且
通过BDE/IDAPI提供连接各种RDBMS的驱动程序，再由Chuck改善VCL架构，提供更为强
劲的数据感知组件能力，让Delphi 2.0正式具备和PowerBuilder/Gupta竞争的本钱。
这也埋下了日后PowerBuilder/Gupta这两个工具备受VB和Delphi强大的压力、终至快
速衰退的命运。
由于Delphi 2．0开始确定走向主从架构和具备开发大型系统能力的方向，因此Anders
没有多余的资源可以实现他的理想，再加上和Zack在产品发展方面日渐出现歧见，这
些都是间接造成日后Anders离开Borland的因素。
Delphi 2.0，进入32位世界的开发工具
在Anders完成了Delphi 32位的编译器而且BDE/IDAPI小组也实现更多连接RDBMS的驱
动程序之后，Delphi 2.0便已经准备好出征了。Delphi 2.0在推出之后果然也非常成
功，Anders亲手打造的32位编译器不但编译速度奇快，编译出的应用程序品质更是无
话可说。在当时，Delphi 2.0产生的执行程序代码屡获专业媒体和实验室的评比大奖，
尤其在整数运算方面，更是比VC++执行得还好。在一般应用程序方面，也和VC++的
程序代码不相上下。整体来说，只有在浮点数方面落后VC++。这也是后来Borland编
译器小组和Anders激活Borland下一代编译器项目的原因之一，目的是为C++Builder
和Delphi开发一个共享的后端最佳化编译器。不过很可惜的是，Anders稍后离开了
Borland，没有参与完成这个最佳化编译器，否则Borland的编译器应该会比现在更具
威力。
Delphi 2.0如同Delphi l.0一样大获成功，因为当时许多想在Windows NT下开发纯32
位应用系统的程序员都愿意使用Delphi 2.0，更不用说一些企业的开发者，在不愿意
忍受PowerBuilder/Gupta等使用脚本语言执行应用程序的缓慢情形下，许多
PowerBuilder/Gupta使用者都转而使用Borland的Delphi，这是Borland继当初
Borland C/C++3.1之后再次打入企业市场。Delphi 2.0和Delphi 1.0的总销量也超过
了一百万套。在全球的市场中，Delphi在欧洲、亚洲和中南美洲都非常的成功，反而
在北美的市场表现平平。由于Delphi表现得非常抢眼，给予了VB和PowerBuilder巨大
的压力，因此Microsoft和Sybase在Delphi 2.0推出之后，也纷纷地准备推出VB 5.0和
PowerBuilder 6.0，正式揭开了RAD工具最后的生死战。
在Delphi 2．0顺利推出之后，很不幸的是Lance也离开了Borland。接手Delphi产品
经理的是Ben Riga。要怎么说这位加拿大的仁兄呢？Ben Riga也是很亲切的人，但是
我当时向他建议的许多Delphi发展方向，这位仁兄都没有反映在Delphi的产品中。
例如我在3.0时便强烈建议Delphi应该在Web方面投入更多的努力，在Delphi中实现类
似当时IntraBuilder的能力，提供可视化的方式开发Web应用系统，也就是像现今的
Developer Express的ExpressWeb Objects组件组，或是IntraWeb组件组。如果在当
时的Delphi 3或是Delphi 4便能够有这种组件组，那么Delphi的Web能力将是No.1，
更不用说对于Delphi的销量会有多大的帮助。可惜笔者人微言轻，Ben并没有把这个
重要的功能放人Delphi的产品开发规格中。一直到现在，Delphi 6/7才认真地考虑这
个需要，虽然时间已经晚了，但是如果真的做得好的话，也比没有好。
RAD殊死战
在Delphi和VB相继进入主从架构的世界之后，便和PowerBuilder有了更激烈的竞争。
在Delphi 2.0出版之后，PowerBuilder面临了更大的挑战。因为VB在易于使用和
Microsoft的努力之下仍然呈现成长的趋势，但是PowerBuilder在许多场合却是直接和
Delphi竞争。在Delphi 2.0推出之后，Borland也很快查觉到许多Delphi的使用者是从
PowerBuilder转来的，于是当时Borland内部便拟定了置换PowerBuilder计划，希望能
够持续从PowerBuilder手中抢得更多的市场占有率。
Delphi 2.0的纯32位编译器以及执行速度一直是许多人喜欢的，这也对PowerBuilder
带来了压力，因为许多PowerBuilder的使用者，特别是软件公司对于PowerBuilder使
用的语言PowerScript执行缓慢而不悦，但是却喜欢PowerBuilder的DataWindow。因
此在当时Sybase便宣告将为PowerBuilder开发一个编译器，以增加PowerBuilder应用
程序的执行速度。不过Sybase并没有在Delphi 2.0之后的PowerBuilder 5.0实现出来，
一直要到PowerBuilder 6.0才推出PowerBuilder编译器，不过问题仍然多多。
当时我曾经仔细地观察台湾参加Delphi发布会的使用者以及参加PowerBuilder的使用
者，发现了一个很有趣的现象，那就是一开始参加Delphi(1.0/2.0)的使用者几乎都
是工程师，很少有DB Center的信息人员或是信息经理。而去PowerBuilder的使用者
则甚少工程师，大部分都是穿着体面的DB Center的信息人员或是信息经理。不过这
个情形在Delphi 2.0之后逐渐改变，因为当Delphi慢慢地被企业接受成为开发工具之
后，也有愈来愈多的信息主管人员出现在Delphi的发布会中。
下图是我早在1999年便绘制的资料，从这个Slide中读者可以发现Delphi、VB和
PowerBuilder的竞争是一个版本对应一个版本的。每当竞争对手推新的版本之后，另
外的竞争对手都会立刻推出相对应的竞争版本。但是在Delphi 2.0之后，PowerBuilder
便开始逐渐无法同步跟上Delphi和VB的竞争脚步，差距也愈拉愈大。
基本上Delphi、VB和PowerBuilder的竞争在Delphi 2.0时期是最为激烈的，在Delphi
3.0和VB 5.0之后大势已定。PowerBuilder已经定位成数据库开发工具，无法像Delphi
和VB一样成为Windows平台中通用的开发工具。因此PowerBuilder的使用者群组便逐
渐缩减到DB Center或是信息室的使用者。这个现象当时在台湾非常的明显，因为大
多数的软件开发厂商、软件包厂商或是项目厂商逐渐地舍弃PowerBuilder，不是选择
使用VB就是选择使用Delphi。在Delphi 3.0之后，Windows平台的主从架构开发工具
市场已经是VB第1，Delphi第2，而PowerBuilder退到第3，并且和Delphi/VB的差距愈
来愈大。经过了3年的激斗，传统主从架构开发工具PowerBuilder和Gupta仍然不是
Microsoft和Borland的对手，即使PowerBuilder曾经拥有超过世界50％的占有率。当初
Sybase也没有预料到在并购了PowerBuilder之后，这么快就损失了大片的江山。不过
比起Oracle和Informix来说，Sybase下的本钱还是比较划算的，因为同时竞争的Oracle
Developer 2000早已只能送给Oracle数据库的使用者。而Informix的主从架构开发工具
Neon更是凄惨，在出了一个版本之后，由于体积庞大，执行缓慢，又臭虫成堆，还没上
场竞争，就被丢人垃圾桶了。这对当时所有投入大量资源开发主从架构开发工具的软件
厂商来说，都是受伤不轻，当然除了Borland和Microsoft之外。
PowerBuilder和Gupta数年辛辛苦苦建立起来的主从架构王国，只经过短短的1、2年
就被VB和Delphi所鲸吞蚕食是有许多原因的。PowerBuilder和Gupta着重在高价、专
有的主从架构市场，却不知主从架构已经逐渐成为一般信息架构应用主流，大量的程
序员需要的是价格合理、功能齐全的开发工具。PowerBuilder和Gupta价格的奇高和
功能的缺失，在VB和Delphi加强主从架构的功能之后便逐渐地浮现出来。此外
PowerBuilder和Gupta当初风行的一个重要因素是提供了连接到各种RDBMS的驱动程序，
以提供开发数据库和主从架构应用系统的能力。但是当VB和Delphi都分别提供了ODBC和
BDE/IDAPI技术连接更多的数据库服务器之后，PowerBuilder和Gupta的优势也就不再
了。另外一个关键性的因素是PowerBuilder和Gupta一直无法成为大众化的开发工具。
除了DB Center和企业之外，PowerBuilder和Gupta无法被大量的ISV、商业软件包厂商、
一般工程师、甚至是学生使用来开发各种不同的应用系统。因此PowerBuilder和Gupta
只能在特定的软件族群中使用，限制了可能成长的潜力市场。
最后我认为最重要的原因是Sybase和Gupta在面对Microsoft和Borland这两个非常精
于实现开发工具的厂商时过于轻心，反应的速度太过于缓慢，以致PowerBuilder和
Gupta除了在数据库和主从架构功能之外，其他的功能都太过阳春。特别是在Java逐渐
兴起之后，PowerBuilder和Gupta最后跨平台的诉求也在瞬间瓦解，因此失去市场也是
不可挽回的命运了。
Borland C++Builder的诞生
在Delphi l.0/2.0大获成功并且对Borland产生了巨大的收益之后，来自Borland
C/C++使用者的需求，即要求Borland也推出一个C/C++版本的呼声也愈来愈强烈，到了
Borland无法忽视的地步。不过这对Borland来说，却是一个相当伤脑筋的事，因为
Delphi是用Object Pascal写的，如何转成C/C++？如果要开发C/C++版的Delphi，那么
Borland C/C++的产品线要如何处理？因此这也在Borland内部起了极大的争议，这又
是另外一个故事了。不过不可否认的是，Delphi 1.0/2.0的成功正是促成了Borland
C++Builder面世的主要动力。
争执的开始
Delphi 2.0的再次重大成功仿佛为Delphi研发小组注入了一支巨大的强心剂。Delphi
研发小组迫不及待地要开发Delphi3.0，以便趁胜追击，进一步的拉近和VB的距离，
并且再次给予PowerBuilder/Gupta重击，以便从PowerBuilder/Gupta取得更多的市场。
在Delphi 2.0推出之后，根据当时Gartner Group的调查，主从架构开发工具的第
一名仍然是PowerBuilder，第二名是VB，而第三名则是Delphi。Gupta的市场占有率
快速地下滑，已经无法进入前三名的占有率了。不久之后Gupta改名为Centura，希望
力挽狂澜，但是仍然无法改变市场的现实，并且逐渐淡出主从架构的开发工具市场。
这对于VB和Delphi来说都是重大的胜利，因为VB和Delphi在短短的一两年之内就几乎
瓦解了PowerBuilder/Gupta在主从架构市场数年经营的优势。虽然PowerBuilder还暂
时维持第一的占有率，但是已经从50％几萎缩到了40％，而且还在不断的下滑之中。
PowerBuilder在VB和Delphi的强烈进攻下岌岌可危，产品价格也在快速地滑落之中。
不过在Delphi 3.0的功能会议中，Anders和Zack却再次发生了强烈的争执，因为这两
个Delphi的灵魂人物对于Delphi 3.0的走向出现了不同的看法。其时由于Microsoft
的COM/DCOM等技术逐渐成熟和受到愈来愈多的使用，因此Anders希望Delphi 3能够充
分地支持开发COM/DCOM的技术，并且提供比VB更方便、比VC更强大的能力。为了实现
这个想法，Anders力邀Alain Lino Tadros加入Delphi的研发小组。为什么Anders会
找上Alain呢?这是因为Alain曾在1996年BorCon的研讨会上以惊人的技术写了5000多
行的程序代码，把VCL组件直接变成COM对象。Anders在BorCon上知道之后，立刻有一
个想法，那就是如何能够延伸Alian的技术，如果通过一种方法便能够把所有或是大
部分的VCL组件变成COM对象以及COM Container的话，那将是多奇妙的事情。如此一
来Delphi的研发小组也不需要为实现COM/DCOM的功能而大费周折了。而Anders的这个
想法也促成了后来Delphi 3中IVCLComObject接口和技术的诞生，直接把VCL转换为COM
对象的神奇功能。
除了邀请Alian之外，Anders也计划直接修改Delphi的编译器，让编译器能够直接处
理COM的参考计数值(Reference Count)，免除Delphi程序员的麻烦，并且提供有效的
执行码。如果依照当时Anders的想法并且把Delphi 3依此实现出来的话，那么Delphi
将会是一个比Microsoft工具更好的COM开发工具。
不过Zack却不认为Delphi 3应该把这么多的资源花在支持COM/DCOM上。虽然Zack同意
Delphi 3必须对COM/DCOM有好的支持，但是他认为Delphi 3应该在Delphi 2的主从架
构获得了胜利之后，继续往更高阶的方向努力，那就是分布式架构，以便把Delphi塑
造成能够开发大型企业的开发工具，把Delphi打入获利丰富的企业市场。因此Zack和
当时Borland开发工具部门的负责人Paul Gross激活了所谓的Golden Gate计划，希望
提供Delphi强大的中介引擎功能，因此Borland并购了出版Entera中间件的公司，让
Delphi能够通过Entera连接到后端大型的系统，希望大型企业能够使用Delphi开发客
户端的应用程序。
由于Golden Gate计划得到了Borland高层的支持，因此Delphi 3的发展方向很快便朝
向分布式技术前进。虽然COM/DCOM的支持也在产品的计划之中，但是并无法做到像
Anders所想要的境界。由于Anders的理想无法被接受，因此在Delphi 3的发展中后期
阶段，Anders并没有介入太多Delphi 3的开发工作。
在Delphi 3正式发表之际，Delphi的研发小组很巧妙地平衡了COM/DCOM和分布式技术
的功能，也让Delphi 3成为Windows平台中第一个提供分布式开发的开发工具。而
Delphi 3当时使用的Marketing Slogan以及产品诉求的重点也是"Component Foundry"，
意谓Delphi 3可以轻易地建立VCL组件以及COM/DCOM/ActiveX组件。
Delphi 3推出之后，Delphi应该算是到达了巅峰的状态，销售数字也非常的亮丽，已
经超过了Borland C/C++3.1的销量，而Borland也有了稳定的收入。但是人无远忧必
有近虑，后来发生的数件大事几乎让Delphi重演当初Borland C/C++4．0的历史覆辙。
不知道读者看到这里有什么想法？我认为COM/DCOM和分布式技术都是重要的，后来的
事实也证明分布式技术是Delphi的强项之一，而应用系统架构也逐渐走向分布式多层。
不过没有像Anders的想法把Delphi塑造成无敌的COM/DCOM组件开发工具相信也是许
多人的遗憾。
在Anders逐渐不介入Delphi 3的开发之后，随后发生的两件关键的事情便注定了
Anders Hejlsberg继Philippe Kahn离开Borland的命运。
天才的损失和新英雄的接棒
在Anders和Zack对于Delphi的走向逐渐出现了歧见之后，Anders便没有再主导
Delphi 3.0的开发，反之Zack在Delphi开发小组中的角色却日益重要，后来几乎是
Delphi 3和Delphi 4的主要领导人。为什么Delphi的Architect Anders会慢慢地淡出
Delphi的核心呢？这和Philippe Kahn离开Borland也有重要的关系。
英雄落难
Philippe Kahn和Anders共同创造了传奇的Borland，两人之间有着浓厚的感情。在
Borland工作时，对于Anders任何的想法和计划，Philippe Kahn都是不遗余力地支持。
也正是这个重要的支持力量，才有随后极为成功的Borland Pascal以及Delphi的问世。
但是在Philippe Kahn离开Borland之后，Anders再也没有了这股来自最亲密战友的强
力支援。1997年，Borland新的CEO Delbert Yocam在掌握了大权之后，Borland整个
公司开始走向第二个重要的转变，Delbert对于Borland产品的开发和趋势也有了不同
于Philippe Kahn的看法。当Java在1996年逐渐快速发展之后，睿智的Anders也看到
了Java成功的未来。因此在Anders不再积极参与Delphi 2/3的开发工作之后，他非常
希望能够主导Borland Java开发工具的开发，期望能够像当初的Delphi 1.0一样，为
Borland再次开发出全世界一级的Java开发工具。
不过，由于当时Delphi是Borland最重要的收入来源，高层仍然希望Anders继续在
Delphi产品线上投入全力，因此当时的Borland CEO Delbert Yocam并没有批准Anders
的请求。Borland的下一个重要的开发工具JBuilder，当时的产品开发名称为Latte，
仍然交由其他小组负责。依据我的推想，由于当时Anders对于Java已经有许多的想法，
因此才会有后来的VJ++以及C#，这些产品和程序语言的许多特性想必已经在Anders的脑
中存在了一段时间了。
Delbert没有允许Anders带领Latte开发小组，但Anders仍然没有放弃他的新计划。也
许是Anders注定和Borland的缘分已经到了尽头，这个时候正好Microsoft展开了有史
以来对Borland最大的挖角行动。在Anders无法在Borland取得满意的支持之后，
Microsoft提供的优厚条件顿时对Anders产生了致命的吸引力，从而造成了Borland无
法挽回的遗憾。
虽然Anders没有显赫的学历，无法获得Turning Awards(即图灵奖，信息科学界最高
荣誉的奖项，等同于诺贝尔奖)。但是我认为Anders的实力和贡献绝不输于任何一位
Turning Awards的得奖人。Anders是最好的信息实践型人物，在2001年，他终于获得
了信息界最具权威的信息刊物Dr. Dobbs' Journal颁发的Excellent Programming
Awards，以表彰Anders为信息界做出的卓越贡献。我想Anders应该是许多本身没有高
学历或不是计算机信息科系出身的优秀程序员最好的效仿对象。
Anders Hejlsberg这位不世出的软件天才，是目前全世界最顶尖的软件技术人员之一。
论实现技术，Anders可能是目前的第一高手，因为他精通程序语言、编译器技术、开发
工具、Framework以及系统架构。我虽然知道许多软件界重要的人物和好手，但是尚
不知有任何人能像Anders一样在这么多领域都能成为大家。下面是笔者整理出
Anders Hejlsberg到目前为止重要的功绩、贡献以及获颁的重要大奖：
" 和Philippe Kahn共同创办Borland
" 开发出Turbo Pascal，当时首创的In-Memory Compiler震惊了全世界
" 开发出全世界最畅销的Pascal产品，Turbo Pascal(这是许多信息人员学习Pascal
和Data Structure使用的经典产品)以及Borland Pascal。Turbo/Borland Pascal合
计销售超过了数百万套。Dr. N. Wirth(Pascal语言的创始人员)也应该向Anders致敬，
表达Anders对于Pascal语言的贡献
" Anders使用汇编语言撰写编译器，其功力无人能出其右。创造出了全世界速度最快、
品质也是一流的Pascal编译器。在Anders离开了Borland之后，几乎没有人能够修改
Anders的编译器
" 开发出影响深远的Delphi这个伟大的RAD工具
" 开发出VJ++语言
" Microsoft .NET的Architect
" Microsoft颁授Microsoft Distinguish Engineer大奖
" 发明C#这个又将造成重大影响的语言
" 获颁2001年Dr. Dobbs' Journal的Excellence In Programming大奖
一个人一生能够做出几件让全世界都津津乐道的事业呢？Anders却成就了无数PC界伟
大的功绩，并且在程序语言、编译器、开发工具以及Framework方面都有重要的贡献。
PC软件界因为有了Anders而精彩、丰富了许多，也创造了许多令人惊叹的故事。更
棒的是Anders现在仍然在继续贡献他惊人的天分，就让我们拭目以待，看看Anders还
能创造什么功迹吧。不过，不管以后如何，相信Anders应该是大部分软件人员希望学
习的目标。Anders的功力也是大部分软件人员一生企望能够达到的境界。
在2002年Borland Developers' Conference中，Anders Hejlsberg是排名第一的
Keynote Speaker，尚在Java的创始人James Gosling之前。根据现场同时聆听这两场
Keynote Speech的听众报道，Anders的Keynote Speech是非常精彩的，而James的
Keynote Speech则相对的枯燥，许多人因此而提前离席。而且Anders在开始进行
Keynote Speech之时，便获得了现场所有听众起立鼓掌致敬，看来，在大多数Borland
开发工具使用者的心中，Anders Hejlsberg是永远的巨星。
Microsoft的挖角和Anders的离开
Anders在不介入Delphi的开发、并且无法主导Borland Java开发工具开发的情况下充
满了挫折感。没有了Philippe Kahn的强力支援，Anders虽然是Borland最顶尖的技术
人才，却也无法对抗Borland管理阶层的力量。当然这也是从Philippe Kahn离开了
Borland之后、Bodand开始转型有关，这在稍后Borland的转变一文中，我会作详细的
说明。
虽然Anders在Borland遇到了挫折，但是对于Microsoft来说这却是千载难逢的好机会，
在此时Microsoft展开了大规模的挖角行动，而且是明目张胆地进行，正是由于
Microsoft如此大胆的行动，因此也造成了不久之后Borland对于Microsoft的法律控诉。
这次的挖角行动中，Microsoft同时锁定了数个Borland最杰出或是重要的人物，当然
Anders是名列第一的挖角对象。时值1996年，Microsoft终于展开了行动，使用的方
式是最直接的攻击。Microsoft直接派遣加长型的大轿车到Borland大门口找Anders吃
饭，第一次Microsoft开出了年薪百万美元以上的条件。不过在Borland知道了这件事
情之后，也很快进行了加码的动作，因此Anders并没有对Microsoft进行响应。
Microsoft在苦等无应、按捺不住之下，很快就再次用大轿车找Anders。这次Microsoft
提出了两百万美元以上的条件，希望Anders能够首肯。对于这次的喊价，Borland可有
点为难了，因为两百万美元不是笔小数目，这已经比当时Borland许多副总裁的年薪还
高。此外，如果Borland答应也加到两百万以上，那么是不是Chuck也要如此加码？其
他的Delphi R&D小组要如何调整？这些都是非常棘手的问题。
不过Borland很快找到了解决的方案，那就是允许Anders从每一套卖出的Delphi版本
中抽取一定数量的版权费。如此一来Delphi卖得愈好，Anders便能取得愈多的回馈。
不过就我的了解，Anders注重的并不是金钱上的问题，因为在Borland创立的初期，
由于Turbo Pascal的编译器都是Anders撰写的，因此当时Anders也是卖一套Turbo
Pascal就可以抽取版税的。依照Turbo/Borland Pascal全世界销售数百万套来算，
Anders早就是富翁了。薪水多一点，少一点并无所谓，Anders心中想的是自由发展的
空间。在Borland提出了Delphi的随版抽税，再加上Microsoft并不知道Anders真正想
要的东西，因此Anders仍然没有响应Microsoft提出的优厚条件。
不过，Anders实在是太重要的人物，而且Microsoft在面对Java与日俱增的威胁下，
非常渴望能够有像Anders这样的人才带领Microsoft开发下一代的开发工具，这当然
也是由于Microsoft以前向Borland挖来的人都做出了不小的贡献所致。Microsoft食
髓知味，当然希望能够得到Borland的镇山之宝。在Anders两次不为所动之后，
Microsoft决定祭出最后的王牌，由Bill Gates亲自找Anders吃饭，进行最终的挖角
行动。
不管读者喜不喜欢Bill Gates，不可否认的是Bill也是一个天才。自古英雄惜英雄，
在Anders和Bill相谈甚欢的情形下，Microsoft开出了年薪三百万以上、数万股的
Microsoft股票这个超高的条件，再以当时Microsoft高贵的股价来计算，真是一笔庞
大的数字，也许对于搞软件技术的人来说，这已经是不可能的天文数字了。不过这些
条件并不是打动Anders的主要原因，Bill最后提出的条件是"答应给Anders一个小组
和极多的资源，让Anders尽情地发挥"。这个条件可说是打到了Anders的心底，因为
Anders正渴望有人能够支持他完成新的计划和想法。我想，在软件产业中大概也只有
Microsoft能够拥有这种雄厚的资源可以挖角任何人吧。
在Bill Gates提了这样的条件之后，Borland再也没有本钱能够和Microsoft进行比价
了，只好眼睁睁地看着Anders离开Borland前往Microsoft再开创下一个人生的高峰。
在Anders到了Microsoft之后，Bill Gates果然重用Anders，也立刻让Anders负责激
活Microsoft的下一拨开发工具计划，当然这个计划也是Microsoft对抗SUN/Java的整
体计划之一。Anders到了Microsoft之后立刻展现了实力，让Microsoft的编译器技术
又精进不少，最明显的例子就是Microsoft后期的Java Virtual Machine是PC上执行
效率最好的，而且在2、3年后，VJ++编译出来的虚拟机械码的执行效率不但比任何的
Java开发工具还快，在某些方面甚至比原生的Windows开发工具，例如Delphi、VB、
甚至是VC++还有效率。这真是令人震撼，当然Anders为VJ++打下的基础现在也展现在
NET的C#编译器以及.NET的JIT(Just In Time)编译器之上，.NET的JIT在许多程序代
码最佳化方面比Delphi还先进。因此在2、3年前当VJ++即将推出之际，在Borland内
部也引起了非常大的骚动，并且严阵以待，当然这又是另外一个故事了。
对于Anders来说，到了Microsoft之后不久又再次登上了生涯的另一个巅峰。因为当
初Anders在Borland之时，就有如孙子兵法中叙述的"藏于九地之下"，虽然是不世出
的天才，但是仅为少数的人所知，即使是使用Borland产品的人在当时可能也不知道
Anders这号人物。因为Anders和Borland的作风很像，都是行事低调，不到最后绝不
随意出手。但是Anders被挖角到Microsoft之后，由于Microsoft的企业文化向来是前
进、积极的侵略性方式，因此Anders也就转变为"动于九天之上"，负责Microsoft开
发工具大军的核心大将，不但广为人知，成为许多软件人员效法的对象，而且屡获大
奖。他不但获得了信息软件业界的推崇，最后也终于获得了信息学术界的认可，可说
是实至名归。
Anders的离开对于Borland来说是一个很大的损失，不过对于Delphi R&D小组来说却
是有好有坏，因为Delphi开发小组虽然失去了最重要的支柱，但是也给Danny Thorpe
一个快速崛起的机会，在1年后，Danny果然立刻成为了Delphi/C++Builder/Kylix中
最杰出的人物之一(另外一个当然就是Anders的老搭挡Chuck Jazdzewski了)，Danny
也是我认为目前在Borland RAD(注)部门中功力最厉害的人物。在稍后的内文中我会
对Danny进行比较详细的说明。
注：Borland RAD部门是指Borland的Rapid Application Development部门，RAD负责
的产品包含了C++Builder、Delphi、Kylix以及未来的.NET以及Mobile的新产品。
巅峰之作和最后的胜利者
在Zack于Delphi 3开发的后期和Paul Gross逐渐取得了主控权之后，Delphi的发展方
向也偏向了Zack希望的Multi-Tier的技术以及由Paul Gross稍后主导的Borland
Golden Gate计划。1997年，Delphi还是像Delphi 1/2一样以强劲的生命力，以一年
一个大版本的速度准时推出了。当时Delphi 3也称为Delphi 97。Delphi 97和
Delphi l/2一样有一个最重要的战略目标以及主要的革新技术，那就是Multi-Tier和
COM/DCOM的支持。因此，当时97推出之际使用的行销术语是"Component Foundry"，
意指Delphi 97能够开发任何的软件组件(事实上是指VCL、COM/DCOM以及ActiveX组
件)，而且使用组件来开发Multi-Tier的应用系统。
Delphi 97无论是在品质、功能或是市场和销售上都是非常成功的。也许是为了证明
即使是没有了Anders，Borland的Delphi R&D小组仍然有实力开发出优秀的Delphi产
品，因此Delphi 3一推出的品质就在高水平的地步，后来Delphi 97销售的结果也证明
了它没有令人失望，Delphi 3的推出让Delphi一举突破了150万套的销售大关，也几
乎成为Borland有史以来最畅销的单一系列开发工具，我也认为Delphi 3是Delphi所
有版本中最好的一个。
不过，Delphi 97在即将推出之时也令一些人感到忧虑，因为在当时几乎没有任何开
发工具强调Multi-Tier的开发，大多数的开发工具仍然着重在Client/Server的功能。
Delphi 97将许多新功能集中在Multi-Tier的开发的确是一个不小的冒险，因为在当
时Multi-Tier的观念还非常的新颖，许多人对于Multi-Tier是什么？能够用来开发什
么？为什么要使用Multi-Tier等等问题都不是很清楚。更重要的是，在那个时候
Multi-Tier的基础工程都尚未完全准备好，使用者要如何使用Multi-Tier技术来开发
应用系统、甚至是学习Multi-Tier的技术呢？
我所谓的"Multi-Tier的基础工程都尚未完全准备好"，是指在那个时候Microsoft的
DCOM技术都还没有推出。那么，Borland该如何在Windows平台上提供Multi-Tier应用
系统需要的分布式技术呢？说到这里，我们也不得不佩服当时Borland这些Delphi
R&D小组的眼光，他们几乎已经精确地看到了未来的软件计算世界将会由网络和分布式
技术主导，因此，即使是在操作系统平台尚未准备好的情形下，Borland也决定快速
向前出发。
另外一个驱使Delphi 97走向Multi-Tier的重要原因便是当时Borland已经准备走向组
件技术的领域，准备在中间件(Middle-Tier Software)中成为一个关键的软件开发厂
商，这就是Paul Gross和Zack Urlocker激活的Golden Gate Strategy。而Paul Gross
也就是由于Golden Gate计划扬名立万、进而成为当时Borland整个研发部门的副总裁
(Vice President)，后来又成为Microsoft下一个挖角的对象。
为了配合Golden Gate计划并且成为分布式技术的领导厂商，Borland由Paul Gross主
导并购了Boston一家有名的顾问公司，这家顾问公司拥有一个颇为知名的中间件
"Entera"。Entera是一个以RPC(Remote Procedure Call)通信协议为骨干的中间件，
Borland希望通过Entera快速进入中间件的市场。由于Entera的客户端能够执行在
Windows的操作系统中，因此，Entera在Windows平台上拥有基础的分布式技术支持
能力，这刚好提供了Delphi 97需要的技术，所以Delphi的R&D小组立刻使用VCL封装
了Entcra的底层API，提供了一个称为OleEnterpriseConnection的VCL组件，让
Delphi 97能够和以RPC为基础的中间件连接。
因此在Delphi 97中Borland提供了三种分布式连接组件，分别是使用DCOM技术的
DCOMConnection、使用TCP/IP技术的SocketConnection以及OleEnterpriseConnection。
在那个时候最成熟的技术应该是OleEnterpriseConnection，而使用DCOM技术的
DCOMConnection在Microsoft本身DCOM尚不成熟的背景之下，表现得并不好。至于
SocketConnection，我认为Borland一直没有很认真地地实现SocketConnection，因此
最好只可以用来作为学习的对象，尚未到达可以真正应用的水准。不过稍后随着时间
和技术的进步，OleEnterpriseConnection逐渐没落，而DCOMConnection则反而因为
Microsoft的DCOM的慢慢改善而成为比较实际的应用对象。当然，这些又属于
Delphi 4的开发故事了。
虽然Delphi 97采取了比较冒险的做法，但是由于其品质良好，又支持COM/VCL组件的
开发，因此也很快征服了Delphi使用者的心而大获成功。当时许多Delphi的使用者仍
然是以开发Client/Server应用系统为主，不过由于Delphi 97好用的COM技术以及应
用Web的WebBroker技术，再加上Multi-Tier的功能，都让使用者大呼过瘾，把Delphi
作为学习这些先进技术的好工具，因此Delphi 97在当时到达了巅峰的地步。而
Delphi/VB和PowerBuilder/Gupta缠斗的情形也逐渐明朗。Delphi/VB的销售量和市场
占有率已经远超过PowerBuilder/Gupta 了，PowerBuilder/Gupta也注定将从通用开发
工具以及主从架构开发工具市场中让出绝大的市场份额。
其时PowerBuilder仍然不肯服输，并且坚称PowerBuilder在总收入方面仍然是第一。
这是因为PowerBuilder在当时仍然非常的昂贵，比Delphi/VB至少贵了两三倍以上。
但是在不断地快速流失市场的情况下PowerBuilder的售价很快就出现了大幅的下降，
至此Delphi和VB终于获得了全面的胜利；Client/Server开发工具的战争已止，但是
接下又上演了另一出精彩的Java开发工具大战。
危机的开始
在Delphi 3再次获得了胜利之后，Delphi 4决战的目标已经从Delphi、VB、PowerBuilder
和Gupta混战的形势转变为和VB对战的局势。原本Delphi有继续进击的机会，因为在
当时Delphi 3的功能的确强劲，而且许多功能都领先业界至少半年以上的时间，不过
可惜的是，在1996年Borland担任CEO的Delbert Yocam先生正好在这个时候开始了改
造Borland的计划，几乎造成了对Delphi不可挽回的错误，这要从Zack Urlocker被
Delbert Yocam拔擢成Borland Marketing的副总裁开始说起。
1996年11月，Borland邀请了Del Yocam入主Borland成为新的CEO，希望通过Delbert
Yocam在管理方面丰富的经验改善Borland长久以来在公司管理方面的积弱不振。
Delbert Yocam原本是Apple计算机公司的副总裁，应该是拥有丰富的管理经验，不过
不知道Delbert是不是在大型计算机公司呆惯了，因此花钱花得特别凶。Delbert在一
进入Borland之后立刻花了大钱更换总裁办公室里所有的家俱和装潢，其后到各地出差
时又要求头等舱以及总统套房，花钱像流水一样。当时我便对这位新的CEO没有什么好
印象。
Delbert在进入Borland之后一直想改造Borland。在Delphi 3大获成功之后，Delbert
便把重点集中在Delphi的身上。Delbert认为Delphi非常成功，是Borland的摇钱树，
因此一直想从这个产品线获得更多的收入。好大喜功的Delbert觉得Delphi的根基已
经很稳固，因此可以更快速地从Delphi身上取得资源。这让Delbert在1998年下了一
个严重的错误决策，几乎折损了Delphi的大好基业。
Borland和Microsoft的法律大战
在Microsoft不断地挖角，甚至把Anders也挖走之后，Borland已经到了"士可忍，孰
不可忍"的地步。Microsoft挖角的动作愈来愈像是恶意挖角，似乎是想把Borland搞
垮。Borland无法忍受的是Microsoft不但在操作系统和开发工具上进行不公平的竞争，
现在甚至进行人事上的不公平竞争。Microsoft不思在产品上和Borland一决雌雄，反
而进行挖墙角的破坏，Borland实在是忍无可忍了。
1997年5月，Delbert Yocam终于向美国法院提出了对于Microsoft的控告。当时Borland
提出的控诉理由是"Microsoft对于Borland进行Brain Drain"的行动。Microsoft在30
个月内从Borland挖角了34名Borland关键的开发者，而且每一名被挖角的人到了
Microsoft之后都担任和在Borland类似的角色，这摆明了就是要利用这些人在Borland
的知识快速地帮助Microsoft提升和Borland的差距，并且了解Borland内部的产品和技
术的开发状况。这种不公平的竞争应该是没有任何一家公司能够容忍的。
在Borland正式提出了诉讼之后，具备侵略性企业文化的Microsoft当然就立刻反击，
和Borland对簿公堂。Borland和Microsoft从开发工具战场一直斗争到法律战场，互
不相让的情形让许多看客大呼过瘾。Borland对于Microsoft来说似乎就是打不倒的勇
者，不管情势再艰辛，仍然能对抗到底，因为Borland知道，对于Microsoft一旦让步，
以后就永远没有机会了。当时，业界许多人都已经预测Borland迟早会采取行动，但
是没有想到这么快就勇敢地响应。Borland当时的行动引起了许多信息业界的尊敬和
支持。
这场官司的进行很快就有了初步的迹象，所有的证据都对Microsoft不利。Microsoft
一看情势不对，又不想让Borland真的消失，以避免吃上在开发工具市场垄断的官司，
所以立刻表达愿意和Borland在庭外和解。正是由于这个原因，才有后来1999年时
Microsoft对于Borland的投资，Microsoft这项投资正是这次庭外和解的条件之一。
不过Delbert的运气并不好，虽然Microsoft愿意和Borland进行庭外和解，但真正和
解的动作以及Microsoft对于Borland的赔偿事项却是发生在Delbert之后的Borland下
一任CEO，即Dale Fuller身上，Delbert种下的稻穗却是由Dale Fuller来收割。
接二连三的错误决策
1998年，Delbert Yocam再次展现了好大喜功的本性，在没有充分地讨论以及共识之
下，Delbert Yocam决定把公司名称从众所周知的Borland改为Inprise。Delbert决定
如此做有数个原因：
" 由于Paul Gross和Zack Uplocker的Golden Gate计划让Borland进入中间件市场，
因为Borland在企业市场以往没有很强的知名度，许多人认为Borland只是开发工具厂
商，因此Delbert为了解决这个问题决为Borland取一个新的名称
" 使用Inprise的意思是指Borland可以Integrating The Enterprise。为提供企业整
体解决方案的软件公司
" 基本上Delbert Yocam在进入Borland之后已经开始改变Borland，悄悄地进行第二
次Borland改造的行动。这就是以行销为主的Borland，有别于以往Philippe Kahn所
领导的以产品/技术为主的Borland。为了代表Delbert的决心并且重新出发，Delbert
认为公司该使用一个新的名称
1998年4月，在Delbert的主导之下，Borland花费了数百万美元之后终于改名成为
Inprise公司。不过Delbert原本是想在更改公司名称之后可以重新出发，但是没有想
到，在Borland改名为Inprise之后，各种负面的效果却接踵而来。
首先，传统的Borland使用者都强烈反对Inprise这个名称，这些Borland使用者都喜
欢原来的Borland。第二个问题，是许多新的使用者都听过Borland，但是在改名之后
这些新的使用者找不到Borland，以为Borland已经不见了，又从未听过Inprise这家
公司。第三，则是竞争对手刻意放出的讯息，故意散布Borland已经被一家叫做Inprise
的公司并购了，因此希望原先的Bor]and用户能够放弃使用Borland的产品。
Delbert万万没有想到，在花了大钱更改公司名称之后，Inprise(Borland)却开始得
疲于奔命地应付各种不利的后果。结果是赔了夫人又折兵，不但浪费了资源却无法在
企业市场闯出名号，又折损了Borland的金字招牌。
另外一个有问题的决策是把Zack Urlocker拔擢成Borland行销部门的副总裁。由于Zack
在Delphi 3出色的表现，以及和Paul Gross激活的Golden Gate Strategy让Delbert
心动，并且Delbert认为通过Golden Gate Strategy可以让Borland打入企业市场，因
此Delbert对Paul Gross和Zack Urlocker都印象深刻。不久之后，Delbert分别提拔
了Paul Gross为Borland开发工具部门的副总裁、Zack Urlocker为行销部门的副总裁。
本质上Zack是一个非常好的开发者，对于产品也有很敏锐的感触，应该是非常理想的
产品线管理人物，Borland应该让Zack好好地呆在R&D部门，为Borland的产品线运筹
帷幄，好好地开发Borland以后的产品。只可惜的是"水往低处流，人往高处走"，副
总裁的位置放在面前，Zack当然想升官发财(谁不是呢？)。不过Zack并没有想到自己
的优缺点。他固然是出色的开发人员和产品开发人员，但是对于行销却是门外汉。在
Zack做了行销副总裁之后，Borland的R&D小组不但失去了一员大将，更糟糕的是Zack
似乎也开始向Delbert学习，慢慢有了好大喜功的做事方式。
首先，Zack扩充Borland行销人员到达了100多人的数目。可是，当时全世界Borland
的员工才将近1000多人，行销的人员居然超过九分之一的比重，实在是太夸张了。不
过，这么多人的部门在当时仍然没有做出什么好的行销工作，仍然被Borland的使用
者抱怨。我还记得当时我曾向行销部门要求所有开发工具的市场竞争资料，结果行销
部门只说没有这种资料，当时我还很生气，这么庞大的部门居然连这么基本的竞争信
息都没有。事实上，当时Delbert Yocam同意让Zack的行销部门招聘这么多人，除了
是因为Zack很红之外，和Delbert想改善以往Borland做得很烂的Marketing工作也有
很大的关系。Delbert认为Zack在产品线方面表现得很出色，因此也希望通过Zack的
能力来进行Delbert对于Borland行销方面的改善工作。
可惜的是Zack上任之后表现得不如预期，大家对于Zack的表现也是贬多于褒。很快，
Zack就失去了以往在R&D小组时的自信满满，开始逐渐消沉，最后终于离开了Inprise
(Borland)。Zack从因为Borland C/C++3.0时的OWL framework快速窜起，在Delphi
3时达到生涯的高峰，一直到以行销副总裁之尊黯然离开Borland，真是令人感慨。如
果Zack能够清楚了解自己的优缺点，不要去接行销的工作，而继续在R&D部门发展，
也许他会有更好的成果。从Zack的奋斗过程，我认为程序员也许应该想想自己未来的
发展方向，好的技术人员一定是好的管理或是行销人才吗？
一开始我知道Zack Urlocker这号人物，是在数年前我还在Georgia Institute of
Technology念书时从那时著名的"Windows Tech Journal (WTJ)"得知的。当时Zack在
WTJ上一直有Object Pascal的专栏，写的内容都非常好，深深地吸引了我。因此当时
每个月初都开车大约半小时到最近的计算机商店购买当期的WTJ，目的就是为了阅读
Zack的文章，在那个时候我就认为这个家伙真是厉害。
据我所知，Zack在1999年离开了Borland之后，加入了Active Software以及数个其他
的软件公司，大都是担任行销方面的高阶主管。Zack在其后的数个职位上表现得不错，
不晓得是不是因为在Borland时缴了大量学费而学习到的知识。不过不管如何，我仍
然认为Zack Urlocker是一位值得尊敬的人物，因为他至少在一生中开发了2个重要而
且成功的产品"Borland C/C++和Delphi"，本身的技术水准也很高。相信Zack也将永
远记得Borland C/C++和Delphi，这两个产品是Zack一生的成就和骄傲。再见了Zack
Urlocker，相信许多的Borland C/C++和Delphi的使用者都会记得你的。
自巅峰而下--Delphi 4
中国人一直不喜欢"4"这个数字，认为它不吉利。难道说"4"对于Borland来说也是一
个挥之不去的噩梦吗？当初的Borland C/C++4．0对Borland来说是永难忘怀的噩梦，
到了Delphi 4，难道Borland又要重蹈覆辙吗？
时值1998年，是下一个Delphi版本应该要推出的年份，也是Delbert Yocam进入Borland
当CEO的第2年。对于美国企业的CEO来说，第2年是CEO向董事会显示经营绩效以及缴
出成绩单的时候了。Delbert为了能够缴出靓丽的成绩单，因此在1998年决定必须拉
高Borland的营收，以冲高Borland的股票价格。但是，当时的Borland才刚进入组件
和中间件的市场，尚未在企业市场占稳脚跟，因此Delbert决定在Borland的开发工具
产品线中动脑筋。Delbert做的决定就是强迫规定从1998年起，在每一个Quarter(也
就是每3个月)，每一个Borland产品开发部门都必须推出一个新产品，让Borland每一
个Quarter都有新产品可以销售，以便增加Borland的营收。
不过，DelbeN这个决定却相当的糟糕，这让Borland每一个产品部门的主管都面临了
强大的压力，因为即使是产品还没有准备好推出，但是时间一到，不管产品品质如何，
都一定要出货。Delbert这个错误的决定让1998年又成为Borland的噩梦年。
Delphi 1、2和3的时间间隔都是1年多一点，展现了Delphi强劲的生命力。依照原本
的计划，Delphi 4也应该是在1998年推出的。但是1998年Borland在内部开始研发数
项新的科技和产品，加上Microsoft不断的挖角行动，都让Delphi 4的研发工作受到
了延迟。依照当时Delphi 4的研发时程，Delphi 4最早应该在1998年的第4季才能够
推出。但是很不幸的是，为了达成Delbert Yocam的要求，Delphi 4在1998年的第三
季就必须出货。在接近1998年的第3季之时，虽然Delphi的R&D小组仍然无法完成
Delphi 4，并且极力抗拒出货，无奈在CEO强大的压力下，Delphi 4仍然必须在第3季
准时出货。
从我个人的角度来看，当时Delphi 4的产品品质应该只到Beta 2的阶段，离真正能出
货尚有一段不小的距离。Delbert强迫Delphi 4推出，不但打击了Delphi R&D小组的
土气，如此乱搞产品线，以外行领导内行的结果只是让Delphi砸坏了自己的招牌。不
过站在Delbert的角度则又不一样了，因为对Delbert来说，如果在1998还无法冲高
Borland的营收，那么Delbert肯定是要下台的，因此Delbert只有孤注一掷了。
1998年的第3季，Delphi 4果然被强迫推出了。虽然Delphi 4的新功能仍然亮眼，但
是品质不稳的恶名也很快地出现在使用者的抱怨之中。随后，使用者的不满愈来愈强
烈，Borland面对四面八方的反弹不得不快速地做出响应，立刻开始着手Delphi 4
Patch的开发，以期快速修正Delphi 4的臭虫。依我的看法，Delphi 4一直要到
Patch 2才应该是当初Delphi 4出货时的品质。由于Delphi 4的反应不佳，因此未能
再次把Delphi的销售量拉上新高，Delphi原本锐不可当的气势也为之一挫。对于
Borland来说，Delphi 4的销售并没有增加太多的收入，Delbert打的如意算盘当然也
落空了。Delphi 4的失败也严重地影响了C++Builder的品质和销售，Delbert恶搞产
品的开发之后不但又让Borland开始赔钱，终于也自尝恶果，在1999年被Borland的董
事会开除。不过。无论如何，Delbert的决策已经对产品造成了巨大的伤害。
虽然Delphi 4的诞生过程充满了困难，命运也很坎坷，不若它的兄弟般好命。但是
Delphi 4却意外地向全世界揭露了Delphi另外一个Architect的庐山真面目，那就是
Chuck Jazdzewski。在Delphi 4中，使用者只要开启About对话盒，并且按下
"Alt+chuck"，那么就可以看到下图的画面。这个简短的画面是Delphi R&D成员之一
偷偷使用V8录下来并且放入Delphi 4中的，这也是第一次Chuck露脸于全世界。Chuck
事先并不知情，而在以往的Delphi 1/2/3中放的人物图片则一直是Anders。这些隐藏
的有趣图片以及Delphi R&D开发小组的名单在Delphi中称为"Eastern Eggs"。
直到1999年，在费城举行Borland Conference时，我才真正有机会见到Chuck，并且
和Chuck当面讨论一些事情。Delphi 4的失利让Delphi从巅峰的态势往下沉沦，要等
到Danny Thorpe继Zack之后掌握Delphi的研发大权后才能再次向前挺进。
Delbert最后的挣扎
由于Delbert错误的决策先后让Delphi 4和C++Builder 4失利，Borland每季又开始亏
损了。显然，Delbert自己也心知肚明，如果再没有任何建树的话，他很快就要下台
了。为了做最后的挣扎，Delbert决定和其他公司合作。1998年正是Java快速兴起的
年份，SUN在JavaWorkshop失利之后，便一直想找一个好的Java开发工具。而当时
Borland发表了JBuilder 2，虽然JBuilder还不是Java市场上最受欢迎的Java开发工
具，但是JBuilder是最快速成长以及最受好评的Java开发工具。SUN看到了JBuilder
的潜力，因此对于JBuilder拥有强烈的兴趣。
SUN显示了对JBuilder的兴趣，无疑给了Delbert Yocam打了一针强心剂，几乎在绝望
中的Delbert似乎看到了一丝曙光。Delbert很快便和SUN接触，看看SUN能够提出什么
条件。Delbert的如意算盘是让SUN花大钱并购Borland，如此一来，JBuilder不就自
然成了SUN的产品了吗？由于在那个时候Borland的股价已经跌到了3到4美金之间，而
SUN的股价却高高在上，大概是在80多美金。因此，如果Delbert能够促成合并，那么
Delbert Yocam便可以大捞一票，甚至在并购之后，Delbert还有可能成为SUN的副总
裁，继续位居要津。
不过世事不能尽如入意。SUN只对JBuilder有胃口，对Borland其他的产品却没有多大
的兴趣，因为Delphi/C++Builder等都不属于Java系列的产品。而且Delbert Yocam又
狮子大开口，希望SUN以每股20几美元的代价收购Borland的股票，当场吓得SUN退避
三舍，这件事情后来也就不了了之了。当然，Delbert Yocam很不甘心，因为促不成
这宗合并案子，再加上Borland被Delbert搞得乌烟瘴气，下台的命运也就不可避免了。
也许是"天将降大任于斯人也，必先苦其心志，空乏其身"吧，Borland在Philippe Kahn
离开之后，历经了数任CEO，但是一直没有找到真正好的CEO，能够适当地带领Borland
走向光明。不过Delbert Yocam似乎是黎明前的黑暗，在Delbert不名誉地离开Borland
之后，Borland也即将看到未来之光。
Danny的接棒和决心
Delphi 4的仓促推出果然在市场上反应很差，销量上也一落千丈。原本寄望能够再次
获得好成绩让Delphi的总销售量再次冲上新高，并且为Borland带来更多的营收。但
这一切都很快地幻灭了，品质不好的产品仍然得面对市场严厉的考验。在Delphi 4遭
受了前所未有的失败、接着C++Builder 4也铩羽而归之后，Borland又开始走下坡路
了。Borland好不容易通过Delphi带来的希望却在错误的决策下被牺牲了。在1999年
4月Delbert终于被Borland的董事会扫地出门，结束了在Borland的日子。我认为，
Delbert在Borland将近3年的时间里，对Bodand造成了许多的伤害，其好大喜功的管
理方式对Borland的产品线更几乎造成了无法弥补的伤害，是我所认为的最糟糕的
Borland CEO。更离谱的是在Borland的董事会开除Delbert后，他居然还以合约未满
为由，要求Borland支付额外的谴散费，大捞了一票，真是人心不古，工作做得如此
差却还有脸提这种要求，在最后一刻仍然压榨Borland。
在Delphi 4的伤害造成之后，Delphi R&D小组要面对的是如何收拾残局，并且想办法
解决造成的问题。在这个时候Chuck由于把精力放在Borland另外秘密的产品和技术的
研发上，因此无法花太多的时间在Delphi 5的研发上。此时，在Delphi上一向表现良
好的Danny Thorpe便逐渐挑起了Delphi的重负大任。
Danny在Delphi 2之后便有大将之风，开始负责Delphi最低阶的编译器以及RTL(Run-
Time Library)的工作。Danny是美国San Diego大学毕业的，主修就是编译器技术。
在Delphi 4之后，Danny几乎成了RAD部门主要的Architect，负责了RAD大部分产品的
研发工作，甚至又成为Microsoft再次挖角的对象。
对于Danny来说，如何重塑Delphi 5让Delphi从失利中重新站起、找回昔日的光荣便
是一个非常重要的工作。在Delbert Yocam于1999年离开Borland之后不久，现任的
Borland CEO Dale Fuller先生便被Borland邀请加入成为Borland的代理CEO，希望能
够通过Dale Fuller的经验挽救沉沦中的Borland。在Dale入主Borland之后，首先展
开的工作除了整顿Delbert在位时形成的庞大无用的行销部门之外，在产品线方面则
是看好Linux的未来，要求Borland的RAD部门必须开发出Linux下的RAD工具。
在Danny接掌了Delphi主要的开发责任之后，又和Chuck一起再次形成中坚的RAD精英
份子。Chuck主要负责新技术和新构想的实验作品，而Danny则是负责困难的编译技术
以及RTL。由于Turbo/Borland Pascal以及Delphi的最佳化编译器都是Anders
Hejlsberg撰写的，因此当Anders离开Borland之后几乎没有人能够维护编译器程序代
码。Anders都是使用汇编语言(Assembly)撰写复杂的编译器程序代码，而且其品质是
如此之好，不但连Chuck Jazdzewski都赞不绝口，更麻烦的是当时Borland几乎没有
工程师敢随便更动这些程序代码。
因此在Anders Hejlsberg于Delphi 2离开了Borland之后，Borland立刻采取了数项行
动希望能够解决这个"烫手山芋"。Borland决定的第一件事情是从Delphi的编译器抽
离大部分最佳化的工作。因为要在Anders的程序代码再继续加入最佳化程序代码是
Borland当时没有把握的事情。另外，由于当时Borland已经决定开发C++Builder，
而C++Builder也需要一个最佳化的编译器，因此，Borland认为如果能够提供一个共
同的后端最佳化编译器，那么Delphi和C++Builder不仅都可以使用，还能够解决没有
人敢修改Delphi编译器的问题。这个决定就是后来Delphi 3以及C++Builder 2推出之
后Borland宣称的"Delphi和C++Builder可使用共同的后端最佳化编译器"，这个工作
当时是交由Borland的编译器小组Lee他们负责的。
不过共同的最佳化编译器只解决了一半的问题，对于Object Pascal语言本身的改善
仍然需要能够修改Anders撰写的编译器，那么到底谁能够进行这个工作呢？答案当然
就是另外一个软件天才--Danny Thorpe了。Danny在接手Delphi的开发大任之后，就
开始为已经停止开发一段时间的Object Pascal语言本身进行演进的工作。此外，
Danny也开始为Delphi底层的RTL进行改造，并且为Delphi的编译器加入更多最佳化的
功能。
Danny之所以同时在ObjectPascal程序语言、Delphi RTL以及Delphi编译器进行渐进
的改善工作，是有许多因素影响的。首先，当然是为了接下Anders留下的工作，另外
一个原因是在Delphi 3之后，必须再次对于COM的支持进行强化。最后，是为下在
Delphi 4之后，准备把Delphi移植到Linux上。事实上，Borland在Delphi的R&D小组中曾经
一度准备把Delphi和C++Builder移植到SUN的作业平台上，这是为了因应Delbert和SUN
合并时进行的准备工作。甚至Delphi的R&D小组认为，既然要开发跨平台的Delphi和
C++Builder，那么不如把Apple的Macintosh操作系统也纳入考虑。Delphi的R&D小组
在当时甚至已经列出了开发SUN和Macintosh平台的时间表，但是稍后随着和SUN合并
计划的破灭以及Delbert的下台，这个跨平台的Delphi计划也就暂停了。一直等到Dale
Fuller上台强力要求开发Linux平台的RAD工具之后，Delphi的R&D小组才再次激活跨
平台的计划。
为了支持更好的COM开发能力，Danny修改了Delphi的编译器，直接支持COM接口的参
考计数值(Reference Count)的维护工作，以免除开发者繁杂的程序代码，提供了类
似Visual Basic的能力。同时Danny也在Object Pascal程序语言本身中加入接口
(Interface)的机制，让Object Pascal和Java一样对接口程序设计都提供First Class
的支持。Danny并且更进一步，巧妙地结合COM的接口以及Object Pascal程序语言的接
口，让Delphi的程序员更方便地使用和处理COM接口。Danny的这些努力，就是Delphi
的使用者在Delphi 3之后逐渐在Object Pascal中看到的Interface机制。对于非常熟
悉Delphi的读者来说，应该可以发现Delphi 1/2中Object Pascal变化的部分很少，
但是从Delphi 3之后，每一新版的Delphi在Object Pascal程序语言本身都有进步，
这些都是Danny所做的努力。
在RTL方面，Danny更是投注了大量的心血，Danny的第一步是去芜存菁。Delphi经过
了三、四年的发展，许多RTL中的程序代码不是过时，就是需要进行最佳化的调整。
因此从Delphi 4开始，Danny便逐渐整理和改善Delphi的RTL，这方面的成果从
Delphi 5之后便逐渐显露出来，Delphi的RTL不但在效率方面有了进步，更提供了愈
来愈多以前版本的Delphi所没有的功能。当然，Danny在Delphi RTL方面最大的贡献
是改善RTL成为跨平台的基础。Danny维护后的Delphi RTL最后也成功地移植到了Linux
平台上，并且克服了许多Windows以及Linux平台差异处的困难。当然，Danny Thorpe
和Chuck Jazdzewski是Kylix得以推出的最重要的功臣之一。为了解决Kylix在Linux
平台上许多的技术问题，后来还引起了Linux开发者社群围攻Danny Thorpe的精彩大
戏，最后导致Danny Thorpe不再管Kylix的开发而全力投入.NET的阵营，这当然又是
另外一个极为精彩的故事了。
对于Danny来说，只有一个最重要的目标，那就是再次擦亮Delphi的光芒，让Delphi 4
的失败能够在下一个版本中一雪前耻，并且把Delphi开发成最棒的RAD开发工具。Danny
的决心也让Delphi R&D小组再次安定了军心，在历经了Delbert错误的决策、Microsoft
大幅的挖角、Delphi 4的失利之后，Danny带领了一些新的Borland工程师展开了艰苦
的工作。
Danny的杰出表现早已深获许多人的赞扬和肯定，也充分地展现了继Anders Hejlsberg
之后，Borland另外视为宝贝的天才的风采。现在，Danny不但早已独当一面，更成为
了Borland .NET的Architect，负责综合整理Borland未来在.NET上的开发工具。在2002
年Borland的Conference上，Danny正式由Borland的CEO Dale Fuller先生颁发
Borland President Awards大奖，这是继Chuck Jazdzewski、Blake Stone之后，
Borland第3个获得最高殊荣的R&D人员。在Danny接受大奖之时，现场所有的BorCon参
加人员都起立热烈鼓掌，看来，即使在Borland没有颁发这奖项之前，Danny早已被所
有了解他的贡献的人所肯定和钦佩，这只是一个迟来的奖项而已。
我曾在1999年费城的BorCon见到了Danny，并且在澳洲举行的BorCon和他有简短的对
话。Danny的身材不算高大，瘦瘦的，但是非常的温文尔雅。和Danny讲话是一件很舒
服的事情，因为你可以问他许多技术的问题，只要Danny有时间，他会很乐意和你讨
论的。
恭喜Danny!Borland又为PC软件界培养了一个天才和明星。我相信Danny Thorpe也将
成为许多开发者学习的对象，当然也包括我在内。
和对Anders Hejlsberg一样，最后再让我整理一下Danny Thorpe对于Borland和产品
线重要贡献和获得的殊荣，让读者也能对这位值得尊敬的软件开发人员致敬：
" 负责开发Delphi RTL/编译器困难的工作
" 改善Object Pascal程序语言，加入现代语言元素--Interface
" 开发出Kylix并且解决Linux平台的臭虫
" 1999年被Borland内部评选为全Borland最重要的50人之一，是Borland不可放弃的
人才
" 2001年荣升Borland .NET Architect
" 负责开发Borland .NET下一代整合开发工具--Galileo
" 和Chuck Jazdzewski共同开发代号为Charlotte的下一代Web Service程序语言
" 2002年于BorCon获Borland President's Awards大奖殊荣
对于我来说，Borland孕育了无数的伟大软件工程师，当然有一些人我无缘认识，因
此对于这些人，我只能说是"久仰大名"，例如Windows平台的系统和除错大师Matt
Pietrek。但是有一些人却是我认识、甚至有过对话的。这些人每一个都令我折服，
也让我向往这些伟大软件工程师到达的境界，他们是：
" Borland C／C++、dBuilder的Framework大将Carl Quinn
" 不世出的软件天才Anders Hejlsberg
" Borland首席科学家Chuck Jazdzewski
" Borland RAD核心支柱Danny Thorpe
当然，还有本书稍后会叙及的Java天才，Mr. Blake Stone。
重回基本的精致之作--Delphi 5
1999年8月，距离Delphi 4推出将近一年之后，由Danny领军的Delphi 5终于准备推出
了，这次没有CEO不合理的要求，Borland又投入了适当的资源，再加上Danny和
Delphi R&D小组的全心开发，Delphi的开发步调又回到了以往的轨道。在Danny
Thorpe的细心和坚持之下，Delphi 5在推出时的完成度是非常高的。
注：Borland的每一个产品在推出之前都会进行完成度测试和评估，这和其他的软件
是一样的。每一个产品在完成度到达多少才推出是不一定的，一般来说在85%以上就
是不错的产品，低于80％就推出的产品则等于是推出Beta版的软件，品质一定不好。
当Delphi 5推出到市场之后，其品质果然又受到了Delphi使用者的喜爱，销售数字也
证明Delphi 5已经成功地扫除了Delphi 4时埋下的阴影。再加上当年的JBuilder 3又
迈入了一个全新里程，打造成了一个完全由Java撰写的Java开发工具，因而大获市场
肯定，进而正式为Borland在Java市场带来了空前的胜利和大量的收入。Borland又开
始产生盈余了，Delphi和JBuilder从1999年开始也正式成为了Borland的两大摇钱树。
不过Delphi 5虽然成功，但是从销售数字来看，Delphi的销售几乎已经到了顶峰，不
易再高度成长并且带来更多的收入，这从其他Windows传统开发工具的情形也可以看
得出来。所以对于Borland来说，应该要开始为Delphi准备下一代的功能和平台了，
重新设计Delphi的所有功能和GUI接口，再次地演进Delphi的风貌。即使Delphi也和
Visual Basic、PowerBuilder一样即将走入下一代的开发环境，但是Borland仍然有
责任在世代交替之间提供Delphi使用者顺利的移植方案。可以很明显地看到，
Delphi 6提供了Web Service功能让以前和未来的应用程序能够相互整合，Delphi 7
则将提供Microsoft .NET平台开发的功能。Delphi 6和Delphi 7即是为Delphi的开发
者走向未来提供的垫脚石。
Delphi 5应该是Delphi 3之后最好的一个Delphi版本，称为Windows平台下最好的RAD
开发工具是当之无愧的。虽然Borland RAD小组持续的开发最好的Windows开发工具，
但是在Windows平台上的开发模式却已经悄悄地进行了自DOS以来最大的改变，那就是
Microsoft为了因应Java的攻势而展开的 .NET计划。Windows平台上的开发概念、开
发工具和开发技术即将揭开新的序幕，Microsoft也准备逐步淘汰原生的Windows开发
工具。
PC平台上的开发工具从DOS、Windows到未来的.NET，一共历经了数个阶段。在每一个
阶段，开发工具的市场都有着群雄逐鹿、竞争惨烈的战况。开发工具市场几乎是所有
软件中竞争最激烈的。从DOS时代PC的开发工具市场有着数10家软件厂商竞争，到了
Windows平台只剩下10几家、最著名的也就不过五六家，再延续到未来.NET的平台，
举是轻重的开发工具开发商可能会只剩下Microsoft和Borland。
上面的表格是我整理从DOS、Windows第1个阶段、Windows第2个阶段以及未来.NET平
台下的开发工具竞争情势。从上表中，读者可以看到不同的阶段主宰流行的程序语言、
以及最后在开发工具市场胜出的厂商。开发工具情势的演变是Microsoft和Borland
仍然将主宰这个市场，其他的厂商只能占有极小的市场和影响力。Borland也证明了
只有她能够和Microsoft抗衡，也是在Windows平台下，除了Microsoft之外唯一的独
立开发厂商。我相信Microsoft和Borland仍然将在.NET平台的开发工具领域中缠斗下
去，虽然Microsoft已经率先推出了Microsoft Visual Studio，但是2003年第2季
Borland也将推出全新的集成开发环境--代号为Galileo的产品作为响应，一场精彩的
龙争虎斗又将在2003年展开序幕。
具有讽刺意味的是，数年前许多人质疑Borland是否能够活下去，许多人也因为担心
Borland的未来而不敢使用Delphi。但是现在证明，Borland不但成长得愈来愈好，
Delphi还继续推出了新版本Delphi 7，Delph 8也在Borland的计划之列。Delphi 7将
是Windows平台下最好的原生Windows开发工具，也是撑到最后一个的RAD开发工具，
连Microsoft都没有做到。Delphi 7不但延续了原生Windows应用系统开发的生命，
也为未来.NET平台的开发做了铺路和转移的准备。Delphi、VB、PowerBuidler和
Gupta经过了数年的大战之后，结果证明，Delphi才是撑到最后的英雄。
^v^v^v^v^v^v^v^v^v
第四章 未完之传奇
"成功产品的背后有着更多不为人知的秘密!"
Chuck的秘密计划
Chuck像个藏镜人。虽然他始终是Delphi最重要的三个人物之一，但是却一直不愿意
站在最前线面对大众，而宁愿躲在幕后进行令人惊讶的软件革新工程。Chuck进行的
许多开发和研究并不广为人知……
当Anders离开了Borland之后，Chuck短暂地成为Delphi的总Architect。不过，Chuck
负责Delphi的开发工作后不久，就把Delphi Architect以及重要的工作交由Danny来
负责，因为Danny早已显示了大将之风，成为Chuck最为信任的软件专家。而Chuck呢？
虽然他仍然负责Delphi中许多重要的工作，但是后来大部分的时间是花在新技术和新
产品的秘密研究之中。对于一些Delphi例行性的工作，Chuck并不会花费太多时间。
在Delphi 3的研发阶段，Chuck的主要精力并不是在Delphi 3上，因为Danny和Zack负
责得很好。Chuck当时主要是进行两件重要的研发工作，即Delphi的Java编译器以及
Apollo计划。
原来，在开发Delphi 3时，Anders和Chuck都已经预知了Java将来必会成功，成为重
要的语言和软件技术。因此Anders和Chuck都知道必须在Java方面进行一些因应之道，
以未雨绸缪保持Delphi的竞争力。后来Anders离开了Borland，而Chuck则选择了投入
资源研究Delphi和Java的整合技术。当时Chuck的想法是为什么不能够开发一个类似
Java的JVM，直接把Delphi的程序代码转换为Java的ByteCode，让Delphi的应用程序
直接在JVM中执行呢?甚至，当时Chuck还想，为什么Borland自己不开发一个Delphi
JVM，让Delphi也可以执行在Windows、Linux、Solaris和Mac OS之中呢？
有了这个疯狂的想法之后，Chuck立刻要求Borland的高层批准这个研究计划，让他能
够有资源进行研究工作。由于当时正值Anders因为不满在Borland没有足够的研究资
源而离开了Borland，进入Microsoft一展心中的鸿图。因此，Borland高层当然不愿
得罪Chuck，以免他也离开Borland。由于当时Delphi 3的进度在掌握之中，而且
Delphi为Borland带来了大量的资源，因此Borland高层批准了Chuck的这个不可思议
的计划，让Chuck开始了研究之路。
Chuck有了资源之后，就立刻投入研究的领域，在Delphi 3的开发末期也没有花太多
的时间在Delphi上，反而加速地和Borland的编译器小组为Delphi For Java编译器进
行研发工作。在1997年中左右，Chuck有了初步的成果，已经能够把一些简单的
Object Pascal程序直接编译成Java的ByteCode、并且执行在JVM之中。这实在是一个
不小的突破，因此在当年的BorCon 1997中，Borland和Chuck正式对外公开了这个技
术，立刻引起了Delphi使用者强烈的兴趣，因为这代表一旦这个编译器研发出来，
那么Object Pascal便立刻成为一个像Java一样的跨平台程序语言，而且，如果
Borland能够继续把VCL和RTL移植进来，那么，Windows平台的Delphi程序员可以通
过这个技术同时开发多个平台的应用程序，这实在是太美妙了。
当BorCon公开了这个技术之后，Borland立刻面临了愈来愈多的Delphi使用者的询问
以及要求Borland尽早推出这个技术的压力。当然，Chuck以及Delphi研发小组也非常
兴奋，因为这代表Delphi又将有新的市场以及新的成长动力，所以Chuck立刻要求
Borland投入更多的资源，以加速研究这个Delphi For Java编译器以及相关的研究工
作。
不过，此时却发生了两件事情，最终让Chuck放弃了继续开发Delphi For Java编译器
的意图。首先，Chuck和Borland的编译器开发小组发现JVM似乎和Java语言系结得太
紧密，以致JVM的许多伪指令都和Java语言的架构系结在一起，无法轻易地由其他语
言来提供类似Java语言的架构，除非修改这些语言架构来仿真Java语言的架构。这个
原因造成了当Chuck想把Object Pascal一些复杂的数据类型和语言架构编译成Java
ByteCode时发生了极大的困难。
第二个决定性的原因是，由于当时JBuilder已经表现得愈来愈好，Borland希望投入
更多的资源到JBuilder小组，而且不希望有其他的产品或是技术影响JBuilder的成长，
因此，Borland高层对于Delphi For Java编译技术的开发也没有很大的兴趣，再也
没有批准更多的资源给Chuck。最后，Chuck的这个Delphi For Java编译计划便宣告
终结了。这实在是件可惜的事情，不过，当时Chuck研究的东西并没有白费，因为现
在Delphi小组也根据当时Chuck研究的成果来开发.NET上的编译器，希望通过以前投
入的资源和经验来开发更好的Delphi For .NET编译器。
另外一个Chuck在Delphi 3开发阶段秘密进行的研究计划则更为重要了。当时我更期
望这个技术能够出现在市场之上，不过可惜的是，最后也由于Borland高层要求Chuck
投入Kylix的研发工作而一直拖延到今日都还在软件实验室中，这就是属于Data
Component技术的Apollo计划。
Apollo项目的缘由要从Delphi 2开始说起。在Delphi 2开发时，Anders一直想在Delphi
中建立一个Garbage Collection的功能，而Chuck则希望继续扩充VCL的功能为VCL加
入Data Component的能力。由于VCL使用的组件架构在连接数据时是使用数据感知组
件(Data Aware)技术，但是许多真正使用面向对象技术的程序员反而对使用数据感知
组件相当地反感，而且在大型面向对象项目中，数据感知组件也被证明是不适当的。
因此Chuck为了赋予VCL开发大型面向对象项目的能力，决定加入Data Component技术
。
所谓Data Component技术，是指VCL架构可以代表实际世界中的domain对象，这些
domain对象可通过VCL的技术直接储存在数据库之中，或是从数据库中取出，类似EJB
中的OR Mapping(Object-Relational Mapping)技术。如此一来，Delphi的程序员可
以在Delphi中直接使用VCL组件来代表如员工和公司等实例(instance)，而且可以随
时把员工和公司实例储存到数据库中，再从数据库中取出员工和公司成为对象，而不
需要使用数据存取对象直接处理数据库中的数据。Chuck早在五六年前就想在Delphi
中实现目前Bold等公司提供的Object Instance技术。
没有想到，就在Chuck进行Apollo项目到了一半的时候，由于当时Borland的CEO Dale
Fuller先生看好Linux的发展，因此下令所有Delphi小组的成员都必须投入到Linux
开发工具的研发工作，全力为Kylix催生，于是连Chuck也被要求先暂缓所有的研究计
划，投入Kylix的开发工作。其实，当时我就非常反对像Chuck这样的顶尖人才进入
Kylix小组撰写程序代码，因为这实在是非常浪费的事情。Chuck应该进行更为重要的
研究计划，而不是只开发一般的工具而已。但是，当时Borland高层认为Linux将可带
领Borland一飞冲天，因此仍然坚持所有的人力都必须投入。不过，市场就是变化得
这么快，在Chuck和Danny都投入到Kylix的开发之后，虽然Delphi小组几乎以创记录
的时程在1年半左右就在一个新的平台开发了一个新的产品线，但是在Kylix推出之
后，Linux平台的疯狂热潮却开始快速消退。所有投入Linux的厂商再也无法仅以沾
上Linux的名称就可以让股票日创新高，市场终究是要回到基本点，只有真正获利的
公司才能够在市场成为赢家。
在Chuck被Kylix开发工作延误了近2年的时间后，Apollo再也不像当初那么吸引人了，
因为市场已经出现了类似的科技，例如EJB的OR Mapping技术和Bold等公司的产品。
如果Borland当初能够让Chuck全力发展Apollo计划、并且在其他公司之前推出Apollo
的成果，那么Delphi将可以在OR Mapping方面占有领导的地位，Borland研究的OR
Mapping技术说不定还可以被SUN授权使用，就像Oracle花了大钱从WebGain购买类似
的技术一样。Anders和Chuck这两位拥有一流技术和眼光的技术人物，或多或少地被
许多平凡的管理人物糟蹋了好几次。
Chuck本身是一位非常和蔼可亲的人物，我曾经多次和Chuck交谈，每次谈话时Chuck
总是笑嘻嘻的，似乎没有事情可以让他感到忧虑。如果不知道Chuck的人和Chuck交谈，
那么可能没有人会相信，这位看起来像是好好先生的人在软件方面有这么惊人的成
就和高深的造诣，而Chuck一头接近红色的头发也让我第一次见到他时被吓了一跳。
当Chuck和Danny被征召开发Kylix时，其实也不是非常顺遂的。在Kylix激活之后，照
例是由Danny负责Linux上编译器和RTL的研发工作，而Chuck则负责VCL和CLX方面的工
作。由于要在Linux上开发集成开发环境，必须先在Danny负责的底层RTL和编译器完
成之后才能够开始设计。但是，Danny在把Delphi的RTL和编译器移植到Linux的过程
中发现了一些Linux的臭虫，因此，当时Danny在Linux的论坛上公布了他发现的臭虫，
并且希望Linux的社群能够修改这些问题，如此一来Borland才能够继续研发Kylix。
不过，也许是Linux的社群拥有排外的情绪，一直认为Borland不是正统的Linux软件
厂商，因此对于Danny指出的Linux臭虫也嗤之以鼻，认为Danny什么都不懂就来说是
Linux的臭虫。由于Linux论坛上的人非常的不友善，而且坚决不承认Danny提出的是
臭虫，因此也惹得Danny非常不高兴，认为做软件的技术人员为何不能就事论事，明
明有问题却死不承认。于是Danny便在Linux论坛上和这些人发动了笔战，愈吵愈轰动，
最后演变成了两派人马互相批评。我在当时也想不通，为什么明明Danny已经指出了
Linux有问题的地方，而这些也是搞软件的人却有如此的反应？这些人是不是太小心
眼了呢？以Danny如此功力深厚的人反而被这些Linux的人说成是不懂软件开发真是笑
掉人的大牙，这些人应该看看Danny做出了什么东西，看看他们能不能做得出来再说。
由于Danny无法在Linux论坛上得到结果和支持，因此一怒之下干脆自己来修改Linux
的臭虫，好让Kylix能够继续开发下去，不再需要这些Linux社群的帮忙。这也是为什
么在安装Kylix时，Kylix不但会检查使用者Linux使用的版本，并且会安装Patch档案
以修改Linux操作系统的问题。Danny选择了安装额外的Patch档案的方式来解决Linux
的臭虫，而不是直接修改Linux的核心，再由Borland分发Linux Distribution。当时，
在Danny解决了Linux执行时期函数库的一些臭虫之后，Kylix才能够顺利地开发下去。
后来，在Kylix小组开发Kylix的集成开发环境时也发现了一些XWindow的臭虫，Danny
也是选择由Borland自己来修改加以解决，而不需要Linux社群的帮忙。
当然，由于Danny和Linux社群之间的大战也让Danny憋了一肚子气，在Kylix推出之后，
就把随后相关的开发工作交给Kylix小组来负责，Danny则专心到.NET研发小组为Borland
开发.NET上的下一代开发工具了。Danny离开Linux是Linux的损失，这些和Danny争吵
的Linux程序员不知道他们在Linux上损失了一个天才型的软件人员。有时我想，一些
庸才不就是不断地攻击天才吗？难怪古人说"不招人忌是庸才"了。看了Danny大战Linux
论坛这一幕，我也只能在旁摇头叹息，不过我个人倒是很高兴Danny和Chuck全力开发
NET产品，因为我一直想使用Borland的开发工具学习和开发.NET应用程序呢。
目前，Chuck在Borland进行的工作是在.NET上研究先进的技术，包含了在2002年
BorCon上Chuck公开展示的新语言--Charlotte。Charlotte主要是提供Web Service的
First-Class语言，是由Chuck定义Charlotte的语法、功能，并且实现Charlotte编译
器的。我实在佩服像Chuck以及Anders、Danny这些人物，因为这些人几乎都可以独自
开发和实现新的程序语言，其功力的确是一般软件人员难以想象的。
在BorCon上，Chuck已经展示了Charlotte的语法以及初步的编译器，目前，在Borland
.NET内部，Charlotte使用了另外一个比较正式的名称，到了2003年或许我们就可以
看到Chuck和Danny在2002年一整年努力的成果了。
回到未来
2002年，Borland推出了Delphi 7。虽然此时Microsoft已经信誓旦旦地表明，.NET才
是Windows的未来，不过现在Windows应用程序的开发仍然是主流。但是未来呢？
Delphi的未来是什么呢？
Borland已经对全世界宣布了2003年即将推出.NET上的开发工具，首先支持的语言将
会是C#和Object Pascal，而且在.NET上，Delphi已经成为Object Pascal的代名词，
这意味着未来在.NET上，Delphi已经是一个语言名称了，Delphi的使用者将使用Delphi
语言在.NET上开发新一代的.NET应用系统。那么在Windows平台呢？Delphi 7会是最
后一个版本吗？
当然不，虽然根据各种信息调查的结果显示，从2003年开始，.NET将进入起飞的阶段，
但是原生Windows程序的开发仍然拥有三四年的需求。既然如此，那么一定还有许多
的使用者仍然需要原生的Windows程序开发工具，Borland不会放弃这些使用者和这么
大的市场，因此Borland也一定会继续推出新的Delphi版本供使用者使用。
更何况，即使是对于想要开发.NET的使用者来说，可能有极大部分的人也同时需要开
发原生窗口应用程序。那么，为什么软件厂商不提供一个开发工具能够让使用者在同
一个集成开发环境下同时开发原生窗口应用程序以及.NET应用程序呢？这个需求就是
Delphi的优势和机会。看看现在Delphi 7提供的功能，我们会很惊讶地发现，其实
Borland已经偷偷地在进行一些革新的做法。
如果读者在Delphi 7的集成开发环境中安装了Delphi for .NET command-line
complier IDE integration，那么就可以如下图般在Delphi 7的集成开发环境中激活
Delphi For .NET编译器，以便在Delphi 7中开始撰写.NET应用程序。在2002年11月，
Borland又公开了Beta版本的VCL.NET供Delphi 7使用者下载，以便在.NET中使用VCL
组件。
不过，许多人会觉得光是拥有Delphi For .NET编译器以及VCL.NET并不够用。如果要
开发.NET的WinForm应用程序，那么Delphi 7目前并没有提供类似Delphi的Form
Designer，因此仍然非常不方便，Delphi的使用者仍然需要一个解决方案。
让我们想想，虽然目前Delphi For .NET没有像Delphi的Form Designer，但是如果我
们能够使用Delphi本身的Form Designer作为.NET WinForm的开发接口，然后，如果
能够再通过一个工具把Delphi的TForm和VCL转换为.NET的WinForm以及VCL.NET不就可
以了吗？如此一来，Delphi的使用者几乎可以在不花费时间成本之下立刻在Delphi中
开发.NET可视化WinForm应用程序，这不是一举数得吗？没错，其实Borland也早就想
到了，因此Borland也正想开发一个Delphi转换到.NET程序的转换器让Delphi的程序
员使用。这样Delphi的程序员就可以直接使用Delphi的Form Designer来设计.NET
WinForm的接口，最后再通过转换器自动地转换为.NET的WinForm应用程序。
如果读者使用过Delphi 7的Delphi For .NET编译器，那在其中的文件以及Delphi的
论坛中就可以看到"Morpheus''这个名称。其实，Morpheus正是Delphi For .NET编译
器的研发计划的代号[在电影The Matrix中，Morpheus是救世主(The One)基努李维尚
未出现之前的领导者，Morpheus的任务就是寻找救世主以拯救末世]。因此Delphi的
研发小组很有创意地把Delphi For .NET编译器命名为Morpheus，以代表Delphi For
NET编译器是未来Borland推出纯.NET开发工具之前的救世主，负责带领Delphi程序
员走向未来.NET的救赎之道。而Morpheus计划的任务就是为Galileo打下成功基础。
虽然我们对Delphi 8可能提供的功能现在还不清楚，但通过使用者的需求以及市场的
现况，可以推算出如下轮廓：
■ 新的集成开发环境：这是为了让Delphi能够同时在集成开发环境中开发原生窗口
应用程序、.NET应用程序以及Kylix应用程序
■ 新的VCL和CLX：可以让VCL同时使用在原生窗口和.NET之中。此外Borland也将再
次修改VCL/CLX以增加Framework在三个平台的兼容性
■ 新的Delphi/Kylix和Delphi.NET编译器：可以在Object Pascal语言上提供更为兼
容的效果。这是因为在Delphi For .NET中，Borland已经为Object Pascal加入了
许多新的语言元素和功能，Borland可能也将为Windows和Linux平台上的编译器加
入这些功能
■ 更多的辅助工具：帮助程序员同时开发三个不同的应用系统
当然Delphi 8还将有其他许多未知的功能，不过上面所列的几项应该是Delphi 8肯定
具备的。如果Delphi 8真能提供上述功能，那我相信它将是使用率最高的窗口开发工
具，因为除了程序员完全是开发.NET应用程序之外，Delphi 8可以提供最齐全的开发
能力。
Delphi 8将是Delphi最后的一个版本吗？这我也不知道，唯一可以用来判断的标准是
NET多久能够完全占据窗口开发的应用。如果真有那一天，那也就是所有原生窗口退
出市场主流的时候，就像数年前的DOS开发工具一样。届时也请读者把Delphi的最后
一个版本保留起来，以作为我们一起经历过原生窗口开发的见证，同时，也作为这个
曾经是最棒的原生窗口开发工具的纪念。
Delphi风云榜
Delphi的开发过程创建了许多记录，并且也造就了许多有名的人物。Delphi创建的记
录是许多开发工具无法企及的，而围绕在Delphi外围的杰出开发者也各领风骚，为
Delphi的传奇添加了更多精彩的故事。这些Delphi记录和杰出的Delphi开发者故事值
得读者们一一品味，特别是Delphi使用者们熟悉或听闻过的人们。他们虽然不像Delphi
的灵魂人员Anders、Chuck或Danny那样，广为人知、受人尊敬，但对Delphi的发展，
他们也具有不可磨灭的贡献，这里我们也来看看他们的"庐山真面目"。
Delphi集成开发环境之父
相信每一个Delphi/C++Builder的使用者每日都花许多时间在Delphi/C++Builder的集
成开发环境中，既然如此，那除了Anders、Chuck和Danny之外，大家一定要认识一下
负责开发Delphi/C++Builder集成开发环境的主要领导人Allen Bauer。
Allen Bauer是Borland的资深工程师，已经在Borland工作了相当长的时间。Allen除
了从Delphi 1开始便负责集成开发环境的研发工作外，还不断地翻新集成开发环境、
改善Delphi/C++Builder集成开发环境的公开标准：Open Tools API的架构。我曾经
在费城旅馆的电梯中和Allen交谈过，Allen讲话非常轻声细语，给人一种翩翩君子的
感觉。
Allen的这张照片应该是最近的，因为相片中的Allen比1999年我在费城时看到的样子
老了许多，看来最近几年Allen为Delphi/C++Builder的集成开发环境投入了不少的心
力。目前Allen正在为Galileo全力开发新的集成开发环境，据说Allen将在新的集成
开发环境中加入许多更强劲的功能，2003年我们继续关注Allen的下一个力作吧。
Borland RAD工具的推广大使
我非常怀念Charlie Calvert，因为在所有Delphi R&D小组中，我和Charlie Calvert
有过最多共事的经验。Charlie Calvert属于Borland Developer Relationship小组
中的资深经理，主要工作是负责开发全世界Borland RAD工具并协调其与使用者之间
的关系。Calvert不但是著名的Delphi/C++Builder Unleashed书籍的作者，前段时间
还撰写了JBuilder 7的书籍。
Charlie Calvert本人是一位素食者，为人非常的热情和蔼。他在Borland工作的后期
也参与了小部分Delphi和C++Builder研发的工作。Charlie Calvert曾说当Borland不
再开发全世界最好的工具时就是他离开Borland之际。两年前Charlie Calvert终于离
开了，这让我非常难过，我认为他的离开是Borland的损失。我曾经问过Charlie
Calvert，为什么要离开Borland？他回答说是因为不习惯当时Borland的转变(Delbert
乱搞开发工具的时期)而打算自己创业。不过令人高兴的是，在Charlie Calvert离开
Borland之后，他仍然在从事Borland相关工具的训练工作，看来Charlie Calvert仍然
对Borland的工具有着一份强烈的爱意。
Delphi的强中手
除了Delphi R&D小组之外，我认为最强的Delphi高手应该是Ray Lischner了。Ray
Lischner博土从Delphi 1开始就积极参与Delphi的相关工作，稍后更撰写了名震Delphi
圈的数本书籍，包括《Secrets Of Delphi 2》、《Hidden Paths Of Delphi 3》以
及《Delphi In a Nutshell》等好书，其深厚的Delphi功力也是Delphi R&D小组所公
认的。由于Ray的书籍一向令我折服，因此在Delphi 3时还特别要求台湾出版商引入
Hidden Paths Of Delphi 3，并且为Hidden Paths Of Delphi 3进行中文书籍的翻
译工作。
除了撰写书籍外，每一个Delphi的新版本，Ray都参加Beta测试。Ray是一个非常直率
的人，一旦遇到臭虫或是Borland没有做好的地方，他都会毫不留情地要求Borland更
正或是批评Borland没有尽力。我曾经在Borland内部的Delphi论坛中看到Ray精彩绝
伦地痛批Borland没有把产品做好。尤其在Delphi 4时更是不惧高层权势痛骂Borland
乱搞Delphi，看得我大呼过瘾。虽然我身为Borland的人，不敢骂Borland高层的人，
但是心中所想是和Ray一样的，而由Ray这位具有身份地位的人口中骂出，实在令我觉
得爽快，当然Ray如此做也是"爱之深，责之切"的缘故。因此直到现在，在参加RAD工
具Beta测试时，我还是最喜欢看Ray的评论，因为Ray的评论不但有深度，更敢直言，
通常是最有帮助的论坛讨论内容。
Delphi双响炮
说起Steve Teixeira和Xavier Pacheco这两位仁兄，相信也是许多Delphi程序员耳熟
能详的大人物，因为他们两位正是《Delphi Developer's Guide》这本好书的作者。
Steve Teixeira和Xavier Pacheco都曾是Delphi R&D小组的成员，不过这两位仁兄目
前都离开了Borland，各自创业去了，毕竟自己当老板更有赚头。说起Steve Teixeira
和Xavier Pacheco，令人好笑的是他们两人的身材实在是很强烈的对比，Steve
Teixeira年轻高大，而Xavier Pacheco则极为瘦小，因此当Xavier Pacheco站在
Steve Teixeira旁边时，Xavier Pacheco就像一个小孩一样。
我和Steve Teixeira比较熟悉，因为曾经和他在费城一起开过会，也有过交谈。
Steve Teixeira在Delphi R&D小组中负责比较低阶核心的除错功能，Steve Teixeira
让我想起当初Matt Pietrek在Borland的成长过程。由于Steve Teixeira和Xavier
Pacheco都是Delphi R&D小组的成员，因此他们自然能够取得最新、最深入的信息来
写书。
Delphi COM高手
说到使用Delphi来学习COM方面的知识时，就不能不提Binn Ly这位大名鼎鼎的人物，
Binn Ly也算是华人在Delphi圈中之光荣。话说在Delphi 3推出之时就以多层架构为
重点功能，强调Delphi能够撰写多任务的中间件服务器。不过了解内部技术的Delphi
程序员都知道，其实Delphi 3中的中间件服务器只能开发Single Threaded型态的COM
服务器，还不能开发真正的STA和MTA型态的COM服务器，这也是为什么Delphi 3的
MIDAS服务器在客户端使用者人数较多时执行效率就不甚理想的原因。
当时Binn Ly先生就指出了Delphi 3的问题，并且决定自己开发一个真正的Delphi封
装COM技术的framework，并且提供真正的STA、Apartment和MTA的解决方案。这在当
时是一项非常惊人的工程，因为除了Microsoft的ATL之外连Delphi都还没有提供，而
Binn Ly先生却决定完全使用Object Pascal来开发一个如此复杂的framework。后来
Binn Ly先生不但成功地开发出来，还在自己的网站上公开了framework的原始程序代
码，而且还写了许多COM和Delphi方面深入的技术文章。虽然在Delphi 4之后Borland
也终于慢慢地提供了比较完整的COM封装技术，但是Binn Ly先生在Delphi和COM方面
权威的形象已经深入Delphi程序员的心中，他本人也成为日后Borland邀请在BorCon
主讲COM/COM+讲座的台柱之一。
VCL．NET Architect
Eddie Churchill是在Delphi 3之后才加入Delphi R&D研发小组的，不过Eddie在
Delphi R&D研发小组中却上升得很快。
Eddie在加入Delphi R&D小组之后，便开始了Delphi中Diagram Designer的研发工
作，原本Eddie的工作是准备在Delphi中开发出UML的功能，以便为Delphi/C++
Builder提供完整的OOA/OOD的功能。
不过由于后来Borland高层决定和Rational合作，而且Eddie小组需要极大的资源来开
发，因此Borland的RAD部门便在Diagram Designer实现之后决定暂停这方面的研发工
作。其实在Delphi 3时，当时的Delphi产品经理Ben Riga就想为Delphi加入UML的功
能，只是一直无法拥有足够的资源来投入这方面的研发工作，一直到Delphi 5之后才
逐渐在Delphi/C++Builder看到这方面的初步成果。
现在Eddie Churchill和Danny等人投入开发Borland.NET方面的产品，并且是VCL.NET
的Architect，负责把VCL移植到.NET中，在2002年的BorCon中，Eddie Churchill就
说明了把VCL移植到.NET之上的困难和挑战，目前在Delphi使用可下载的Delphi For
NET Preview中已经可以看到Eddie Churchill在VCL.NET方面的初步成果了。
WebSnap始祖
Jim Tierry是在Eddie Churchill之后不久加入Delphi R&D研发小组的，他的第一个
工作就是接手Delphi的WebBroker技术，以开始打造Delphi/C++Builder的下一代Web
技术，初步的成果就是Delphi 5的InternetExpress。
不过在InternetExpress推出之后，Jim自己并不满意，因此立刻开始进行
InternetExpress下一代的开发工作，那当然就是WebSnap了。由Jim带领的WebSnap
开发小组终于在Delphi 6中推出WebSnap技术。不过也是由于资源的限制，因此在
Delphi 7中，Borland决定使用更为完整的IntraWeb作为Delphi在Web方面的主力。
目前Jim Tierry应该是在开发.NET下Web方面的技术和产品，我也希望在2003年能够
有机会和Jim见上一面，让他谈谈目前工作的方向。
Delphi Plug-In第一把交椅
我在日常使用Delphi时，一个少不了的工具就是Eagle Software出品的CodeRush，虽
然有些人认为CodeRush有点不稳定，但我认为CodeRush是一个非常好用的工具，当然
这也是为什么CodeRush几乎在每一年Delphi Magazine的年度产品评比中都是第一的
Delphi Plug-In工具。
CodeRush是由著名的Delphi高手Mark Miller先生开发的，Mark不但是多个产品的作
者，更是BorCon中经常受邀的主讲者。我曾经在许多地方和Mark有着交往，在2000年
澳洲的BorCon时我还曾经告诉Mark当时的CodeRush在中文Windows 2000中有臭虫，因
为当我使用CodeRush的快捷键时，CodeRush会送出重复的字符。Mark当场便拿出
NoteBook查询CodeRush的程序代码，并且要求我也打开我的NoteBook展示CodeRush
的臭虫给Mark看。在Mark了解了问题之后便询问我的旅馆房号，这才发现我们是住
在同一个旅馆。没有想到的是，当晚Mark便打电话到我的房间请我过去再次追踪这
个问题。后来Mark确定CodeRush没有问题，应该是中文Windows 2000在某些地方处
理的方式和英文Windows稍有不同，这应该是IME方面的原因，不过Mark答应我将会
提供walk-around的方式来克服这个问题。我回国后不久，就收到Mark寄来的一个
Patch档案修正了这个问题，其工作效率真是令人惊讶。如果读者也在使用CodeRush
这个产品，那可以经常到CodeRush的论坛看看Mark的发言，许多时候Mark的信件都
是深夜二三点寄出的，Mark工作的狂热的确令人吃惊，不过在Mark有了Baby之后这
个现象就比较少发生了。
MIDAS/DataSnap的掌舵手
Borland在Delphi 3便推出了MIDAS，一直开发到现在的DataSnap。其实Borland一开
始时就对MIDAS有非常大的野心，准备把MIDAS开发成中间件的标准技术。不过随着中
间件从以RPC为主变化成CORBA、COM/COM+以及EJB，Borland也很快地放弃了这个想法，
因为Borland不可能单独推出中间件技术来对抗业界的标准。
因此在Delphi 4之后，Borland便开始转变MIDAS的角色，把MIDAS定位成一个通用的
数据存取处理层技术，让MIDAS能够使用在CORBA、COM/COM+之中提供方便有效率的封
装数据存取功能，以弥补这些组件技术在存取数据方面的不便--必须使用一笔一笔数
据的方式来处理数据。
MIDAS这样的转变是非常正确的，因为在CORBA、COM/COM+中要存取数据实在是非常的
不便，经常必须在对象接口中提供特定的方法让客户端存取特定的数据，并且在移动
数据时也非常的麻烦，而MIDAS却提供了完整的解决方案。正是由于MIDAS的方便好用，
因此Microsoft也仿照在ADO中开始模仿MIDAS的功能，在ADO.NET中更是全面使用MIDAS
的观念来处理数据的存取。Borland也曾经把MIDAS移植到Java中成为JMIDAS，可是由
于Java世界非常强调标准，所有的标准都必须由SUN来制定，而SUN又使用JDBC、
Entity Bean以及现在的JDO来处理数据，因此JMIDAS之后就停止了开发。
Delphi 3、Delphi 4中的MIDAS都由不同的工程师负责。在Delphi 4中是由Josh负责
的，在这期间Josh和Dan Miser合作提供MIDAS的技术和解决方案，当时的Dan Miser
并不是Borland的员工，而只是MIDAS的爱好者。后来由于Josh离开了Borland，Borland
就把MIDAS的维护和新版本开发工作contract给Dan Miser，因此在Delphi 6之后的
DataSnap是由Dan Miser开发的，而Dan也成为了DataSnap的头领。
由于Dan Miser非常喜欢DataSnap，愿意为Borland工作，因此现在Dan已经到Borland
应征，准备正式成为Bodand的员工，继续把DataSnap移植到.NET上，并同时开发新的
DataSnap功能。
Delphi Spirit
Marco Cantu这位意大利的仁兄，应该是许多Delphi初学者都知道的人物，因为Marco
Cantu的《Mastering Delphi》一直是Delphi书籍中的长青树，深受初学Delphi的人
所喜好。
Marco Cantu也经常是BorCon的讲座主讲人以及Delphi相关杂志的专栏作家，不过我
一直无缘聆听Marco Cantu先生的讲座，因为每次我都选择了同时进行的其他讲座，
真是令人遗憾。
元老重臣
最后一个我想介绍的人物可能许多人并不熟悉，但是这位仁兄却一直是Borland开发
工具中的要角之一，那就是Bruneau Babet先生。Bruneau Babet很少公开露面，除非
在BorCon中读者才有可能见到他。
Bruneau Babet从Borland C/C++产品开始就是Borland的研发人员，在Borland C/C++
结束之后也转入Delphi R&D小组开发Delphi，而Bruneau Babet工作的重点一直是以
COM方面的技术为主。
Bruneau Babet除了进行Delphi的研发之外，主要的时间是负责C++Builder的开发工
作，因此他也从事C++Builder中融合ATL方面的工作，在BorCon中，Bruneau Babet演
讲的主题主要是Borland开发工具在COM/COM+的技术支持。
在这里，我无法介绍完所有相关的重要人物，除了上述几位外，许多大家熟悉的人物，
包括Dr. Bob、John Kaster等，我都没有介绍到。这是因为Dr. Bob和John Kaster
是许多人非常熟悉的，他们的照片在网站上可以经常看到，因此就不再列为重点，这
里是以读者不太熟悉的人物为主，让喜欢Delphi/C++Builder的读者能够看看这些杰
出软件人员的长相、了解他们的个人资料，让许多"久闻其名"的人物真实地呈现在我
们面前，作为我们学习的借鉴。
^v^v^v^v^v^v^v^v^v
第五章 逆转的奇迹--Borland JBuilder的战斗发展史
"没有JBuilder，Borland就不可能拥有今日的荣景！"
Java的快速兴起和成功是谁也没有预料到的，即便对于SUN自己似乎也是一个极大的
意外，但是成功者一定是果断而且行动迅速的。当SUN察觉到Java的光明未来之后，
便立刻开始大力推销Java。SUN的总裁McNealy先生数年来苦于没有直接和Microsoft
对抗的机会，这下在Java的身上似乎找到了契机，当然更重要的是SUN接下来的一连
串行动都被证明是正确而成功的。这些行动包括和各种厂商合作；与Addison-Wesley
公司合作出版一系列畅销且成功的Java书籍；在各大媒体占据版面发表所有与Java相
关的文章、专栏等；快速培养Java使用者的基础，吸引大众对于Java的兴趣。这完全
是Microsoft一向无往不胜、攻无不克的手法，SUN也发挥得淋漓尽致，并且"以彼之
道还施彼身"。更重要的是McNealy立刻果断地投入大量的研发资源，不断地改善Java，
终于使Java从1995年开始展露锋芒，并且快速地成为业界焦点，自此展开了PC发展
史上最大规模对抗Microsoft的争霸战，也改变了许多软件开发的习惯和方向。当然
对于Borland来说，Java的发展史也是一场惊涛骇浪的生死之战，是Borland从未经历
过的大规模集团军混战。
对于Borland来说，事情并没有那么顺利。1995年，当Java开始起飞时，Borland并没
有预料到Java成长的速度会如此之快。Borland一开始只是把Java当成C/C++的延伸，
因此只在Borland C/C++5.0中加入了支持Java的P1ug-In。不过Borland很快就发现事
情并不是如此简单，因为除了Java的Plug-In反应并不好之外，也发现Symantec很快
在Java开发工具找到了新舞台，而且发展得相当快速。在Microsoft对Java的态度未
明之前，无疑Symantec占据了先机，Borland这才警觉到自己的失策，Java大会战一
开始Borland就已经落后了。Borland如何才能在下一场最重要的开发工具大战中进行
反攻呢？
Java开发工具初期的争战
当Symantec从C/C++开发工具市场大撤退之后，Eugene Wang不愧是相当高明的开发工
具好手，立刻察觉到尽管在C/C++市场遭遇失败，但利用原有力量却可以在即将茁壮
成长的Java市场上扳回一城，因此立刻率领原先Symantec C/C++的开发团队快速进入
Java开发工具的领域。Eugene很快以当初Symantec C/C++的集成开发环境作为基础，
开始开发Java开发工具，这就是后来著名的Visual Café。
Symantec几乎是第一个介入Java开发工具的软件公司，又利用了Symantec C/C++的基
础，因此在1995年，当Java获得愈来愈多人的注意之后，Symantec也准备好了她的第
一个Java开发工具--Visual Café。1996年10月，Symantec赶在JDK 1.1之前正式推
出了Visual Café。虽然当时许多人批评Symantec为什么不等到JDK 1.1之后再推出，
以支持最新的JDK标准(因为当时的JDK 1.0x版本有许多的问题)，不过这些批评并
没有妨碍Visual Café的成功。
由于当时许多软件人员急于投入Java的学习行列，因此当Symantec推出了Visual Café
之后，立刻在市场获得了极大的成功。特别是在Java学习市场和教育市场，Visual
Café几乎是以席卷市场的姿势迅速占据了Java开发工具第一名的地位，成为炙手可
热的产品，而Symantec公司也一扫在C/C++开发工具被挫败的怨气，再次成为开发工
具市场的领导厂商。
由于当时Microsoft对于Java采取敌视的态度，因此几乎不可能推出Java开发工具，
而Borland也还正陷于C/C++的苦战之中，尚未查觉到Java的潜力。至于另外一个死对
头Watcom则已被Sybase并购，无法在开发工具市场再成气候。这对于Symantec来说简
直是天赐良机，一个可以独打Java开发工具市场的绝佳机会。剩下唯一的威胁是SUN
要推出的Java开发工具。但是Symantec已经抢得市场先机，而且已经成为领先者，只
要好好的把握，就能够以逸待劳和SUN对战。在这个Java开发工具萌芽的阶段，Symantec
似乎是占了绝对的优势，不过很可惜的是接下来Symantec也接连犯了几个错误，逐渐
失去了取得的优势。
首先是当Visual Café推出之后，Eugene Wang便离开了Symantec自己开公司做生意
去了。这对于Visual Café有着相当大的影响，因为Symantec靠着Eugene Wang的技
术能力和眼光，才能够和Microsoft、Borland和Watcom在C/C++开发工具市场对抗；
Eugene Wang又独具慧眼打造了第一个Java开发工具Visual Café。Symantec应该在
Visual Café获得初期的胜利之后再次借重Eugene Wang的功力继续攻城掠地，但是
Symantec居然让Eugene Wang离开，立刻少了开发工具掌舵的大将。
第二个错误是Symantec当初为了尽快推出Visual Café以抢占市场先机，因此集成开
发环境是使用C/C++语言撰写的。这造成了数项缺点，其一是由于使用了C/C++来撰写
可视化窗体设计家(Visual Form Designer)，因此程序员在设计时看到的可视化效果
和真正Java程序执行时的效果是有一些差异的；其二是为了维护Java的控制组件程序
代码和以C/C++撰写的可视化窗体设计家保持同步的状态，在可视化窗体设计家产生
的原始程序代码中内嵌了一些Visual Café控制卷标(Control Tag)。这些控制卷标
并不是Java的程序代码，只是为了可视化窗体设计家使用。如果程序员不小心修改或
是删除了这些控制卷标，就会造成Visual Café的可视化窗体设计家的失效。这是非
常严重的缺点，Symantec应该在Visual Café 1.0之后立刻改善这些问题，然而Symantec
却似乎一直无法有效地加以改善。当然，问题的根源在于Visual Café的集成开发环
境是使用C/C++语言撰写的，要完全改善这个问题，Symantec必须使用Java语言重新
改写集成开发环境，这正是Borland后来采取的策略。不过使用Java撰写集成开发环
境也是非常冒险的行动，Borland后来因此付出了沉重的代价。Symantec之所以没有
如此做，大概也是因为当时的Java并没有成熟到可以如此做的地步。不过SUN显然不
这么认为，其对Java信心百倍，不久就推出了SUN的Java开发工具，Java Workshop。
当Java成功地掳获了开发者的心之后，对于Java开发工具的要求便与日俱增。虽然
Symantec已经推出了Visual Café，但是许多人仍然希望Java的正宗厂商SUN能够推出
Java开发工具，让所有想要学习、使用Java的开发人员能够使用最标准的Java开发工具。
当然，许多人也希望SUN能够使用Java撰写Java开发工具来向世人证明Java的能耐，让
质疑Java能力的人以及Microsoft闭嘴。当然，SUN在Java成功之后也信心满满地宣布
了SUN的开发工具计划，以满足广大开发人员的需求。McNealy多年来进攻Microsoft
地盘的希望似乎即将出现光明的未来。
之后不久，在万方期待之下，SUN终于推出了Java开发工具SUN Workshop。在Java
Workshop即将推出之前，Symantec非常地紧张，因为这关系到Symantec是否能够在Java
开发工具市场站稳脚跟。我记得在Java Workshop推出之际，所有的媒体、杂志都大
幅报道Java Workshop，SUN也大力地宣传和促销Java Workshop。从当时的气势来看，
Java Workshop颇有"千秋万世，一统江湖"的味道。我所认识的许多朋友不管是用买
的、借的、下载等和--嗯--那个的……各种手段，都热切地想取得一套Java Workshop
来玩玩。不过丑媳妇总要见公婆的，在许多人使用了Java Workshop之后，才发现它
不但执行缓慢得像乌龟一样，而且问题多多，和一般的PC开发工具水准比起来简直是
差了十万八千里。看来Java Workshop只适合使用在昂贵的SUN工作站计算机上，而在
当时大多数人使用的PC上则根本跑不动，除非是拥有异于常人的耐性。
Java Workshop雷声大雨点小，不久之后就人气溃散了。许多原来对Java有信心的人
在用了Java Workshop之后，也开始质疑Java是否适合使用来开发复杂的应用程序？
是不是只适合用来撰写Applet？是不是只适合使用在SUN的工作站和计算机之上？虽
然之后SUN仍然很努力地推出Java Workshop 2.x的版本，希望一洗Java Workshop
1.x的恶名，但是仍然无法挽回Java开发人员的信心。至于其他仍然对Java有兴趣的人
则转而使用Symantec的Visual Café，让Visual Café进一步地扩大了市场占有率，
也让Symantec吃了一颗定心丸。当然也有许多Borland的支持者开始强烈地期望和要
求Borland能够推出最好的Java开发工具。
SUN在Java开发工具市场大溃败之后，才了解到PC开发工具市场和Solaris开发工具市
场不一样。在Solaris上SUN是一家独大，但是在PC市场上可是百家争鸣，竞争对手一
个比一个强悍。SUN不了解PC开发工具市场的特性，以为靠着Java正宗的招牌就可以
通行无阻却是大错特错，并且在当时被Microsoft讥笑不懂得开发软件，这也是因为
SUN经常讥笑Microsoft不懂得开发操作系统，看来在当时SUN也不必五十步笑百步。
SUN在Java开发工具市场弄得灰头土脸之后，不得不专心开发Java语言和JDK函数库，
并且在Java语言更为成熟之后开始想要开发Java的组件技术，因此开启了稍后和Borland
合作共同开发Java Bean的功能规格，再进而和Borland共同研发JDK的规格，最后更
对Borland的JBuilder发生了强烈的兴趣，甚至想并购Borland。当然这都是因为后来
Borland展现在了Java方面高度的技术，让SUN从肯定到折服的原因所致。
Borland的Java艰辛奋斗
"事情并没有这么顺利"，Borland当时的R&D主管这么说，并且充满了焦虑。当Borland
警觉到Java的潜力之后，Visual Café早已成功地上市，SUN也准备推出Java的开发
工具。当时Borland正逐渐从C/C++市场失去王者的地位，财务上也开始出现经营赤字，
整个公司正陷于一团混乱的情形中，似乎已经没有额外的资源可以投入Java的研发。
在起步落后，又缺兵少粮的情形下，Borland似乎即将失去进入Java市场的希望。
好在稍后的Delphi一炮而红，让Borland大赚了一票，也稳定了军心。Delphi为Borland
注入的资源也很快让Borland激活了Java研发小组。虽然Borland已经落后许多，但是
Borland知道绝不可以失去这个市场，因为Java的市场没有Microsoft式的寡占，Borland
有希望在Java市场比Borland C/C++、Delphi等更成功。此外，Borland更需要在Delphi
这条产品线之外开拓其他的收入来源，否则只靠Delphi产品，公司仍然无法成长得更
为茁壮，以和其他的软件公司竞争。
在1994、1995年间，Borland正式成立了Java研究小组，开始研发Java的技术，准备
开发Java开发工具。这个Java开发工具的内部研发名称便是Latté。一开始Latté小
组的研发资源并不够多，因为当时的Borland是在风雨飘摇之中，无法注入足够的资
源到Latté小组。因此在Latté开始开发的初期进展得并不顺利，进度很缓慢。一直
到了Borland靠Delphi浴火重生之后Latté小组才有了足够资源，研发的进度才开始
加速。不过与竞争对手们比起来，Borland在Java方面的确是相当落后的，几乎是跑
在最后的参赛者。不过幸运的是Java开发工具之战似乎是一场漫长的马拉松比赛，除
了一开始的表现之外，更重要的是比谁能够撑得比较久。事实上看Borland如何在Java
竞赛场上反败为胜、一一打败强者，进而成为Java开发工具王者的过程是相当精彩的，
而JBuilder小组使用的竞争策略更值得我们玩味和学习。
依我个人的眼光来看，在Borland开发Java开发工具的过程中经历了数个不同的阶段，
每一个阶段都有着非常激烈的竞争，有着成功者和失败者。只是有的失败者仍然坚
持竞争下去，有的却随风消散。JBuilder最终能够成为王者，除了是因为愈挫愈勇、
Borland没有退出Java市场之外，还在于Borland在开发JBuilder 3时下了一个关键性
的决定，以及在JBuilder 3之后每一个版本都有明确的目标，终于在JBuilder 4之后
慢慢成为市场第一的领导者。当然这长达数年的争战过程是非常艰辛的，不过这段历
程正是整个Java开发工具逐鹿中原的写照史。
第1阶段--Java JIT编译器的战争
Borland也许不是最晚开始研发Java技术的厂商，但是明显地落后于其他竞争对手则
是不争的事实。Borland在Latté万事尚未具备的情形下，展开Java竞赛的第一步便
是从Borland传统的拿手绝活开始，那就是从Java JIT编译器开始出发。不过由于Borland
当时对于Java技术尚未拥有良好的掌握，因此一开始是和Pascal的祖师爷Dr. Niklaus
Worth合作，由Dr. Niklaus Worth以及他的学生们为Borland研发Java JIT编译器，
而Borland本身的Latté小组则平行地开发Latté其他的功能。由于当时Java已经逐
渐在校园流行，而且吸引了许多学术研究的兴趣，Dr. Niklaus Worth以及他的学生
们很早便开始投入Java相关的研究。因此当Borland找上门之后，自然便一拍即合。
Borland缩短了开发时程，而Dr. Niklaus Worth研究小组则乐得有人赞助研发费用。
Dr. Niklaus Worth研究小组的第一个作品就是在1997年初左右推出的Java JIT编译
器，这个由Dr. Niklaus Worth研究小组研发的JIT编译器可以让编译后的Java ByteCode
执行速度比当时SUN的Java编译器以及Symantec的JIT编译器快了数倍。Borland宣布
此JIT编译器之后立刻震惊了Java界，因为当时缓慢的Java执行速度是所有使用Java
的人都希望能够立刻大幅改善的。而Borland推出的Java JIT编译器似乎给所有Java
开发人员看到了未来的希望。虽然严格地说当时即使是使用Borland最新的JIT编译器
编译Java程序，其执行速度仍然是很"龟速"的，但是对于使用Java来学习程序设计或
是撰写、执行一些小的Applet来说仍然是很好用的。因此当Borland一推出此JIT编译
器之后，便立刻打响了Borland在Java界的知名度，所有Java开发厂商也开始视Borland
为认真的竞争对手。否则以当时Borland的气势来看，除了Delphi之外，Borland几乎
已经一无所有了。
Borland在Java的处女作Java JIT编译器一炮而红，立刻吸引了当时浏览器霸主Netscape
的注意。由于当时Netscape大力支持Java以便和Microsoft竞争，因此非常需要有品
质精良的Java JIT编译器内建在Netscape之中，以顺利且快速地执行Java Applet，
增加Netscape的竞争力和吸引力，突显与Microsoft IE的不同。不久之后Netscape便
找上了Borland，希望能够在Netscape中附带Borland的Java JIT编译器。
对于Borland来说，这又是一个千载难逢的机会。因为这不但证明了Borland在Java技
术的努力成果，更重要的是Netscape在当时是不可一世的软件公司，全世界有数百万
的使用者。这意味着一旦Netscape内建Borland的Java JIT编译器，Borland在全世界
将立刻拥有数百万的Latté潜在使用者，对于Borland来说是好得不能再好的条件了。
因此Borland立刻答应了Netscape的提议，让Netscape搭配Borland的Java JIT编译
器。但是这一举动也立刻牵一发而动全身，进而导致了Java JIT编译器的大混战。
在Netscape和Borland达成了协议并且开始出货之后，却引起了Symantec的忧虑和不
满。因为当时Symantec是Java开发工具的老大，而Borland连个Java开发工具都尚未
推出，可是Netscape却跑去使用Borland的Java JIT编译器，这不是让全世界都知道
Borland的实力并且让Symantec脸上无光吗？为了颜面以及避免失去Java开发工具的
市场，很快Symantec便决定开始反击。Symantec立刻也集中资源投入Java JIT编译器
的研发，开发出比Borland Java JIT编译器更快的Symantec JIT编译器，并且准备开
发一个直接把Java ByteCode编译成原生Windows程序代码的Java编译器。就在Borland
Java JIT编译器风光不久之后，Symantec也宣布了新的Java JIT编译器。Symantec
的Java JIT编译器比Borland Java JIT编译器更有效率，编译后的Java ByteCode执
行效率比Borland的快了2~3倍。
在Symantec Java JIT编译器宣布之后，又轮到.Borland脸上无光了。才刚和Netscape
谈好合作条件，没有想到效率王位还没坐热就立刻被Symantec踢了下来，这如何向
Netscape交待？因此Borland立刻进行改善JIT编译器的研发工作，力图再次超越
Symantec。果然Borland的努力没有白费，不久之后Borland的JIT编译器又打破了
Symantec JIT编译器创下的效率纪录。自此Borland和Symantec便展开了Java JIT编
译器的"竞速"比赛，不断地试图打败对方。也由于Borland和Symantec的JIT竞赛，当
然更重要的原因是Java的执行速度在当时实在是太过缓慢，引起了IBM、Microsoft以
及SUN在Java编译器方面的研究。
Symantec在当时不愧是Java开发工具的王者，在和Borland几次的JIT编译器交手之后，
便开始逐渐地占了上风。由Dr. Niklaus Worth研究小组研发的Java JIT编译器也
逐渐不再是Symantec的对手。至此Borland决定收回Java编译器的技术，开始自行研
发。Borland发觉光是和Symantec在Java JIT编译器竞争没有多大用处，当务之急是
赶快推出自己的Java开发工具。因此Borland开始退出和Symantec在Java JIT编译器
的竞赛，以求全速催生Latté。当然Borland退出JIT编译器的第一阶段战争之后的影
响是不久之后Netscape便不再使用Borland的Java JIT编译器，改为使用Symantec的
Java JIT编译器。至此Symantec终于获得了JIT编译器第一阶段的战争胜利，保住了
Java开发工具第一厂商的颜面。但是Symantec真的获胜了吗？那可不能断言，因为JIT
编译器战争才刚开始。
在Symantec的Java JIT编译器打败了Borland的JIT编译器之后，Symantec便把脑筋动
到了SUN的身上，希望SUN也能够使用Symantec的Java JIT编译器，把Symantec推向Java
核心技术的领导厂商宝座。不过Symantec的盘算显然是落空了，因为SUN已经决定收
购一家专门研发Java编译器技术的软件公司，并且准备开发自己的JIT编译器，那就
是后来的SUN HotSpot编译器技术。另外Microsoft和IBM也开始加入了Java JIT编译
器的竞赛之列。IBM为了和SUN争夺Java领导者的地位，不但自己研发IBM的JDK，甚至
也研发IBM的Java JIT编译器。严格地说，当时IBM的Java JIT编译器品质比SUN提供
的好多了，不但稳定而且执行速度比SUN的快了许多，让SUN也颜面无光，很不是滋味。
甚至可以说IBM的Java JIT编译器品质不会比Symantec的Java JIT编译器差到哪里。
更麻烦的是Microsoft为了让IE能够和Netscape竞争，也可以执行Applet，因此也开
始研发精良的Java JIT编译器。特别是当Microsoft得到了Anders Hejlsberg之后，
在编译器技术方面有了重大的突破。虽然Microsoft的JIT编译器一直不像其他厂商的
Java JIT编译器那么符合标准，但是其品质却是相当的精良。在Microsoft不断地改
善之下，依我当时的测试，经其编译后的Java ByteCode执行的速度是最快的，连IBM
和Symantec的JIT编译器都不是对手。因此从我的观点来看，在这个Java JIT编译器
的阶段，应该是Microsoft获了冠军。要不是Microsoft没有持续支持最新的JDK标准，
又混杂了一些Microsoft自己的东西，到最后很可能使用最为广泛的Java JIT编译器
反而就是Microsoft的JIT编译器。
至于Symantec，在取得了JIT编译器表面上的优势之后，立刻又把重点放在了开发直
接把Java ByteCode编译成原生应用程序的原生Java编译器。稍后Symantec成功地开
发出了这种编译器，让Borland大为紧张，并且准备跟进。而Symantec也把这个原生
Java编译器加入到Visual Café中，成为一项吸引人的功能。不过很快地这个功能却
引起了许多Java使用者的批评，因为他们认为这违反了Java"Write Once，Run
Everywhere"的精神，如此一来厂商必须为每一个不同的平台开发原生Java编译器，
这会造成Java应用程序在不同的平台执行的反应不一致的现象，又陷入C/C++语言开
发的应用程序在不同的平台表现不一的相同问题。后来连SUN也不赞成这种做法，当
然这是因为SUN想力推自己的HotSpot编译器技术。因此原生Java编译器在风行了一阵
短暂的时间之后就不再吸引人注意了，而Borland原本为JBuilder开发原生Java编译
器的计划也因此而打住。
Microsoft VJ++的威胁
1996年，Anders Hejlsberg来到Microsoft之后的第一个作品即将推出，那就是
Microsoft VJ++。VJ++的即将推出，对于许多软件公司而言都是一个很大的震撼。
对于SUN来说，这是Microsoft在Java领域的挑战。在SUN自己的Java开发工具不争
气的窘境之下，又得面对擅长开发工具的Microsoft，特别是由Anders领军开发的
精品。对于其他的Java开发工具厂商来说，也是提心吊胆。Visual Café在JBuilder、
Visual Age For Java陆续推出之后市场占有率已经慢慢地被瓜分，现在又得再次面对
Microsoft的竞争，昔日Symantec C/C++失败的阴影又缠上了心头。而Microsoft的死
对头IBM更是在VisualAge For C/C++、VisualAge For BASIC连番失败之后，好不容
易推出了VisualAge For Java，准备在Java开发工具市场打一场好球赛，没有想到
现在Microsoft又来搅局。
对于Borland来说，这个消息更是令人不安，因为Borland本身的Java开发工具仍然处
于研发阶段，还没有推出，而且看样子将会是市场上最后一个推出的Java开发工具，
落后主要竞争对手已经很多了。现在Microsoft居然更早一步推出Java开发工具，而
且是由Anders Hejlsberg主持开发的。Borland当然知道Anders Hejlsberg的实力，
自然不敢轻视VJ++的影响力。更麻烦的是在VJ++推出之前，Microsoft一直对VJ++保
持模糊的态度，不愿意表明VJ++是否是一个纯正Java开发工具。更让Borland惊讶的
是，Borland内部对于VJ++ Beta的测试表明VJ++编译出来的程序代码在某些方面居然
比Delphi等原生的Windows开发工具执行得还快速。这意味着VJ++不但对于Java开发
工具可能会有严重的影响，甚至对于一般的Windows开发工具都有可能造成威胁。不
过Borland分析如果VJ++真的开始对Windows开发工具产生威胁，那么VB将会是受到影
响最大的开发工具。但Borland仍然感到忧心，因为VJ++仍然可能对于Delphi和C++
Builder产生一定的影响，这是Borland不乐意见到的。当然这也加速了Borland研发
Latté的决心，因为已经不能再拖了。
记得当时我还和Borland在亚洲新加坡R&D总部的Mr. Inn Nam Yong谈过VJ＋+的表现
以及对于VJ++可能产生影响的忧虑。Mr. Yong也说VJ++的表现令他们吃惊。看来Anders
Hejlsberg在VJ++的编译器技术上下了苦功，其表现早已超过了当时一般的Java编译
器技术，的确是令人刮目相看，更麻烦的是从VJ++的身上依稀可以看到Delphi的身影。
Borland的R&D已经了解了这个情形，Borland的编译器小组也在研究相关问题的技术。
由此可见当时Borland已经如临大敌，开始准备相关的技术，并且已经掌握了初期的
状况。
Microsoft VJ++在1996年11月终于正式推出了，全世界也都屏息以待，准备看着VJ++
会产生多少的毁灭力量，而SUN更准备看看Microsoft是否会违反任何SUN和Microsoft
之间的Java协议。当然SUN是担心Microsoft想破坏Java的开发。VJ++在一开始果然获
得了一些回响，毕竟这是Microsoft推出的Java工具，使用Microsoft开发工具的软件
人员当然会考虑VJ＋+。同时VJ++也吸引了一些想使用Java语言、但是仍打算呆在
Windows平台的开发人员。
不过VJ++推出之后也很快受到了所有Java开发工具以及支持Java平台厂商的全面围剿。
他们害怕Microsoft对Java市场的入侵，会让其他厂商再次无法生存。之后连SUN也开
始领军围攻Microsoft，因为SUN除了害怕Microsoft会慢慢地主宰Java平台和标准之
外，还发现Microsoft正在很有技巧地逐步破坏Java语言和标准，例如VJ++便提供了许
多非标准的Java用法并且很明显地把VJ++绑死在Windows平台，破坏Java的"Write
Once，Run Everywhere"的美梦。而且，Java开发人员如果大量使用VJ++，那么便再
也离不开Windows平台。Microsoft计划通过提供一流的"类Java开发工具"来限制开发
人员的自由选择权的企图是昭然若揭了。
由于SUN的带头批判，想使用Java的开发人员和企业很快地发现VJ++并不是标准的Java
开发工具，因此对于VJ++的热情很快消退了下来。而VJ++对于Java以及Windows开发
工具的威胁也很快地解除了。VJ++对于Microsoft来说很可能是自DOS版的Microsoft
Pascal之后第2次在开发工具的大失败。不过依我的观点来看，VJ++在本质上是一个
优秀的产品，不论是编译器、Framework和集成开发环境都有高水平之作。VJ++之所
以败阵下来实在是因为形势比人强，Java平台也是第一次不是由Microsoft所主宰的
市场。在Java联军的合攻之下，即使是软件巨人也得回避三分。
因为第一次在Java出击就弄得灰头土脸，并且SUN摆明了不会允许Microsoft在Java平
台成气候，使得Microsoft下定了和SUN正面开战、在Java市场上全面开火的决心，进
而造成了SUN控告Microsoft违反Java合约的规定的结果，而Microsoft稍后则干脆把
Java支持从操作系统中移除。当然，这是Microsoft和SUN之间的Java平台之战，已超
出本书讨论的范围，也许应该由Microsoft或是SUN的人来说明这整个过程。
虽然事后证明VJ++在Java开发工具是失败了，但是Anders Hejlsberg在VJ++中花费的
心力却没有白费，因为VJ++的编译器技术以及Framework和集成开发环境的技术都在
稍后融入Microsoft .NET计划的基础核心技术之中。例如C#的语言和Java很相像，
C#的编译器技术想必也借重了许多当初VJ++优秀编译器的技术，因此C#编译器的最佳
化结果也在一些方面胜过了现在许多原生Windows开发工具的编译器水准。Anders
Hejlsberg的努力正激活了Java和.NET的正面决战。
IBM VisualAge For Java的推出
IBM在PC开发工具市场的表现一直令人摇头，因为其"玩玩便跑"的作风总是让人无法
放心使用它的开发工具。但是也许是IBM的招牌太大，再加上它会免费向购买IBM机器
或是软件的客户奉送IBM开发工具，因此也总是有人会去使用IBM的开发工具。我个人
在受了IBM VisualAge For C/C++的教训之后，便对IBM的开发工具敬谢不敏了。
IBM当然不会放弃Java这个潜力无穷的市场，因为对于IBM来说，Java不光是语言和开
发工具而已；更重要的是Java平台牵涉到IBM和SUN在庞大商机的硬件和大客户之间的
竞争。IBM不光是要支持Java，更想从SUN手中取得Java的主控权，因此对于重要的Java
开发工具市场，IBM自是不会缺席。IBM很快采用了许多当初在VisualAge For C/C++
中相当受欢迎的元素作为开发VisualAge For Java的基础。例如VisualAge For C/C++
的项目管理功能、组件设计家等等。事实上使用过VisualAge For C/C++的读者会发现
VisualAge For Java非常的具有亲切感。不但所有的按钮都是采用圆形造型，甚至连
激活时缓慢的感觉、整个集成开发环境温温吞吞的表现也非常相似。由于采用了
VisualAge For C/C++的部分观念和程序代码，再加上IBM拥有最丰富的资源，因此
VisualAge For Java进展得很快。
1997年9月，IBM终于推出了VisualAge For Java，开始直接和SUN、Symantec竞争。
在IBM推出了VisualAge For Java之后，Borland注定成为最后一个推出重量级Java开
发工具的厂商。不过IBM的竞争目标明显不是Symantec和Borland等纯粹以Java开发工
具为目标的厂商，而是SUN和Microsoft。IBM在Java技术方面采取了数个平行的战略，
希望能够在Java世界中取得龙头地位，因为这关系到IBM最大业务--硬件销售、服
务提供以及IBM操作系统销售的收入。如果IBM能够在Java世界取得决定性的地位，那
么就可以侵蚀SUN的市场，最不济的情形则是不希望客户因为想要使用Java技术而自
然地想到SUN。至于另外一个锁定目标Microsoft，IBM则是打算通过Java日益扩大的
声势来打击或是抑制之。
因此IBM一方面和SUN签订Java合约，取得Java使用的合法授权，另一方面又投入大量
的研发资源开发自己的JDK版本以方便移植到IBM其他的专属平台，而且做得比SUN的
JDK还要稳定和有效率，随后让SUN和IBM之间一直有不和的争执。接着IBM推出了Java
开发工具，再次和SUN的Java Workshop竞争。不过从特性上来看，VisualAge For Java
锁定的客户群应该是IBM的客户、大型企业客户以及其他直接竞争对手的客户，例如
SUN的客户以及HP的客户。VisualAge For Java需要比较强劲的机器来执行，此外一
开始的版本就非常注重团队开发的支持，不像其他的Java开发工具一开始都是注重在
方便、实用的功能，稍后才逐渐强化团队开发的功能，这些差异都是IBM想争抢较大
型客户的证明。这也可以从后来许多专业媒体和杂志在进行Java开发工具评比时
VisualAge For Java几乎都在团队开发功能方面获得了最高的评价得知。由于VisualAge
For Java一开始锁定的客户群和Visual Café以及JBuilder锁定的客户群不同，因此
在Java开发工具的竞争初期并没有发生严重的竞争冲突。但是随着Visual Café和
JBuilder逐渐往上仰攻企业市场，而VisualAge For Java为了扩大市场而开始降价
进入一般Java大众市场之后，稍后的Java开发工具恶战也不可避免了。
第2阶段--Java集成开发环境的战争
Borland在初期以开发Java JIT编译器练兵之后，已经逐渐对于Java的技术有了掌握。
在Java Workshop、VJ++和VisualAge For Java陆续推出之后，Borland知道再也不能
够延迟JBuilder的推出时间了，否则就注定要退出Java开发工具的市场。因此Borland
对JBuilder的研发小组下了最后的通牒，一定要在1997年推出JBuilder。
JBuilder小组在竞争的第一阶段掌握了Java的JIT技术之后，立刻兵分多路展开了整
个JBuilder的开发工作。虽然Java是一种全新的语言以及革命性的平台，但是开发工
具总不外乎编译器、集成开发环境、数据库存取能力、Framework以及其他的工具和
Plug-In等。当时的Latté小组有许多成员是从以前的Borland C/C++转进来的，另外
的一些成员则包括了Borland原本的软件研究成员、Paradox成员、Visual dbase成员
以及从Borland外部找进来的新工程师。
在Borland开发JBuilder之时，由于Java尚没有完整的组件架构，也没有数据感知组
件标准以方便地开发Java数据库应用程序，更加没有完整的Java可视化组件，因此
Borland决定先自行开发一套组件组以便让JBuilder拥有最好的组件开发能力。这刚
好又是Borland擅长的技术，因为Borland要为Java开发一套Java Framework，这就是
JBCL(JavaBeans Component Library)的由来，而JBCL的架构稍后也成为SUN制定
JavaBean的基础技术。
当时负责JBCL架构的Architect是Joe Nunoll先生。这位帅哥原本属于Paradox小组，
在Borland逐渐失利于桌上型数据库战场之后，便转到Latté小组专门负责设计Latté
的组件架构。
而JBCL的主要实现工程师则是当初设计和实现Borland C/C++ Framework-OWL的总工
程师Carl Quinn。Carl Quinn在组件设计和Framework方面都有丰富的经验，OWL就技
术而言也算是精品。因此在Borland C/C++产品线停止之后，Carl Quinn由C/C++转换
到Java跑道是很自然的事情，毕竟C/C++和Java是很类似的。Carl拥有丰富的经验，
由他来带领开发Latté的组件Framework是再适合不过了。
由于Carl在JBCL的努力和成果，稍后又负责了Borland的Java组件模型Baja的开发。
之后Carl凭借着对于JBCL和设计Baja的经验，在SUN采用Baja做为JavaBean的核心基
础技术之后便自然地受邀于JavaBean的开发小组。由于Borland在Java组件方面卓越
的表现，因此也开启了SUN和Borland逐渐密切的合作。Borland虽然在Java方面投入
的时程稍晚，但是却凭借着扎实的技术而慢慢迎头赶上。
Latté的Framework开发在Joe Nunoll和Carl Quinn的带领之下有了稳定的发展。事
实上JBCL的表现一直是非常优秀的。当Latté随后正式推出时，JBCL也是让Latté得
以脱颖而出的重要功能之一。Joe Nunoll和Carl Quinn的功劳可谓不小，而我钦佩的
Carl Quinn又再次在Java方面证明了他坚实的技术和在Framework方面丰富的设计和
实现经验。
Java Framework虽然重要，但也只是整个完整开发工具的支柱之一。Latté要推出仍
然需要编译器和集成开发环境的功能。在Java编译器方面，Borland和结束委托
Dr. Niklaus Worth研究小组开发Java JIT编译器之后，Latté开发小组便开始展开
研究的工作。当时JIT编译器已经全面开战，而Borland在Latté尚未推出、还没有足
够资源的情形下如果再介入JIT的战争，那么不但胜算不大，而且可能会严重影响Latté
的推出时程。因此Latté小组决定先专心开发一个编译品质良好，而且能够和Latté
完美搭配的Java编译器，而不再强求效率至上。
从现在的观点来看，当时Latté小组的决定是非常正确的。因为：第一，当时Borland
的确没有太多的子弹；第二，Latté的时程再也不能拖延；第三，也是最重要的是稍
后SUN宣布了开发Hotspot编译器技术的计划，顿时之间所有Java JIT编译器的风头都
被SUN抢走了。特别是在稍后SUN决定将Hotspot内建在JDK中之后，争夺Java JIT编译
器不但变得没有意义，而且对于Java开发工具而言也没有什么附加价值了。因此在SUN
的Hotspot编译技术揭露之后，Symantec很快就在Java JIT编译器市场上销声匿迹了。
Latté小组确定了Java编译器的策略之后，立刻便接手Dr. Niklaus Worth研究小组
的后续开发工作，同时开发Latté的编译器、Latté的Plug-In以整合Java编译器到
Latté的集成开发环境中，并且也进行Java编译器最佳化的研究工作。当时这个Java
编译器开发小组由Carl Fravel等人带领，同时也包括了Borland的编译器小组。Carl
Fravel主要负责Latté的编译器以及编译器的Plug-In软件，此外他也参与了Latté
数据库方面的开发。当时Java在数据库存取方面仍然相当弱势，Borland为了加强Latté
这方面的功能，决定先借重Delphi在数据库方面的成绩，即通过JDBC标准接口封装
Delphi已经有的各种数据库驱动程序，让Latté能够立刻连接到最多的数据库，这就
是后来JBuilder的DataGayteway。
除了Carl之外(嗯，Latté开发小组有两个Carl)，Sergio Cardoso也是Latté编译器
最佳化的成员。Sergio原本是Borland C/C十+的开发者之一，专门研究C/C++最佳化
的技术，他和Carl Quinn等人一样转移到Java的产品线。Sergio和Carl Fravel合作，
负责打造Latté的核心引擎。在Latté上市之后，事实上每一版的JBuilder的编译
器都有进步。就现在来说，在JBuilder 7/8中编译Java应用程序相当的快速。这说明
JBuilder和当初Borland C/C++一样，都是在初期版本快速地强化引擎、不断地提升
速度。
当时的Latté并没有一个真正的总Architect，只有不同技术领域的Architect，例如
Joe Nunoll。因此Latté当时主要的舵手应该是产品经理以及Borland的Java资深研
究员了。而产品经理以及Java资深研究员再和所有的各领域Architect讨论Latté的
开发方向。因此在Latté的初期开发阶段，其模式就像罗马时期的合议制。
当时的Latte产品经理是Klaus Krull(K. K.)。这位仁兄长得又高又大，也是一位相
当热心的人。K. K.原本是Paradox和dbase小组的成员，负责Paradox/dBase的产品线。
在Latté小组成立之后K. K.立刻跳槽到Java产品线来。事实上许多Paradox/dBase
的工程师也都希望转换到Java产品来，因此当时在Borland内部掀起了很大的风浪，
也造成了许多人离职。这段故事在稍后的dbase相关章节中将详细说明。
K. K.加入了Latté小组之后，便积极地带领Latté小组往前冲。也许是因为K.K.在
Paradox和dBase时表现得并不好，因此想借着Latté证明自己的实力。不过K. K.人
也许很好，可是管理方面似乎仍然不甚灵光，Latté初期的进度仍然稍嫌缓慢。在IBM
VisualAge For Java于1997年推出之后，Borland高层下令K. K.绝对不可以再度延迟
进度，一定也要在1997年推出第一个Latté版本。好在当时Delphi 3大获全胜，而
K. K.又是当时Delphi产品经理Ben Riga的好哥们，因此由Delphi转入Latté的资源
也就源源不绝，让Latté的进度慢慢地赶上了。
至于当时Latté架构的主要人物并不是稍后众人皆知的Blake Stone，因为Blake Stone
是在Latté推出之后才加入Borland的。Latté初期的架构负责人应该是Steve
Shaughnessy。
Steve是Borland的资深研究人员，也是当初Borland最早投入Java技术研究领域的人
物之一。不过资深研究人员的缺点之一是喜欢不断地想象以及研究软件技术，但是对
于产品进度的掌握却不是他们的专长，也不是他们最关心的事情。这就是为什么Latté
一开始的开发进度非常缓慢的原因。直到最后K. K.加入并且面临了Borland高层和
市场巨大的压力之后才匆匆地集中所有的资源和时间想要追上进度。
当Latté小组开发JBuilder的第一个版本时，就想学习使用Delphi成功的Open Tools
API特性，为JBuilder定义完整而且极具弹性的开放式集成开发环境。不过由于当时
Delphi的Open Tools API仍然没有大量的采用接口程序设计的架构，考虑到Java拥有
定义良好的接口机制，无法完全采用Delphi的Open Tools API的设计，所以一开始
JBuilder集成开发环境的Add-ins功能开发得很缓慢。当时负责JBuilder集成开发环境
中Add-ins功能的工程师除了Carl Fravel之外，另外一位主要的工程师则是Greg Cole。
当Carl Fravel和Greg Cole了解到无法直接借用Delphi的Open Tools API来设计JBuilder
的Add-ins架构之后，就决定开始研发JBuilder本身的集成开发环境开放架构，并且
直接使用接口程序设计的机制来设计JBuilder的开放架构，这是和当时的Delphi不一
样的地方。而一直要到Danny Thorpe为Object Pascal程序语言加入了接口机制之后，
Delphi的Open Tools API才展开了第2波的大改版，使用接口机制来重新设计，也就
是后来Delphi著名的OTA架构(Open Tools Architecture)。
1997年11月，Latté终于完成并且推出市场。正式的产品名称被定为Open JBuilder，
这是为了强调Borland的Java开发工具就像Java本身一样是使用开放的架构。
在Open JBuilder 1.0推出之后，Java开发工具市场总算是竞争者齐聚一堂了，每一
家厂商终于一一地使出了真本领来竞逐Java开发工具的市场龙头。Open JBuilder 1.0
推出之后不久，几乎所有的信息媒体以及Java的专业杂志都进行了Java开发工具的评
比，想要比较所有Java开发工具的优/缺点，并且让Java的使用者了解当时市场的
老大Visual Café是否能够面对新兴势力的挑战，保住市场第一的地位。
当时大多数杂志评比的目标包括了Symantec的Visual Café、SUN的Java Workshop、
IBM的VisualAge For Java以及Borland的Open JBuilder 1.0。对于Symantec来说，
第一次的Java开发工具大会战是处于以逸待劳的情势，而且Visual Café也是4个Java
开发工具中唯一完全使用C/C++语言撰写的，因此面对当时Java编译器还不够好、JVM
品质也未若今日精良的情形下，Visual Café的执行速度占了非常明显的优势，在功
能方面当然也胜出其他竞争对手一截。
Symantec的Visual Café唯一的缺点就是在Java程序代码中加入了开发工具特有的程
序代码卷标，造成使用Visual Café撰写的Java程序代码不易使用在其他开发工具中
的后果。而且Visual Café在Render Java图形使用者接口时仍然拥有不十分精确的
问题。
当时对SUN的Java Workshop的评比是比较保守的。毕竟Java Workshop是Java正宗厂
商SUN推出的产品。虽然它不论在功能、执行效率方面都比不上竞争对手，而且小问
题一大堆，但是为了给SUN面子，媒体仍然没有给予太多的苛责。甚至有一些媒体还
称赞SUN有勇气开发一个完全使用Java语言撰写的Java开发工具，向全世界证明Java
是能够用来开发大型应用程序的。不过虽然媒体和杂志很给SUN面子，但Java Workshop
终究逃不过市场的考验，从此慢慢地退出了Java开发工具的市场。
在当时的评比中IBM的VisualAge For Java虽然是执行最为缓慢的Java开发工具，但
是在高阶功能方面的表现却是遥遥领先所有的竞争对手。VisualAge For Java的团队
开发功能、项目管理功能以及可视化设计家都大幅超越了其他的Java开发工具。不过
VisualAge For Java使用了专属的格式，因此其程序代码不容易使用在其他的工具中，
而且VisualAge For Java的项目在进入了Repository之后也发生过整个Repository
毁损的情形，因此当时VisualAge For Java在易用性方面的分数是比不上其他竞争对
手的。
对于Borland的Open JBuilder 1.0来说，这个最晚进入竞争市场的工具在第1次的集
体评比中最后的结果不如人意。原本Java的使用者以及专业媒体对于Borland的产品
有着高度的期待。因为以Borland一向精于开发工具，而且是最后才推出Java开发工
具的情形来推断，大多数人都认为Open JBuilder应该是准备最充分的，但是评比之
后的结果却不是如此。
首先Open JBuilder并不是纯粹使用Java撰写的开发工具，而是混合了Java和Delphi
的程序代码。不过最后的执行效率不但比不上Visual Café，也不比纯粹的Java
Workshop快上多少。此外Open JBuilder在功能方面比不上Visual Café，在可视化
设计家和高阶功能方面又不是VisualAge For Java的对手。在比上不足，比下只有
险胜的情形下Open JBuilder让当时许多人大失所望，当然也包括了我在内。因此在
大多数的评比中，Open JBuilder只得到中等的评价。当然这样的结果也反映在Open
JBuilder的市场表现之上。
Hotspot编译技术是个笑话吗？
1997年市场上逐渐出现愈来愈多的Java开发工具，愈来愈多的人开始尝试使用Java，
却也有愈来愈多的人抱怨Java的执行效率。当时的PC不像今日动不动就拥有1GHz的执
行效率以及512MB RAM的内存，以当时的机器来执行Java是很痛苦的事情。还记得当
时我还没有动力足够的机器来跑Open JBuilder，每一次执行Open JBuilder时就觉得
受不了。当时我还开玩笑地说，机器从执行Open JBuilder到进入Open JBuilder的集
成开发环境这段时间，早就够我使用Delphi写完一支程序了。造成Java执行效率缓慢
的主要原因当然是Java编译器以及JVM的品质不够精良了。
为了急于让信息界接受Java成为标准，SUN必须想办法克服这个问题。虽然克服Java
执行缓慢的现象是当时几乎所有支持Java软件厂商都想解决的事情，但Java的正宗厂
商SUN是责无旁贷的。也是因为Java执行效率的缓慢，当时也兴起了许多小的软件厂
商开发各种技术和编译器来改善或是解决Java的这个致命缺点。很快SUN找到了一家
小软件公司，这家公司以开发出"Adaptive Compiling"技术来加快JVM执行效率、以
及使用类似的技术来改善Java编译器的品质而闻名。SUN在了解到这些杰出的技术之
后便立刻决定购买这家公司，并且根据他们的技术来实现SUN的下一代Java编译器以
及JVM，这就是稍后SUN HotSpot技术的由来。
SUN投入新的Java编译技术之后不久，就有了初步的结果。根据这个新的技术编译出
来的Java ByteCode以及新的JVM的执行效率果然比以前进步了许多。这让SUN更有信
心，便立刻向世界公告了这个新的技术，并且命名为HotSpot。SUN宣称最后推出的Java
编译器和JVM将提供类似C++的执行效率。
在SUN公布了HotSpot技术之后，立刻引起了全世界Java使用者的狂热。人们认为一旦
SUN推出这个技术，Java将可望克服最后一个缺点，从而一统天下。与此同时，这也
引起了信息业界非常大的讨论和争议。特别是C/C++社群的人认为这根本是不可能的，
虽然"Adaptive Compiling"非常的有创意，但是要和已经存在数年的C++最佳化编译
器比起来，Java的ByteCode是不可能超越C++的。但是从SUN在其时公布的一些HotSpot
编译数字来看，"Adaptive Compiling"是非常有希望的，因为它改善的幅度实在是很
大。因此全球相关的人员都在屏息以待，准备看看SUN最后的成果。
在SUN第1次公布HotSpot的推出时程之后，果然让所有Java的使用者都引颈期盼，恨
不得SUN立刻推出这个技术，解除大众执行Java的痛苦。不过随着时间不断的接近，
SUN在最后关头又宣布因为研发不及因此要延迟HotSpot推出的时程。软件研发的工作
延后在软件界见怪不怪，当时也没有引起太多的争议，不但让SUN争取到了更多的时
间，也顺利地延后了推出的时程。
不过在SUN宣布的第2次推出时程到期时，SUN仍然无法推出HotSpot技术。很快的SUN
不得不再次宣告要延后HotSpot的时程。就在这样SUN不断跳票的戏码重复上演的情形
下，终于开始有人笑称HotSpot根本是一个骗局，SUN根本无法推出接近C++执行效率
的Java编译技术。
到了1999年左右，SUN自知再也无法推拖HotSpot推出的时程了。因此在当年8月，当
时HotSpot研发小组的领导人(一位博士，但是我已经忘记了他的名字)在BorCon上进
行Keynote Speech，正式向参加BorCon的人介绍HotSpot技术并且在现场展示了HotSpot
的研发成果。虽然一切看起来都很棒，但是当现场的听众直接询问到底HotSpot技术
是否能够超越C++的执行效率时，这位博士却没有正面回答，只解释说在一些应用中
HotSpot的确可以提供超越C++的执行效率。我听了之后心中大概就已经知道HotSpot
最终的结果了。
果然在HotSpot被迫推出市场之后，大家很快地了解到HotSpot和C++的执行效率相比
终究是还有一段距离，根本无法超越C++的表现。这造成了当初一些热切期待的C/C++
程序员回到C/C++语言的市场，并没有转换到Java市场。这也是为什么后来C/C++市
场虽然受到了Java的影响，但是仍然有大量的使用者和市场，并没有像当时许多人预
测的那样将会有大量的C/C++程序员进入Java市场，终究还是因为Java无法完全取代
C/C++语言来完成一些工作。而SUN呢？为了转移大家对于HotSpot的失望而开始把研
发重点转到Internet/Intranet、EJB组件模型和Java Mobile系统方面的研发。轰动
一时的HotSpot热潮也逐渐淡去。
现在SUN再也不怎么提起HotSpot编译器了，只是在每一个新版本的JDK中不断持续的
改善HotSpot的编译品质。想起当初SUN对HotSpot不可一世的吹嘘最是令人感叹。不
过HotSpot也不是一无是处，的确是精进了许多Java ByteCode的产生品质以及JVM的
执行效率，只是没有达到当初SUN夸口逼近或是超越C语言编译器品质的程度。在目前
状况下，HotSpot能够让Java的编译品质在伺服端的效率有着显著的提升，提供非常
不错的执行效率。但是在客户端，尤其是牵涉到图形使用者接口Render方面的应用时，
仍然是相当缓慢的。
就Borland本身使用Java的情形来说，Borland使用Java开发的VisiBroker For Java
的执行效率已经相当接近VisiBroker For C/C++的执行效率。因此如果再搭配使用品
质良好的JVM，那么根据Borland内部的测试数据显示，VisiBroker For Java甚至在
一些特定的应用中超越了VisiBroker For C/C++。
HotSpot在纷纷扰扰的这么多年之后到底是不是一些人讥笑的"笑话科技"呢？不同的
人到现在可能还是有不同的答案吧。
Borland的困境和选择
Open JBuilder虽然赶在1997年最末的一班车推出，但在市场上的反映并不如预期的
好。当然这是有许多原因的。首先是Open JBuilder太晚推出，初期的Java市场早已
被其他的Java开发工具，特别是Visual Café所占领；第二是Open JBuilder急着推
出市场，因此在和其他Java开发工具竞争时并没有什么特别突出的功能、明显的优势，
竞争力当然不够；第三是Open JBuilder于一开始就混合地使用了Delphi和Java程序
代码，因此Open JBuilder激活以及窗体设计家的反应都很缓慢，不像Visual Café
那种以纯C/C++程序代码撰写的Java开发工具反应迅速，从而给许多程序员造成了
不良的印象。IBM的VisualAge For Java虽然也很迟缓，但在高阶的团队开发方面却
支持得很好，而且通常会使用团队开发功能的使用者大都是属于企业或是大型用户，
因此使用的机器配备也很好，对于VisualAge For Java的缓慢反应也还能够接受。
Open JBuilder的表现不如预期，这让Borland很着急，因为其无法承受失去Java开发
工具市场的损失。因此在Borland的Java开发工具研发小组中开始有了一些讨论，那
就是如何让Open JBuilder能够后来居上，取得胜利的果实。针对Open JBuilder的失
败原因，Open JBuilder的开发人员开始反思是否也应该像Visual Café一样使用
Delphi重新打造Open JBuilder，让Open JBuilder的执行反应加快到使用者能够接受
的地步，因为在当时Borland实在已经无法再加快Java的执行速度。此外使用Delphi
开发Open JBuilder的窗体设计家也可以避免许多JDK的臭虫，不会因SUN开发或是改
善JDK的时程而影响到Open JBuilder的开发周期。
这个想法在Open JBuilder的内部引起了很大的争议。使用Delphi重写Open JBuilder
的集成开发环境可以拥有许多短期的效益而且产品马上会有明显的改善，可以拥有和
其他竞争对手一搏的本钱。不过反对的人则认为使用原生开发工具开发Java的工具是
走回头路。这些人认为Java有朝一日一定会开发到成熟的阶段，到时Open JBuilder
就会拥有最后的胜利，现在只是一时的挫折，没有必要灰心。
对于Borland来说，如何继续Open JBuilder是一个困难的抉择，因为当时Borland急
需收入的挹注，而Open JBuilder的研发费用惊人，光靠Delphi力撑实在是很辛苦。
不过如果再回到使用Delphi开发，那么可能又会失去未来的机会，这到底应该如何决
定呢？
Java天才的加入
这一切的答案在Open JBuilder的新产品架构领导人Blake Stone加入后才逐渐明朗。
Blake Stone原本是DSW Systems Corporation公司的技术主管，而DSW公司一向和Borland
互动良好，许多DSW公司的人都曾在Borland的Conference(BorCon)中负责技术讲座。
Blake Stone先生也在1997年的BorCon中负责了一个讲座。也许是Blake Stone和Borland
在这次的BorCon中合作愉快，Borland也很赏识Blake Stone的技术和才华，因此在BorCon
结束之后不久，Borland便和Blake Stone接触，看看Blake是否有意愿加入Borland的
Java研发小组。也许是天意吧，在Borland失去了Anders这个天才之后，老天又给了
Borland一个弥补软件天才的机会。
在Borland和Blake接触之后，Blake不但对于Java未来的潜力看好，而且因为Blake也
曾使用Delphi，对于Borland研发开发工具的能力相当有信心。更凑巧的是由于Open
JBuilder 1.0的不尽人意，因此此时刚好有一个Open JBuilder的Architect离职，
让Blake立刻有了适当的职位。没有多久Blake便答应进入Borland作为JBuilder的
Architect，目的是带领JBuilder成为最成功的Java开发工具。由于Blake惊人的天
分，因此很快就成为JBuilder的主要Architect以及技术的主领导者，JBuilder未来
开发的Java技术都由Blake负责研究和研发的工作。
Blake进入JBuilder开发小组之后，面临的第一个挑战便是如何改造Open JBuilder，
让它执行得更为顺利，并且能够在竞争群中脱颖而出。当然Blake必须做的第一个抉
择就是Open JBuilder到底该走向纯Java的开发工具或是改成原生的Windows Java开
发工具。Blake并没有迟疑多久，便决定把JBuilder带向纯Java的开发工具，使用Java
语言本身来打造整个JBuilder。Blake做了如此的决定是有许多原因的。首先是Blake
希望通过使用Java语言开发JBuilder本身来让Borland的工程师彻底掌握Java的技术，
也希望通过这样的开发来证明Java的实用性。就像Delphi本身就是使用Object Pascal
和Delphi研发、Borland通过Object Pascal证明了Delphi的实用性和可靠性一样，
Blake也希望使用JBuilder来证明Java语言的可用性。
第2点是因为打造纯Java开发工具可以让JBuilder通过Java跨平台的特性把JBuilder
推向其他所有支持Java的平台，让Borland能够穿透到以往无法进入的市场，这样可
以让JBuilder的潜在市场和客户比竞争对手的更宽广、更多。
第3点因素则是Blake希望通过这个行动让Borland掌握Java的核心技术，最好能够和
SUN有更密切的互动，让Borland能够在Java领域取得相关的领导地位。因为在和以往
Microsoft交手的过程中，Borland深深了解到如果无法在一个技术领域取得第1或是
第2的地位，那么终将成为微不足道的角色，被市场淘汰出局。
Blake在JBuilder研发方向制定的策略事后都被证明是正确的。后来JBuilder果然能
够支持Windows、Linux和Solaris平台，成为当时架构最大、最复杂的Java应用程序。
更重要的是SUN充分肯定了Borland在Java方面卓越的技术，进而采用Borland的Baja
技术制定Java Bean规格并且邀请Borland共同参与开发Java的JDK。Blake在JBuilder
早期设定了成功的趋势，奠定了JBuilder成功的基础。稍后JBuilder新的产品经理
Tony de la Lama又成功地制订了JBuilder的市场研发脚步和竞争策略，终于让JBuilder
在3.5版本之后一飞冲天，成为Java开发工具的翘首。
在Blake加入JBuilder开发团队并且决定了JBuilder走向之后，很快整个JBuilder的
开发方向便朝着他决定的方向快速前进。Blake也激活了JBuilder庞大的纯Java开发
工具的计划。1998年JBuilder研发小组在Blake的带领之下很快地交出了第1张成绩单，
那就是JBuilder 2的推出。
JBuilder 2的战略目标并不是成为完全的纯Java开发工具，而是为了快速跟上其他
Java开发工具的功能，并且提升Open JBuilder 1.0为人诟病的缓慢执行速度以及问
题多多的窗体设计家。
无疑JBuilder 2是非常成功的。我所谓的成功并不是指JBuilder在销售上的成功，
而是指Blake为JBuilder 2.0设定的目标。因为JBuilder 2.0推出之后很明显的比Open
JBuilder 1.0看起来成熟多了，而且在执行速度、包含的功能等方面都到达了合理
的地步，也让JBuilder正式进入Java开发工具第一方阵的竞争群。在Blake的努力下，
JBuilder 2.0的实现程序代码已经进步到使用25％Delphi程序代码和75％Java程序
代码，离纯Java开发工具已经愈来愈近了。Borland也开始从JBuilder 2.0的身上看
到了未来的曙光。也是上天注定，这个时候正是Delphi逼近于全盛的时期，需要
JBuilder接棒才能够让Borland持续地成长。
JBuilder 2.0的渐入佳境除了归功于Blake Stone之外，另外一个重要的原因便是此
时JBuilder的产品经理也换成了颇具眼光的Tony de la Lama。Tony也像K. K.一样是
从Visual dbase小组转来的，而且在K. K.离开了Borland之后接手成为JBuilder的舵
手。本来没有人看好Tony的，没有想到Tony却是一个雄才大略的人物。
Tony显然和Blake合作无间。在JBuilder一开始于产品和技术还相对处于劣势的时期，
Tony知道最重要的工作是先把产品做好，再求其他的策略。因此JBuilder在2/3版
时主要是由Blake Stone操刀、Tony为辅。稍后当JBuilder逐渐成为Java开发工具的
重要角色之后，便由Tony主导在市场、产品定位和竞争策略方面运筹帷幄。
Blake在研发JBuilder 2.0时，便设定了下面的目标，准备重新奠定Open JBuilder的
竞争实力。
■ 呈现精确的设计时期可视化效果。这方面胜出Visual Café许多，也是JBuilder
准备强攻Visual Café弱点的策略
■ 充分利用Java平台的特性
■ 以Java来思考开发工具的开发。这一点非常重要，也是日后JBuilder胜出其他Java
开发工具的重要因素
■ 开始为Java设计组件架构。当时这项研发计划命名为Baja，由Carl Quinn负责。
Baja也是日后JavaBean的前身
■ 打算以纯Java撰写JBuilder并且为移植到其他平台做准备
在JDK 1.1推出了JNI(Java Native Interface)之后，JBuilder开发小组的工作就更
为顺利了，因为他们可以通过JNI呼叫使用Delphi 2撰写的程序代码，呼叫Borland自
行开发的原生Virtual Machine，以快速地编译Java程序。此外由于JBuilder 2.0尚
无法成为完全的Java开发工具，因此Blake在Delphi方面也进行了更好的最佳化调整，
以加速JBuilder激活和执行的速度。当然在JBuilder的窗体设计家方面，Blake更是
决定投入大量的资源，以求解决Render和JDK臭虫的问题。由于Blake的决定，Borland
发现并且要求SUN解决了当时JDK和AWT/SWING初期的许多臭虫。其中有一些是SUN来不
及或是不愿意立刻修改的，为了不延误JBuilder的开发，Borland直接予以解决再提
交给SUN作为参考。
当时Blake为了让JBuilder中Delphi和Java的程序代码有更好的整合和表现，甚至研
发了许多低阶的技术来暂时强化JBuilder 2.0的执行效果，并加强Java和Object Pascal
语言之间互动和交换数据的机制。嗯，看来Blake在数年前便想到并且解决了许多现
今.NET的技术问题呢。
Blake Stone成功地带领JBuilder开发小组推出了JBuilder 2.0，这只是Blake为
JBuilder实施的第一阶段竞争步骤。当JBuilder 2.0获得了初步的成果之后，Blake
也正式激活了以纯Java打造JBuilder的计划。JBuilder 3.0是Blake瞄准的第一个版
本。在JBuilder 2.0之后的JBuilder研发工作中，Blake已经拥有愈来愈多的资源，
整个JBuilder开发小组的规模也开始和Borland的RAD部门不相上下了。
1999年8月，在Blake Stone和JBuilder团队全力催生之下，几乎是完全由Java开发的
JBuilder 3.0也在距离JBuilder 2.0推出一年之后正式推出了。如果说JBuilder 2.0
是为了让JBuilder赶上其他Java开发工具的版本，那么JBuilder 3.0的定位无疑就
是在Borland推出纯Java的JBuilder之前从落后于竞争对手到超越竞争对手的一个产
品。
虽然Borland进入Java开发工具市场非常晚，但是在经过了3个版本的努力之后，终于
在JBuilder 3毕其功于一役，进入了Java开发工具的领先群。此时当初第1名的Java
开发工具Visual Café正每况愈下，逐渐接近被JBuilder超越的命运了。
还记得在1999年的BorCon中，我曾经和Blake Stone有过短暂的交谈，明白了为什么
许多人都说Blake Stone是一位天才型的软件人物。当时我去听其中一场讨论(如何调
整InterBase执行效率的Seminar)，没有想到坐下来之后才发现Blake Stone就坐在旁
边。之后，我一直在暗中观察他。只见他在Seminar开始之后就拿出了Notebook专心
写程序。我当时便想，Blake参加这个Seminar大概只是消磨时间，主要是写写JBuilder
的程序，并不是真的想听这个Seminar的内容。选择InterBase这个Seminar纯粹是因
为人比较少，不会受到太多的打扰吧。知道了Blake的举动之后，我也一直想移动身
体朝向Blake，希望看看天才写的程序代码是什么样子？但是出乎我意料之外的是，
当Seminar结束之后，主讲人开始接受询问问题，Blake却不断地举手发问。
这令我大吃一惊，因为整场专心写程序的Blake看起来能够一心多用，不但脑袋可以
想东西，手指可以打键盘，心思还能够倾听Seminar的内容，真令我佩服。Seminar结
束之后，我和Blake交谈了数句寒暄的话，恭喜他在JBuilder方面的成就。Blake转身
离开时，从身后看简直就像一位小姐。因为Blake身材纤细，又留了一头长发，不知
情的人从身后看一定会认为这是一位美丽的小姐呢。
当JBuilder 3在市场上接受开发者的考验时，虽然JBuilder的市场占有率排名还不是
第一，但是已经和主要竞争对手非常接近。从成长分析中也可以看到，JBuilder是以
快速的速度成长，而Visual Café却不断地呈现下滑趋势。至于VisualAge For Java，
也几乎停滞不前。JBuilder对于所有Java开发工具竞争对手的威胁与日俱增，Symantec
和IBM再也不敢轻视JBuilder的实力。事实上此时JBuilder的王者之姿也隐然若现了。
不过Blake并没有稍做停顿，给其他的Java竞争对手以喘息之机，而是很快蓄积力量，
准备在产品面进行最后的一击。
2000年3月14日，对于JBuilder来说是最重要的一个里程碑，因为这一天是Borland正
式推出JBuilder 3.5的日子，也是Borland的JBuilder小组在经过了数年的努力之后
终于拥有了一个纯Java打造的Java开发工具的日子。
JBuilder 3.5不单是Borland第一个完全使用Java撰写的开发工具，也算是业界中第
一个纯Java开发工具。虽然数年前的Java Workshop也是使用Java开发的，但是Java
Workshop提供的功能远不如JBuilder 3.5，此外JBuilder 3.5的复杂度和难度也比
Java Workshop高太多了。
JBuilder 3.5推出之后，立刻风靡了Java开发工具市场。大量的Java开发人员迫不及
待地升级到JBuilder 3.5，因为许多Java程序员都想使用一个纯正的Java开发工具。
此时JBuilder在市场上的占有率排名已经达到第一位，而且正朝市场占有率50％的目
标迈进。依我的眼光来看，JBuilder到了3.5版之后，在技术和产品方面的竞争已经
告一段落。因为在这个阶段，JBuilder本质方面的使命已经完成了。JBuilder 3.5之
后的竞争要点是在市场和产品策略上。如何让JBuilder超过50％的占有率是JBuilder 4
的任务。此时JBuilder的领导也由技术Architect转到产品经理Tony de la Lama身上。
也是由于Tony de la Lama继Blake Stone之后表现得相当出色，很快Tony de la Lama
就升为Borland Java事业部门的Director，继Blake Stone之后再为JBuilder开辟一个
光荣的战场。
JBuilder从混合代码的1.0演变到3.5的纯Java开发工具，每一个版本核心都有精进。
最后我列出JBuilder的演进史，让读者也能够了解JBuilder的变化。
Delphi程序代码 Java程序代码
JBuilder 1.0 40 60
JBuilder 2.0 25 75
JBuilder 3.0 10 90
JBuilder 3.5 0 100
JBuilder 3.5推出之后，Java开发工具不可避免地开始进入了第3个大混战时期。
Blake Stone的荣耀
1999年7月，Borland首次在公司内部设立首席科学家的荣誉职位，该职位颁给Borland
最优秀和重要的软件人员。除了"首席科学家"光荣称号外，当然也有丰厚的物质奖赏。
Blake Stone当时就和Chuck Jazdzewski以及Andreas Vogel同时获得了Borland"首
席科学家"大奖。Blake对于JBuilder的贡献也算是实至名归。在进入Borland短短的
数年时间内，就以最年轻的软件人员身份获得此项大奖，这也证明了他惊人的实力。
虽然Blake不像Anders那么锋芒毕露，也不像Danny一样著作丰富，但他本身在软件上
的修行已属顶尖。下面列出他荣耀的历史：
■ Borland最年轻的首席科学家
■ 成功带领JBuilder成为世界第一的Java开发工具
■ 成功克服Linux上当初没有标准JDK，让JBuilder能够在Linux上执行
■ 世界Java专业论坛的主讲人
■ 主导Borland Java开发工具和技术的关键人物
现在Blake愈来愈受到Borland的重视。除了原本的JBuilder产品之外，后来Borland
并购OptimizeIt、进一步强化JBuilder整体竞争力也是Blake的主张。Blake已经慢慢
从JBuilder产品线转而成为负责Borland大部分Java技术的关键人物。日前Borland又
宣布Blake也将负责公司内新的生命周期管理软件的研发。看来Borland下一代Java产
品也将由Blake贡献心力。继续加油吧，Blake！
第3阶段--大混战
"人人有希望，个个没把握"应该是对这个Java竞争时期最好的叙述了。在JBuilder逐
渐成为Java开发工具的领导者、同时传统霸主Visual Café也逐渐没落之时，对于每
一个Java开发工具厂商而言，这似乎都是最后一搏的机会了。时间已经进入了公元2000
年。虽然Java开发工具的市场独立于其他语言的工具市场，而且这个市场的规模也在
不断地成长，但明显没有像当初Gartner Group等机构预测的那样有足够大的规模。
更麻烦的是Java开发工具的价格显然在许多免费工具的竞争力之下，这些厂商的获利
也不如预期。但是在每一家Java开发工具厂商都已经投入大量的资源情况之下，除了
市场第1、2名以外，其他的开发工具厂商都势必无法拥有足够的获利。除非Java开发
工具厂商有其他的利益或是因素而能够忍受不佳的获利甚至赔钱，否则迟早许多厂商
都必须退出这个市场。
或许所有进入这个市场的厂商都没有料到，Java开发工具会有如此激烈的竞争。当初
这些厂商都认为Java是一个极具潜力而且没有"Microsoft"竞争的市场，因此一定比
较好生存。但却没有想到因为没有"Microsoft"，反而所有其他厂商几乎都进入了这
个市场，甚至一些名不经传的小公司都以为可以分一杯羹。想在这个市场成名立万就
必须经过激烈的割喉竞争。
同样在2000年11月，Borland向所有Java开发工具竞争对手挥出了致胜的一击，那就
是JBuilder 4的推出。JBuilder 4对于Borland来说是一个重要的Java里程碑，是Borland
在JBuilder 3.5之后乘胜追击之作。在JBuilder 3.5以纯Java开发工具的号召获得了
Java程序员的青睐之后，Borland毫不放松到手的胜利，立刻以JBuilder 4一举冲破
了Java开发工具50％的市场占有率，正式成为Java开发工具的王者。
JBuilder 4不但在销售上大获全胜，也让Borland在经过数年努力之后终于在Java开
发工具重享当初C/C++王者的荣耀。此外JBuilder 4产品本身也得到了专业Java媒体
和杂志的高度评价，一致认为Borland的JBuilder是最好的Java开发工具。Borland可
以说是里外兼得。
在Borland以JBuilder 4横扫千军之际，唯一还能够与之抗衡的就只有IBM的VisualAge
For Java了。而昔日的Java开发工具霸主Visual Café已经沦落到第3名的地位，且
其市场占有率和影响力还在快速的下降之中。Symantec当初辛辛苦苦花了3年时间打
造的Java王朝就在二三年之间很快幻化成泡沫，这也造成了Symantec完全退出开发工
具市场、全心开发防毒和企业解决方案应用软件的结局。
因此在2000年3月，Symantec把Visual Café卖给了新成立的WebGain公司。Visual
Café从此慢慢地从通用Java开发工具转变为专属的Java开发工具，其Java开发工具
市场的地位也变得无足轻重了。
另外一个重要的现象是在Borland的JBuilder一轮猛攻并且成为Java开发工具的领导
者之后，JBuilder也慢慢地被Java开发人员视为正统的Java开发工具。因此当时许多
在Windows平台使用Java的开发者都逐渐转至使用JBuilder。而Microsoft的VJ++由于
不支持最新的SUN Java标准，又混合使用了许多Microsoft特定的功能，最后还和SUN
发生了法律上的争执，也逐渐被视为非正统的Java开发工具，使用者逐渐流失。因此
在2000年左右，当所有的Java开发工具都呈现成长趋势的时候，Microsoft的VJ++却
出现了大幅的衰退，是唯一呈现负成长的"类Java开发工具"。此后不久，Microsoft
慢慢地退出Java市场，开始准备另起炉灶，再以2年后的.NET进行反击。
JBuilder 4算是Borland毕其功于一役的版本，因为JBuilder 4不但在产品功能方面
大幅领先于其他的竞争对手，在市场占有率方面也终于达到了Borland一直想要达到
的目标。到了这个时期，Blake主导JBuilder的工作也算是圆满达成目标，在接下来
JBuilder的开发过程中就开始由Tony de la Lama操盘，Blake则转向主导JBuilder和
Java先进技术的研发工作，并且稍后和RAD的Chuck一起，获得了Borland首席科学家
的荣耀。
第4阶段--谁跟的速度最快
在Java开发工具进入大混战阶段之后，看起来虽然热闹、生气蓬勃，事实上却是惊险
不已。各种Java开发工具多得令人眼花缭乱，每种Java工具也都有人使用。从要钱的
到不要钱的，从完整集成开发环境到只提供最简单的Java编辑器，各种产品都有厂商
提供，的确是一个百家争鸣的时代。
Borland为了在这个阶段取得领先地位，以避免被淘汰出局，因此激活了Borland前所
未有的开发模式，那就是在JBuilder的开发团队中同时有二组并行且彼此竞争合作的
JBuilder小组。当其中一个小组开发目前的JBuilder版本时，另外一个小组便开始着
手研究和开发下一个版本的JBuilder。开发目前版本JBuilder的小组完成之后，便接
着再使用另外一个小组已经开发出的成果持续开发下下版本的JBuilder。这种作战方
式从JBuilder 3.5之后便开始显现成果。JBuilder不但及时地紧紧跟随着每一个JDK
的版本，成为市场上最符合JDK要求的Java开发工具，也渐渐形成每半年推出一个新
版本的速度，让JBuilder远远超越竞争对手，成为唯一的领先者。
JBuilder成功的竞争策略，让JBuilder的最大竞争对手IBM的Visual Age For Java和
WebGain愈显吃力，更不用说其他的Java小厂商了。在这个阶段Java开发工具开始了
残酷的最后生存战。Java开发工具市场注定将像当初PC平台上的C/C++开发工具市场
一样，只有少数的厂商才能存活下来。事实也证明从2000年之后不断有Java厂商被迫
退出市场，甚至是面临关闭的命运。造成这种现象以及Borland能够脱颖而出是因为
下面的原因：
■ Java开发工具市场虽然有成长，但相对于其他种类的软件来说，毕竟是比较小的
市场，因此开发工具厂商必须达到经济规模才能够获利，才能生存下去
■ Java开发工具的市场并没有像Gartner Group在公元2000年预测的那样会有巨大的
成长。事实上当时就是因为许多研究机构看好Java市场的成长潜力，因此才吸引许多
软件厂商不断地进入。但是过多的软件厂商和不够大的市场注定会淘汰许多的竞争者
■ Borland在残酷的开发工具竞争市场生存了将近10几年之久，因此当然知道竞争的
激烈，也深黯竞争之道。
■ 最重要的一点，是Java开发工具市场对于Borland来说是生存之战。在Borland的
RAD开发工具到达了饱和之后，Borland必须靠新开辟的Java开发工具市场才能继续茁
壮发展
在经历这一波的残酷淘汰赛后，每家厂商的心态昭然若揭。对于一些小厂商而言，无
声无息的消失是很自然的事情，即使是大厂商也不见得好到那里。例如IBM在Visual
Age For Java经营了4个版本之后，又采用了像当初对待Visual Age For C/C++一样
的手法。我早在数年前便已经预言IBM终会放弃VisualAge For Java，如今果然被我
言中。我之所以能预知结果，并不是能够洞察先机，而是从IBM处理PC软件的一贯模
式推知的。PC的软件经营金额对于IBM来说是九牛一毛，根本无足轻重，只是IBM竞争
的手段之一，特别是在经营结果不甚理想之后自然是第一个开刀的对象。不过最惨的
应该是WebGain了，曾几何时是市场第一的Visual Café也将面临再次被卖掉的命运。
这个比快的淘汰赛中，JBuilder和它的孪生兄弟、Oracle的Jdeveloper一起遥遥领先，
而IBM则已经准备放弃Visual Age For Java，而和BEA WebLogic搭配的WebGain也逐
渐长路将尽了。
第5阶段--谁能走的最久
当Borland以JBuilder 4横扫千军之后，剩下的主要竞争对手就只剩下IBM的VisualAge
For Java了。不过VisualAge For Java和一般的Java开发工具定位不太一样，而且
大多数的VisualAge For Java使用者都是IBM的客户。此外VisualAge For Java最强
的功能是在团队开发方面，而JBuilder在这方面一直不算是做得很好。
为了和VisualAge For Java进行最后的决战，JBuilder小组决定在JBuilder中大幅强
化团队开发方面的功能，期望击溃VisualAge For Java最后的防线。2001年6月，
Borland推出了JBuilder 5，除了增加JBuilder对于愈来愈风行的各种EJB应用程序服
务器的支持之外，还加入了可视化EJB设计家以及支持CVS、Rational ClearCase和
Visual SourceSafe等团队开发和原始码管理的功能，开始投注更多的资源在VisualAge
For Java强项的功能上。
JBuilder 5推出之后，果然改变了许多Java专业媒体和杂志对于JBuilder在团队和大
型企业开发能力的评价。此外由于JBuilder是所有Java开发工具中支持EJB应用程序
服务器最齐全和最好的工具，因此从JBuilder 5开始，一些应用程序服务器厂商便逐
渐地建议客户搭配JBuilder来开发Web和EJB应用系统。这个现象也开始微妙地影响了
JBuilder的定位并且开始产生许多奇妙的效果。
首先，为了在市场上取得最大的占有率，Borland一直坚持JBuilder必须支持所有市
场上重要的EJB应用程序服务器，特别是对于市场的领导EJB应用程序服务器，例如BEA
的WebLogic和IBM的WebSphere，应该有最好的支持，以吸引这些EJB应用程序服务器
的使用者来使用JBuilder。但是由于Borland自己也有EJB应用程序服务器，而Borland
的EJB应用程序服务器部门希望JBuilder能够先支持Borland自己的EJB应用程序服务
器，再考虑其他的EJB应用程序服务器。因此当时Borland的JBuilder小组和Borland
Enterprise Server小组之间有了一些小争吵。不过由于JBuilder是属于Borland Java
RAD部门的产品，因此JBuilder小组仍然决定成为市场上支持WebLogic和WebSphere
最好的Java开发工具。只是JBuilder小组也把Borland Enterprise Server当成是一
线应用程序服务器，决定给予的支持就像给予WebLogic和WebSphere的支持一样。
第二个现象是一些EJB应用程序服务器开始和JBuilder Bundle(捆绑)在一起销售，或
是建议客户使用JBuilder。因为在Java开发工具重新洗牌之后，JBuilder已经是市场
的领导者，其他的应用程序服务器厂商在可选择的Java开发工具愈来愈少或是原开发
工具厂商退出Java市场之后，也不敢违抗市场的主导力量，当然纷纷搭乘JBuilder的
便车了。
在JBuilder 5成功的在团队开发方面给予了VisualAge For Java极大的压力后，
Borland于同年的11月再次进逼，发表了JBuilder 6，成为压垮VisualAge For Java
的最后一根稻草。
JBuilder 6不但继续强化团队开发能力，而且已经成为支持EJB的最好工具。另外
JBuilder 6又开始整合UML和Extreme Programming方面的功能，比起VisualAge For
Java已经先进了许多。而VisualAge For Java在开发脚步迟缓的情形下，早已跟不上
JBuilder的健步如飞。更麻烦的是从JBuilder 5之后，JBuilder成功地打入了企业市
场，侵蚀了原本IBM的客户并且动摇了Visual Age For Java最后的大本营。VisualAge
For Java在功能和市场方面节节败退，已经到了穷途末路的地步了。
2001年12月左右，IBM终于宣布把Visual Age For Java开放给Eclipse计划，正式结束
了VisualAge For Java五年来在Java开发工具市场的竞争。IBM在久战不下，Visual
Age For Java又无法替IBM带来充分的利润之后，正好借Open Source的名义把Visual
Age For Java拱手奉送。还可以利用VisualAge For Java最后的价值为IBM打打广告、
做做形象。不过回头看看IBM在开发工具市场的记录，却是惨不忍睹，对于客户而言也
没有什么保障。
当JBuilder 6成功地摧毁了VisualAge For Java的防线之后，连带在市场上排名第三
的Visual Café也无法再支撑下去，因为Visual Café的拥有公司WebGain在失去了
BEA的支持之后，已经没有能力再在Java开发工具市场竞争下去了。
第6阶段--胜利者的出线
2002年Borland仍然以半年一个版本的速度又如期推出了JBuilder 7。Borland这种推
出新产品的速度简直令人无法置信。JBuilder的竞争对手们也早己一个一个的累倒在
地上，纷纷出局了。JBuilder很明显的已经成为了最后的胜利者。
同年6月，WebGain在找不到后继的资金和投资者之后，决定把Visual Café卖掉并且
结束WebGain的运营。不久之后TogetherSoft以相当便宜的价格购买了Visual Café，
准备正式进军Java开发工具市场。而TogetherSoft加入Java开发工具战火也代表着
新一波Java开发工具的竞争，这在稍后会继续说明。
Borland的JBuilder在第7版虽然成为了王者，但是这并不代表已经打遍天下无敌手。
因为在Visual Café被Case和UML模型工具开发厂商购买之后，新一波的Java开发工
具之争已经隐约成形了。此外当初由Delbert Yocam License(授权)给Oracle的
JDeveloper也表现得愈来愈好，开始给JBuilder造成不小的威胁。
第7阶段--Java开发工具和Case Tool结合的趋势
Java已经明显的成为大型企业开发应用系统的首选，许多名列Fortune 1000中的大企
业也都开始采用Java的应用方案。在Java成功地穿透了企业市场之后，随着Java开发
工具的流行，Java使用者也开始要求开发工具必须结合OOA/OOD的功能，让Java使用
者能够以面向对象的方式开发大型的系统。于是从JBuilder 6开始，Borland便在
JBuilder中逐渐加入OO和UML的功能，准备在JBuilder已经于Java开发工具金字塔
中/底层成功的攻城掠地之后，再把JBuilder推向金字塔顶端。不过JBuilder的举动
自然也引起了另外一群软件厂商的紧张，进而隐隐地激活了另一波的竞争，这些软
件厂商就是开发Case以及UML工具的软件公司。
话说从2000年许多软件公司经历了高成长之后，从2001年起，这些公司为了继续维护
成长以期获利，必须在既有的产品之外想办法再扩充产品线。JBuilder就是一个很好
的例子。JBuilder只有不断地扩展它的功能面以及使用者群，才能够持续地在Java开
发工具市场成长。对于像提供面向对象和UML工具的厂商来说(例如Rational和
TogetherSoft)，当金字塔顶端的使用者在大部分已经购买了这类工具之后，如何再
让其他的使用者也购买这些工具便成为这类厂商首要的问题。就像在大部分的多金客
户和老板们已经成为Benz的客户之后，如何让更多的人愿意购买Benz汽车，便是Benz
需要想办法的一样。Benz的策略是推出C-Class级的汽车，以年轻新颖化的设计为号
召，企图打入年轻的使用者群，因为以前这一族群的使用者是Benz无法打入的。
Rational和TogetherSoft为了扩展原有的面向对象和UML相关的产品线，开始想要跨
入开发工具的市场。由于在所有的开发者群组中，Java开发者是最接受面向对象和UML
技术的群组，因此Rational和TogetherSoft自然以Java开发工具作为优先的市场。
Rational采用的策略是自行开发"类开发工具"，那就是Rational XDE。虽然Rational
很小心地处理开发工具市场，但是仍然遭遇了开发工具厂商的抵抗。例如Microsoft
原本在开发工具中内附Rational的简易UML工具，但是在Microsoft逐渐为Visio加入
更好的UML支持之后，就放弃了采用Rational的产品。当然对于Borland来说，
Rational进入开发工具市场也有着非常微妙的影响，因为Borland和Rational也有合作
的关系。现在Rational为了新增产品线而进入开发工具市场，令Borland和Rational同
时处于既合作又竞争的地位。
对于TogetherSoft而言，是否进入开发工具市场更是难以决定的事情，因为TogetherSoft
在UML工具方面和Rational竞争得非常激烈，分居此市场的第1和第2位，在Rational
逐渐跨入开发工具、而且Rational和TogetherSoft的客户也开始对于结合开发工具和
UML工具有了强烈的需求之后，TogetherSoft也必须苦拟竞争对策，否则TogetherSoft
和Rational的差距不但会被拉开，既有的客户群也会遭受Java开发工具的侵蚀。特别
是在Borland于JBuilder 6开始加入低阶的UML功能(例如Refactoring)之后，很明显
JBuilder在某些场合便已经开始和TogetherSoft的产品竞争了。
正由于Java开发工具的厂商往上仰攻企业用户群，而Case和UML厂商又想向下开拓新
的潜在客户，因此开发工具厂商和这些上端的Modeling软件厂商从以往互不相干、到
合作打天下，再到目前阶段的合作竞争状态，看来这两类软件厂商彼此竞争开战或是
合并的日子已经不远了。
在2002年8月，TogetherSoft终于从WebGain购买了Visual Café，正式准备进军开发
工具市场。也许TogetherSoft的第一步是整合Visual Café到TogetherSoft的产品线
中，先提供TogetherSoft客户的需求。接下来势必强化Visual Café的功能，加入UML
的能力，让TogetherSoft正式和Java开发工具竞争。TogetherSoft不但通过Visual
Café快速地进入Java开发工具市场，也让Visual Café又神奇的再次延长了生命--
Visual Café真可谓是Java开发工具界的"九命怪猫"了。
在TogetherSoft正式通过Visual Café进入了Java开发工具市场之后，Borland、
Microsoft、Rational和TogetherSoft在开发工具市场的竞争也再次隐然而动。这个
熟悉的影像就和数年前C/C++市场的竞争一样，只是换了2个主角而已，看来虽然开发
工具市场获利并不丰富，但却是一个具有制高点作用的重要市场，因此即使许多厂商
都损兵折将，但是仍然不断的有新厂商投入。前仆后继，蔚为壮观。
不管Java开发工具未来的竞争形势如何，从这些厂商的动作来看，整合面向对象和UML
的高阶功能似乎是不可避免的趋势。成功的开发工具必须适当地整合Extreme
Programming、UML和传统的RAD集成开发环境，以向使用者提供最大的生产力。加入
UML的功能是传统开发工具厂商要面对的挑战，提供RAD和Extreme Programming的能
力则考验了UML厂商是否能够提供具备亲和力的开发工具。Java开发工具目前的两种
开发和竞争方向，的确是和数年前C/C++开发工具的竞争有所不同。究竟谁能胜出，
终究要通过使用者、市场和时间来考验了。
第8阶段--和.NET的巅峰之战
从1995年到2002年，应该算是Java的成长和全盛期。这段时间内许多的Java厂商、开
发工具和应用程序服务器不断的在竞争和厮杀，如同神鬼战士一般进行最后的生存战。
为什么？我想这是因为必须剩下最强的竞争对手，才能与2003年起Microsoft.NET逐
渐产生影响力时.NET下的开发工具竞争吧。虽然Bill Gates日前在媒体上公开承认.NET
的流行速度没有Microsoft设想的快，但是从以往Microsoft的竞争模式来看，
Microsoft一向擅长后来居上，不可小看其决心和实力。更何况Java毕竟已经开发了
将近七、八年，而.NET不过是1年多左右，后面竞争的日子仍然很长。
在我日常的工作中，通过接触许多不同型态的客户，也可以察觉到传统Windows开发
工具、Java和.NET势力的消长。Java从2000年起开始有了明显的成长，特别是大型客
户、使用多种不同平台的客户群更是快速地倾向使用Java。由于这类客户在后端大都
是使用Mainframe或是强力的UNIX机器，在采用Java之后，也自然需要引入Java的组
件架构以及Web Solution，故JSP/Servlet便大行其道，EJB也开始逐渐风行并且快速
成长，而造就了许多EJB著名厂商的壮大以及另外一个竞争激烈的EJB市场。由于大型
企业偏向Java的解决方案，因此造成了许多大型企业、卫星软件公司也选择使用Java。
此外Java也在学校和研究界获得重视，许多大学和学术机构提供了大量的Java人才，
逐渐地形成了极为强大的Java凝聚使用群。这群使用者应该算是Java最有力的支持了。
对于中小型信息客户来说，事情就没有这么顺利了。由于这类客户的资源并不像大型
客户那样丰富，因此许多中小型客户一开始在Java风潮下也都尝试着使用JBuilder来
开发，但是Java的高门槛立刻让这些客户退出了Java的世界，即使留下来的也仅限于
使用Java开发Web方面的应用。
由于Java在客户端的图形使用者接口方面失败连连，从Applet、AWT到Swing，Java似
乎一直无法为客户端提供堪用的解决方案，以致不断败退，造成了目前在客户端使用
Java应用程序的应用系统仍然非常稀少，客户端仍然是Windows原生开发工具的天下。
问题是虽然Java目前在中间及后端占了极大的优势，不过应用系统仍然需要客户使用
客户端来呈现应用系统的数据以及图形使用者接口，因此Java如果无法在客户端取得
一定的应用地位，那可能也将逐渐失去中间层的优势。在Microsoft的.NET从2003年
开始逐渐影响市场之后，Java在客户端以及Web的应用都将会面对新的挑战。尤其是当
Microsoft以.NET虚拟执行环境提供更具安全和延展性的Web应用(指ASP.NET，新的IIS
服务器以及ASP.NET开始支持Apache Web Server)之后，简易好用的ASP.NET技术和开
发工具将进一步挑战Java在Web方面的应用。目前.NET在中间的组件技术方面仍然落后
Java阵营一大截，是Microsoft需要补强的地方，否则.NET仍然不适合做为大型企业解
决方案的应用(不过Borland却可提供非常良好的解决方案，那就是把CORBA移植到.NET
上，稍后的章节会说明这些有趣的开发)。但如果Java持续地在客户端、Web应用以及
移动消费端节节败退，那Java的应用也将局限在中后端的系统应用，情形就不怎么乐
观了(就像UNIX一样)。
根据许多知名信息机构的调查，在未来的数年当中，Java和.NET的竞争将趋于白热化，
而且最可能出现的是由这两大技术平分天下的状态。因此Java目前的开发以及声势
似乎都遥遥领先，但是对擅长打持久战和逆转战的Microsoft仍然不可大意。更何况
Java并不是完美的金刚之身，仍然有许多不甚令人满意的地方，还是需要加把劲才能
够维持好的局面。
此外应用系统型态的开发趋势也深深地影响了开发工具的走向。开发工具必须满足客
户的需要，当应用系统型态改变时，开发工具厂商必须提供适当的解决方案，让使用
者能够开发应用程序。根据Gartner Group的调查，Java和.NET的应用将开始快速爬
升，开始侵蚀原本的Microsoft DNA应用市场以及传统的COBOL、4GL和专属系统。
数年前Java以Web应用开始风行，再进而成为企业解决方案。现在.NET也遵循相同的
路径进入市场。只是.NET除了以Web进攻之外，还搭配了Web Service和一流的开发工
具。Microsoft有样学样的招式不但使用在开发产品方面，连和SUN技术平台的全面对
战模式使用的策略也如出一辙，只是包装的更好而已。
技术和开发工具的竞争最终取决于使用者的需求以及提供的功能、服务、架构和完成
度。不过由于现在软件技术的高度竞争，因此往往一方有了特定的技术，另一方很快
的也会推出相对的技术来因应。这种竞争类似于Java开发工具在第3和第4阶段的竞争，
只是希望SUN能够撑得久一点。我相信一旦有一方撑不下去，一定又会站出来以冠冕
堂皇的词汇说明他们只是为客户提供最好的解决方案，而不是为了和另一方竞争。如
果读者看到这一天，那就代表着即将分出胜负，出来说明的一方又将使用新的名词和
技术寻找出路。无论如何，从下图Gartner Group公布的评估数据来看，虽然.NET现
在只是第1个版本，但是在许多方面已经不输给开发了数年之久的Java。看来Microsoft
具备在短短的1、2年之内达到Java开发了数年之久的功能和成就的能力，这也许就是
寡占市场的好处。Java要和.NET竞争，SUN还是需要加快油门，否则很快就会被Microsoft
追上，竞争可是不等人的。
对于Java开发工具来说，似乎目前加入争战的厂商还彼此杀得不亦乐乎、难分难解。
往好的方面想，这是为了找出最终的强者，再与Microsoft的.NET以及.NET下的开发
工具竞争；往不好的方面想，也代表这些厂商还没有察觉到.NET的威胁。不过从我的
观察以及.NET推出之后业界的反应来看，.NET的确已经开始吸引一些客户从Java转向
NET，特别是中小型客户以及需要使用Web应用的客户，当然一些大中型的客户也有
开始动摇的情形了。
对于Java开发工具的厂商来说，除了要和其他Java开发工具厂商竞争之外，或许也要
开始面对.NET开发工具的挑战。这些厂商必须加快把Java开发工具塑造成更容易使用、
生产力更高的工具，否则面对精于打造开发工具的Microsoft，小的Java开发工具厂
商生存的时间就不长了。对于Borland而言，这却是一个机会。现在JBuilder已经执
业界牛耳，Borland又决定开发.NET下的开发工具，如此一来Borland由于在两方都提
供最好的解决方案，因此有机会进一步扩大Borland的客户群。
但无论如何，当.NET到达了一定的规模之后，.NET开发工具和Java开发工具的竞争是
不可避免的。即使像Borland这样同时提供Java、原生Windows开发工具和.NET开发工
具的软件厂商，也或多或少的都面临自己人的竞争。叶孤城的"天外飞仙"对西门吹雪
的"一剑西来"，你赌谁赢？嗯，也许对决的结果会创造出新的混合体--像周星驰的"
少林足球"，也不一定啊。嗯，有可能，有可能。
Java需要面对和解决的问题
Java在开发了七、八年之后，也逐渐进入成熟期。一旦产品进入这个时期，很多的压
力就会出现，再加上.NET逐渐产生的影响力，Java开发工具以及Java的应用程序服务
器产品线也开始面临了许多的变化，这些变化将影响Java未来的开发以及和.NET对抗
的趋势。依我的观察，目前许多Java厂商都逐渐陷入困境和挑战之中。因为.NET和市
场的压力愈来愈大，厂商高获利的时代结束，开始进入了"微利"的阶段，这会让许多
Java厂商开始退出Java市场。Java已经不再像数年前拥有横扫市场的绝对优势，
Microsoft的.NET也逐渐在原本Java主导的市场形成气候。我认为目前Java正面对着
下面最重要的挑战和威胁：
■ 开发工具价格往下降的威胁
任何产品都是一样，当产品开始进入成熟期之后，产品价格一定会开始下降，这是正
常的现象。不过对于Java这种高投资的技术和开发工具来说，产品价格下降代表Java
厂商会经营得更吃力，如果无利可图，那许多Java厂商将会退出这个市场。正由于竞
争压力太大，许多Java厂商都希望尽快达到一定经济规模，以备Java开发工具价格快
速下降后能够以量大来弥补，这也是这一波割喉竞争的原因。对于Java开发工具是这
样，对于EJB应用程序服务器也是这样。Java开发工具价格持续地探底将会注定只有
排名前二或是前三的厂商才能够继续存活下去，其他的小厂商只能以非常便宜或是免
费的角色存在于这个市场。但是如果这种现象持续下去的话，那Java开发工具的进步
幅度和品质都有可能开始往下滑。
■ EJB过度竞争的压力
EJB是Java的组件架构。由于会使用EJB解决方案的企业都属于中、大型公司，而这些
公司通常都属于财力雄厚的企业，因此愿意并且有能力花大笔的经费在建制EJB应用
系统之上。这个市场获利丰厚而且具有主导应用系统架构的力量，吸引了世界一流大
厂和许多著名的厂商开发和提供EJB应用程序服务器，当然也不乏许多小厂商想通过
这个新的组件市场而功成名就，因此为数众多的软件厂商便在这个拥挤的市场中拼得
你死我活了。举凡IBM、SUN、HP等世界级大厂都加入竞逐的行列，这些厂商原本就是
在UNIX工作站和大型Mainframe的死敌，自然不愿意让其他的竞争对手有机会独大于
重要的EJB市场。经过了数年的争斗之后，IBM和BEA已经很明显地居于领导的地位，
Borland和SUN等则处于第二领先群中。IBM通过庞大的公司资源以及硬件的交互支持
成为数一数二的EJB厂商，BEA则是由于最早进入EJB市场并且通过高知名度的Tuxedo
掩护成功地打入企业市场。至于SUN，虽然是Java技术的领导厂商，但是推出的软件
产品一向令人不敢恭维。继当初的Java Workshop失败之后，EJB应用程序服务器iPlanet
说实话一点也不好用，功能和执行效率也比不上竞争对手。要不是靠SUN的金字招牌，
iPlanet绝对无法在EJB应用程序服务器市场占有一席之地。
不过EJB应用程序服务器市场虽然逐渐分出胜负，但是在高度竞争以及许多EJB应用程
序服务器厂商以免费作为诉求的同时，厂商不但必须投入极大的资源研发最新、最符
合JDK和EJB规范的产品，还必须浴血奋战。这从观察EJB应用程序服务器的授权价格
不断往下降就能看得出来，由于EJB授权价格快速地下滑，因此许多EJB厂商面临了困
境。许多只占有极小市场的厂商开始无利可图，进而把价格压得更低甚至采用免费方
式和大厂竞争，这造成了即便是市场领导者也无法避免这个风暴的局面。由于IBM主
要标是硬件销售，再搭配WebSphere，因此对于EJB应用程序服务器价格下滑仍然不感
吃力。但是对于BEA和SUN来说，却是压力巨大，因为BEA的收入几乎就是靠EJB应用程
序服务器，而SUN则在投入了大量的资源研发iPlanet之后，不但在市场占有率上无法
做大，又面临价格快速下滑，当然就吃不消了。
因此，在2002年8月，SUN的EJB部门副总裁公开宣示，各EJB应用程序服务器厂商如果
再持续进行不计血本和免费大放送的劣质竞争，那么EJB应用程序服务器将提早出现
大幅衰退的现象。当然EJB应用程序服务器价格下降是有利于使用者，但是这也将让
所有的EJB应用程序服务器进行毁灭战，EJB大厂必须通过坑杀小厂以取得更多的市场
占有率来弥补。最后可能剩下不多的选择以及品质开始下降，对于企业级的使用者，
这是福是祸呢？
■ 行动和消费端的竞争
SUN一直想让Java主宰所有的软件市场，从大型企业的应用系统一直到消费端的行动
解决方案，因此除了在Java语言以及企业的J2EE架构之外，也非常积极地力推JINI和
J2ME等技术。如果SUN能够让Java同时在中/后端企业应用系统以及移动设备市场大获
全胜，那么上下交攻，Microsoft的领域势必被严重地压缩。不过SUN的如意算盘似乎
是出了状况，Java OS和JINI一直是雷声大雨点小，SUN数年的心血似乎也一直无法让
这两个技术成气候。反观Microsoft，虽然在桌面型应用领域独占鳌头，但是在消费
端的应用一开始是处于劣势的。Win CE开始并不见声势，又被Palm OS压着打。但不
屈不挠似乎是Microsoft反败为胜的惯例，Win CE在2、，3年的努力之后已经到了和
Palm OS平起平坐的地位，Pocket PC又逐渐受市场欢迎，Microsoft也介入传媒和移
动电话的市场，并且以X-BOX进入家庭游戏市场，一再显示出Microsoft在消费端的电
子行动设备方面已经悄悄地建立起了一片江山。在.NET以相同的技术和Framework允
许开发者同时开发企业以及消费端和行动解决方案之后，Microsoft结合消费端和桌
面型的优势将对SUN形成强大的竞争压力。如果Java无法在消费端和电子行动市场成
长得如同其在企业端的绝对优势，那Java在消费端的力量将遭受严厉的挑战。
■ 语言的对抗
Java通过简洁的语言风格和虚拟机器提供的安全执行环境获得了开发者的广大回响之
后，其他语言当然也不会坐以待毙，新的语言势必出现，以求对抗Java。当初Java能
够成功地采纳C/C++语言的好处并且开发出新的面向对象语言，其他的新语言也可以
学习Java成功的地方，融合更多现代的需求以求超越Java。C#就是一个很好的例子，
C#在许多方面都学习了Java，却又加入了Object Pascal的优美特性，成功地塑造了
新语言，分散了Java群组的使用者。Gartner Group的调查就显示了C#将同时侵蚀C/
C++和Java的使用群，更不用说许多原有的语言了。此外VB和Object Pascal也会或将
要推陈出新，巩固原有的使用者群，并且在新的.NET虚拟环境中吸引从Java转战而来
的使用者。很显然，Java现在的处境已经慢慢地失去了独尊的地位。
当然，Java解决方案尚有许多其他的挑战和问题，但如何面对和解决上面重要的问题，
是所有Java厂商以及SUN要尽快解决的。虽然现在没有人知道未来Java的趋势，不过
唯一可以确定的就是Microsoft正在一步一步地逼近之中。
JBuilder未来的开发
JBuilder从2.0开始成功地执行了一个有效的竞争模式：先从产品功能面竞争，稍后
再配合市场策略一举攻上王座。虽然JBuilder后半段以每半年一个版本的速度杀得对
手措手不及，不过快速升级的方式也造成了一些后遗症，那就是由于改版速度太快，
造成许多JBuilder客户以跳版本的方式来升级。例如JBuilder 4的客户更新到
JBuilder 6，JBuilder 5的客户则升级到JBuilder 7。
当然JBuilder快速升级方式和Java开发工具的竞争有关，但是很大一部分原因也是因
为Java的JDK经常更新，迫使Java开发工具必须跟上Java JDK的脚步，否则就有被淘
汰出局的危险。因此为了兼顾Java快速开发和使用者的权益，JBuilder在快速开发之
后的下一个阶段也许应该考虑推出1年套餐版，让使用者在付费之后的1年内都可以免
费升级吧。
Borland的JBuilder还在快速的开发之中，精彩的故事也一定会持续发生，也许1、2
年之后，再让我们回首，又将看到许多可歌可泣的故事，这就留待日后的书籍来叙述
吧。当读者看到本书时，JBuilder 8可能已经在市面上销售，而JBuilder 9可能也在
开发的阶段，这就是Java充满活力、进步快速的特质。喜欢Java吗？那么就接受这个
高度动感的世界吧！
^v^v^v^v^v^v^v^v^v
第六章 失去的王冠--Borland数据库工具的战役
在Borland的产品线中，有两个产品是较少受到瞩目的，那就是Borland从Ashton-Tate
并购来的dBase系列以及昙花一现的IntraBuilder。对于Borland来说，dBase和
IntraBuilder是非常可惜的牺牲品。dBase发展的黄金时机被Philippe Kahn白白浪费，
IntraBuilder带来的无限潜力硬生生地被Delbert Yocam糟蹋掉。Borland最有机会的两
个关键时刻分别被两任CEO蹉跎，不知到底是时也？命也？运也？
dBase和IntraBuilder这两个产品，到底是如何在Borland中发展的呢？为什么最后dBase
和IntraBuilder都会进入死胡同？让我们一起来探索其中的秘密。
IntraBuilder的诞生
谁说"洞悉先机"一定是好事？当初哥白尼在几个世纪之前大胆地提出了天体运行论，
同势力庞大的基督教对抗，因而被基督教视为邪说，一直到3个世纪之后才被罗马教
皇承认。而哥白尼的一生都在承受着巨大的压力，Borland的IntraBuilder几乎也面
临了同样的命运。
1995年，当浏览器的应用逐渐成为主宰力量之后，各种Web的应用也开始快速地发展
起来。一开始Web应用是以面向文件为主，许多Web应用都使用纯文本编辑器来开发HTML
网页。但是人们很快发现，这种方式非常不经济，因为Web应用虽然有很大一部分属
于美工的需求，但是当Web进入人们的生活后，许多Web应用便开始需要结合数据处理
而转向商业的应用。因此，很快Web的解决方案便开始从静态网页的应用进入到使用
程序来解决的阶段。但是，当时正值浏览器大战的阶段，Netscape正和Microsoft的
Internet Explorer拼斗得你死我活，而Java也开始兴起。此时浏览器并没有标准，
连带着对HTML、JavaScript的支持也混乱无比。因此，虽然许多程序员都感觉需要一
个Web开发工具帮助他们开发逐渐炙手可热的Web应用程序，信息业界也开始有强烈的
需求，但是混乱的Web标准却让许多程序员不知所措。
不过，Borland的Visual dBase小组却从中看到了极大的契机，因为在为Visual dBase
未来的版本加入支持Web的功能时，Visual dBase小组突然发现，既然Web的功能是许
多程序员想要的，那么，为什么不直接提供一个可视化的Web开发工具，让需要开发
Web应用程序的程序员能够拥有最好的工具，而不需要痛苦地使用纯文本编辑器来开
发Web应用程序呢？
时值1995年，这的确是一个令人相当震撼的想法，因为它体现了未来需求的趋势。当
Visual dBase小组提出这个想法之后，立刻在部门内获得了极大的回响。几经商议，
Visual dBase小组决定先开发一个可视化的Web开发工具来测试市场，而且他们决定
就使用Visual dBase来开发这个新的产品。这实在是个大胆又令人惊讶的决定，因为
当时不但没有类似的产品，而且决定使用Visual dBase而非C/C++来开发新产品，更
是不可思议，开发工具真的可以使用Visual dBase来开发吗？
当Visual dBase小组决定开发这个新的开发工具时，却面临了一些技术上的抉择，那
就是使用什么语言作为这个新开发工具的核心？另外，该产品既然是一个Web开发工
具，当然需要一个Web Server作为后端的驱动引擎。但是，当时的市场上只有Netscape
和O'Reilly等少数厂商拥有Web Server引擎。因此，Borland必须决定使用什么Web
Server。不过，这些问题很快就有了答案。
由于Java快速地兴起，Applet也成为学习Java的入门知识，因此，JavaScript很快就
被众人视为开发Web应用程序的标准语言。于是Visual dBase小组决定使用JavaScript
作为这个开发工具的核心语言，并且强化当时的JavaScript语言，以支持这个新的开
发工具。另外，由于当时的Web Server大都不便宜，因此，Visual dBase小组决定自
行开发一个Web Server作为这个开发工具的内建Web Server。最后，Visual dBase小
组定义这个开发工具必须拥有下面的功能：
■ 可视化开发环境，允许程序员使用组件和拖曳的功能来设计Web应用程序
■ 使用JavaScript作为核心语言
■ 提供内建的Web Server
■ 结合BDE/IDAPI来连接各种数据库
这个开发工具便是IntraBuilder--后来震撼一时的数据库Web开发工具先驱。
在IntraBuilder开始开发之后，Visual dBase小组很快发现，虽然他们可以使用Visual
dBase完成大部分的工作，但是，终究有一些功能是Visual dBase力所不逮的地方，
因此，在IntraBuilder开发的后期，为了让它能够支持当时Microsoft刚推出的、同
Applet相抗衡的ActiveX以及动态执行Applet，Visual dBase小组还是使用了部分的
C程序代码来完成这些功能。
IntraBuilder的震撼
1996年9月，经过1年多的开发，IntraBuilder终于推出在世人的面前。IntraBuilder
推出之后，全世界的专业媒体几乎都对IntraBuilder好评有加，而且都不能相信Borland
能够如此快速且先知地推出数据库的Web开发工具。
全世界的好评如潮，因此，在IntraBuilder准备正式出货之前，Borland也是信心满
满。我记得，当时在拿到IntraBuilder的Beta版后，虽然我对于Web的开发仍然没有
太多的经验，但是很快就了解了这个产品的潜力，因为IntraBuilder和当时其他的Web
开发工具以及编辑器比较起来，简直是领先了数个世代之久，而且还能够用来作为学
习JavaScript的工具和开发连接数据库的Web应用程序。这些功能在市面上几乎没有
任何的竞争对手可以比拟。即便以今日的标准来看，IntraBuilder提供的Web可视化
设计能力仍属一流。因此，当时我就觉得这会是一个大卖的产品。
IntraBuilder面对的困难
即便Borland非常有信心，专业媒体也一片看好，但是没有想到的是，在IntraBuilder
推出之后，只带来了第一波销售热潮，随后的销售却很快冷却下来，造成了IntraBuilder
叫好不叫座的情形。这实在是一件很奇怪的事情，因为IntraBuilder产品本身没有太
大的问题，产品的方向也是正确的。但是为什么IntraBuilder在市场上就是无法拥有
亮丽的表现呢？这个问题是Borland急于寻找答案的。记得当时在台湾发表IntraBuilder
时，似乎也是回响热烈，但实际出席的人却不多。台湾Borland的产品经理还在会场
询问我，为什么出席的反应这么不热烈，产品本身不是不错吗？
在IntraBuilder首次遭遇挫折之后，Borland很快便找出了其中的重要问题所在。有
些属于产品本身的小瑕疵，有些则是当时整个环境的问题。总结当时IntraBuilder
1.0失败的原因有：
■ IntraBuilder太过于先进，许多程序员不知如何使用
■ IntraBuilder不支持中文
■ 浏览器对于JavaScript语言的支持程度混乱
■ IntraBuilder在GUI方面的Render尚有瑕疵
由于当时Web的程序应用还属于萌芽期，Internet/Intranet程序应用仍然处于第一波
面向文件的阶段，大多数的Web应用是使用HTML和一般编辑器来制作的。这个时期距
离第二波程序员开始大量使用各种不同的Web语言来开发Web应用程序仍然有1、2年的
时间差。
可惜的是，IntraBuilder就是太早的察觉了这个趋势，因此当IntraBuilder推出之时，
仍然是领先第二波Web应用的发展。从下面的图形，我们也可以看到IntraBuilder
推出的时机的确是先于数年后其他Web开发工具的脚步。
正是由于IntraBuilder推出的时机太早，因此只能吸引站在前端的开发人员，大多数
的开发人员对于这样革命性的产品，浑然不知其重要性，造成IntraBuilder一开始只
能销售给Borland的少数客户以及其他领域顶尖者的结果。不过我认为这是一件好事，
因为IntraBuilder先期的销售数量虽然没有达到Borland的预望，不过IntraBuilder
一开始便攻入了最重要的客户群，占据了金字塔顶端客户的mind-share。只要
IntraBuilder能够再接再厉，等到1、2年后，当大多数的开发人员了解了Web开发工具
的重要性以及实用性之后，IntraBuilder将可快速收割成果。此外IntraBuilder的理
念与技术领先于其他竞争对手数年之久，即使其他Web开发工具推出，IntraBuilder也
能够以逸待劳，痛击竞争对手。
在Borland分析了IntraBuilder遭遇挫折的因素后，很快便展开了相应的行动，因为
Visual dBase小组对于IntraBuilder仍然非常有信心。在支持DBCS方面，由于
IntraBuilder 1.0不支持DBCS，因此造成了在许多亚洲国家和地区，包括中国台湾地
区、日本和韩国以及中东无法销售的问题。这个影响当然是很大的，因为光是一个日
本市场，几乎就可以销售数千万套。
另外一个扰人的问题，就是由IntraBuilder开发出来的Web应用程序在不同的浏览器
中会发生网页内容和位置与在IntraBuilder中设计时不一致的情形。这个问题形成的
原因很复杂，大都和当时不同的浏览器在render网页内容时的差异有关。当然，当时
尚未有一致的标准，使得不同的浏览器支持的HTML版本和JavaScript版本不同。不过，
虽然这些问题不全是Borland的错误，但是，就如同当时一个IntraBuilder使用者在
Forum中留下的一句话"It may not be Borland's error，but it definitely is a
Borland's problem(不是Borland的错误，却是Borland的问题)"。
为了解决IntraBuilder面对的问题，Visual dBase小组很快便开始进行了IntraBuilder
第二个版本的开发工作，目的就是为了解决IntraBuilder客户所抱怨的问题，并且强
化IntraBuilder在扩展性和执行效率方面的功能，以期让更多的客户愿意使用
IntraBuilder。1997年6月，Visual dBase小组手脚很快地推出了IntraBuilder 1.5，
进行第二次的出击。
IntraBuilder 1.5几乎是一个成熟的Web开发工具，因为IntraBuilder 1.5可以支持
DBCS，并且大幅提高了IntraBuilder应用程序的执行效率。此外，Visual dBase小组
也特别使用C改写了IntraBuilder在render网页的功能，让IntraBuilder能够更精确
地呈现Web网页的内容，并且大幅提升了在不同浏览器中的兼容性。
经过了这么多的改善之后，IntraBuilder在全世界的销售果然有了起色，慢慢地向
Borland为IntraBuilder设定的目标接近。Visual dBase小组当然也是很高兴，因为
这证明了他们的眼光是正确的。因此，Visual dBase小组在IntraBuilder站稳了脚步
之后，便开始进行IntraBuilder 2.0大改版的工作，希望通过2.0版本让IntraBuilder
成为最成功的Web开发工具。
再接再厉，IntraBuilder 2.0的开发
1997年，Borland已经准备好了新版的IntraBuilder，并且在当年的Borland Conference
中公开宣示了IntraBuilder 2.0，也为未来的IntraBuilder 3.0提供了发展蓝图。新
版本的IntraBuilder一切看起来是非常的顺利，而且Visual dBase/IntraBuilder小
组也信心满满，准备为IntraBuilder再下一城。
当时的Borland正和最具影响力的Netscape以及Microsoft共同制定JavaScript的标准，
并且准备捉交到ECMA。其时IntraBuilder Architect Randy Solton正忙于和Netscape
以及Microsoft的人员定义JavaScript的最终标准，希望两大浏览器Communicator和
Explorer能够在未来支持这个新的标准，以便让IntraBuilder的应用程序能够正确无
误地执行在这两个浏览器中。不过，由于Netscape和Microsoft正处于最激烈的战火
中，彼此各怀鬼胎、谁也不服谁，因此标准制定的流程进行得非常缓慢、不顺利，这
也间接造成了开发IntraBuilder的难度。
在Borland Conference 1997中，当时IntraBuilder的Director Michael Gardner展
示了IntraBuilder 2.0的新功能。
在IntraBuilder 2.0中，Borland提供了一个内建的HTML可视化编辑器，以提供更为
精确的网页编写功能(类似今日Macromedia提供的工具)。IntraBuilder 2.0的ActiveX
具有同时在客户端和伺服端执行的能力。这个功能非常Cool，因为在当时，ActiveX
大都只能执行在客户端，而IntraBuilder 2.0却能够让ActiveX同时执行在客户端和
伺服端，这可就稀奇了。另外，IntraBuilder 2.0对于JavaBean的支持也将和ActiveX
一样完全，这代表两种不同的组件技术在IntraBuilder中将会是相同的First-Class
组件。这可是Macromedia在数年之后才能在UltraDev中实现的技术。
另外一个IntraBuilder 2.0最重要的功能就是提供了跨平台的能力。Borland准备同
时开发Windows和UNIX平台的IntraBuilder，计划支持的UNIX平台包含了Solaris、HP
-UX、AIX和IRIX。这在当时可算是非常大的手笔，因为当时市场上不但没有类似的产
品，更遑论是提供跨平台的Web开发工具。因此，我认为当时如果Borland能坚持下去，
就将拥有绝佳的市场契机。
在1997年的Borland Conference中，除了Michael Gardner的讲座之外，IntraBuilder
的Architect Randy Solton也在Borland Conference主讲了两个讲座，深入地讨论了
IntraBuilder 2。0的新功能和实现技术。
此外，当时IntraBuilder的产品经理Klaus Krull(K.K.)也在现场同台演出，并且声
明IntraBuilder 2.0的Beta版将提供给有兴趣的开发者测试。从所有的迹象来看，
IntraBuilder 2.0已经是蓄势待发了。
另外，当时IntraBuilder的QA工作，是由华人出身的Ken Chan所领军。其实从Borland
C/C++ 3.0开始，华人在Borland的R&D以及QA部门中一直占有一定的比例，对于Borland
产品开发有着不小的贡献。
不过，事情的发展很快就出乎所有人的意料，在Borland Conference 1997年举行过
后不久，Borland突然放弃了IntraBuilder。这个消息传来，对于当时急切等待
IntraBuilder 2。0的我来说，实在是晴天霹雳。为什么Borland会突然放弃
IntraBuilder，这是当时我一直想要了解的问题。我曾经询问过台湾Borland的好友，
但是他们也不知道实际的原因。后来我曾经听到几种说法：其一是Delbert Yocam对于
IntraBuilder没有兴趣，因此不愿意再投入资源开发下去；另外的传言则是Borland
决定全力开发JBuilder，因此把IntraBuilder的资源移到JBuilder去；还有的说法
是IntraBuilder开发团队和Delbert处不来，因此集体离开Borland。不过事情的实际
答案仍然是一个谜，即使到了今日，我再次为Borland工作时，仍然无法获得确定的
答案，实在令人遗憾。
我认为IntraBuilder是最为可惜的产品之一，因为早在1996年，当其他软件公司尚未
察觉到Web需要一个良好的、能够和数据库整合在一起的开发工具时，Borland居然就
已掌握到软件时脉，而且推出了实际的产品，可说是一片大好，也是Borland少有能
够走在别人前面的好时机。如果当时Borland好好地持续开发IntraBuilder，我相信
IntraBuilder一定会成为比今日Macromedia的UltraDev还好的产品，而且也将是我认
为属于"消费型软件"的产品，Borland将可在数年之后的公元2000年大展鸿图。只可
惜Delbert Yocam似乎是脑筋坏了，不然就是没有眼光，居然在IntraBuilder 2.0几
乎已经完成之前决定放弃。不但让Borland失去了在Web开发工具方面占有一席之地的
机会，也失去了数年后让全世界疯狂的Internet/Intranet和DotCOM的黄金发展阶段，
真是令我扼腕。甚至在Delphi 3/4时，我强烈建议在Delphi中开发类似的IntraBuilder
功能的心愿也无法达成。我想，这应该是Borland在并购Ashton-Tate之后，另外的一
个重大失策。
令人遗憾的结局
在Delbert Yocam决定放弃IntraBuilder之后，这个举动也几乎成为压垮骆驼的最后
一根稻草，因为这对Visual dBase小组实在是一个非常大的打击。Visual dBase小组
已经看到Visual dBase的市场不断地下滑和萎缩，因此急需一个新的产品以增加收入
并开拓未来的产品线。不过，在Delbert决定了IntraBuilder的命运之后，也代表了
宣布Visual dBase小组终将结束的未来。正是由于Delbert的决定，引发了1、2年后
Visual dBase小组所有人都急于跳下Visual dBase这个曾经一时的旗舰，转而纷纷希
望加入Java这艘新的战舰，从而引发了稍后Borland内部的极大争议。
直到现在，我仍然非常喜欢和怀念IntraBuilder。因为我在CDC服务时，便曾和一位
同事共同把IntraBuilder引入CDC作为开发Web解决方案的开发工具。由于CDC使用Delphi
作为主力开发工具，而IntraBuilder的开发模式又和Delphi很类似，因此对于
IntraBuilder的接受程度很高。IntraBuilder 1.5解决了中文问题和执行效率问题，
当时我开发的Pilot系统可以执行得非常顺利，因此我决定在Web方面的工具使用
IntraBuilder。没有想到，后来Borland居然放弃IntraBuilder，顿时之间所有的心
血都化为流水。身为Borland产品使用者的我，不能够接受Borland这种处理产品的
方式，更何况Borland在当时也没有提供任何可取代IntraBuilder的产品。Borland
处理IntraBuilder的方式引起了当时许多IntraBuilder使用者的反弹，也让Borland
几乎无法再涉足Web开发工具的市场。
命运坎坷的dBase
回顾dBase产品的一生，实在令人不知说什么好。dBase曾经主导了PC数据库技术的发
展主流，在早期也几乎霸占了PC数据库市场。十几年前，当人们发现一台PC在执行了
dBase之后，居然能够处理许多日常数据，立刻便为dBase不可思议的能力而着迷，进
而创造了dBase不可一世的时代。
1980年8月，George Tare和Hal Lashlee两位先生创建了Software Plus软件公司。稍
后，他们和Microsoft一样，从一个小软件公司购买了Vulcan Data Base软件，并且
根据Vulcan Data Base开发出dBase产品的前身。很快，George Tare和Hal Lashlee
合作的软件便获得了许多使用者的好评，他们的软件逐渐在市场上受欢迎。不久之后，
George Tate和Hal Lashlee便成立了Ashton Tate公司，展开了dBase神话的时代。
在Ashton-Tate推出dBase II之后，正值PC开始快速成长的时期。由于当时的dBase
II在PC上提供了合理的数据处理能力，因此很快便有了大量的使用者，dBase II的影
响力也开始渗入商业使用者领域，而Ashton-Tate这个招牌也逐渐成为广为人知的公
司。
1984年是Ashton-Tate一生最为重要的一年，因为在这年的6月，Ashton-Tate推出了
dBase III。dBase III在数据处理能力、运算速度方面都比dBase II大幅提升，正好
符合当时PC愈来愈大量数据应用的需求。在Ashton-Tate推出dBase III之后，立刻在
全球大卖，随后推出的dBase III Plus更是奠定了Ashton Tare在PC数据库方面至尊
的地位。dBase III和dBase III Plus的空前成功，使得Ashton-Tate营收大增，并且
成为当时全球第3大的软件公司。和Microsoft、Lotus分别以DOS、Lotus 1-2-3和dBase
各在操作系统、Spreadsheet以及数据库市场鼎足而立。
当Ashton-Tate在数据库市场不可一世之时，Oracle还是一个名不见经传的小公司。
怎知10年风水轮流转，现在的Oracle已经成为数据库的霸主。为什么Ashton Tate这
个曾经执PC数据库牛耳的公司后来会一蹶不振呢？这都要从Ashton-Tate的dBase IV
说起。
急转直下的dBase IV
当Ashton-Tate的dBase III/Plus成功之后，Ashton-Tate的野心就更大了，急于和
Microsoft/Lotus逐鹿天下。Ashton-Tate决定投入大量的资源开发下一代的dBase软
件，把处理数据的能力再次提高，并且提供更为复杂的功能。虽然Ashton-Tate的想
法很好，要把PC数据库的竞争再次升高，提供更为高阶的应用，但却忽略了当时PC硬
件设备是否能够跟上Ashton-Tate设定的标准的问题。
在Ashton-Tate开发dBase IV到中期之后，却发现当时PC的设备无法顺利执行dBase
IV，此时Ashton-Tate才发现事态严重。其实，在Ashton-Tate开发dBase IV之前，并
没有评估硬件需求或是没有控制dBase IV的开发。无论如何，对于Ashton-Tate来说，
dBase几乎是唯一的软件，也是成功的支柱。结果，对于最重要的产品居然管理成这
个样子，从这个迹象便可知当时的Ashton-Tate可能被dBase III/Plus的胜利冲昏了
头，也开始夜郎自大起来。
Ashton-Tate发觉了dBase IV的问题之后，立刻和一些软/硬件厂商合作，为当时只能
使用640K内存的PC加入新的内存设备，以便执行需要海量存储器的dBase IV。虽然后
来的确弄出了一个解决方案，但却不为市场大众接受。dBase IV在Ashton-Tate无法
解决内存需求问题之下仍然执意推出，结果市场一片负面评价。不但一般的PC内存不
够无法顺利执行，再加上dBase IV的臭虫极多，立刻被市场所唾弃。原来的dBase使
用者仍然继续使用dBase III/Plus，不愿意升级到dBase IV，这让Ashton-Tate面临
血本无归的窘况。再加上dBase又得面对FoxBase和Borland Paradox愈来愈强劲的竞
争，Ashton-Tate无法推出让dBase使用者满意的下一代产品，只能眼看着市场不断流
失。
1990年初，Ashton-Tate内部起了内讧，导致dBase的主要Architect以及许多工程师
离开Ashton-Tate，而Ashton-Tate在数年之间仍然无法解决dBase IV的问题也让人不
可思议。此时，Ashton-Tate在Paradox和FoxBase的鲸吞蚕食之下，几乎快变成一个
空壳了。公司营收不断下滑，dBase市场占有率不断下降，人员更是快速流失。到了
1991年，Ashton-Tate几乎已经撑不下去了。
在Ashton-Tate快速走下坡之际，却是Borland即将到达巅峰之时。1990年，Philippe
Kahn从Borland本身的Paradox成长情形知道了dBase的状况，已经逐渐看出Ashton-
Tate的颓势。于是Philippe Kahn知道，Borland称霸PC数据库市场的时机即将到来，
而且Borland必须比Microsoft先出手才能够赢得这个不容错过的好机会。
1991年，在Ashton-Tate已经摇摇欲坠之际，Philippe Kahn终于决定出手。因为
Philippe Kahn知道，绝不能让Microsoft先叫牌。更绝的是，Philippe Kahn一出手
就是雷霆一击，条件好得让Ashton-Tate根本无法拒绝。1991年7月，当Philippe
Kahn以440 Million叫牌之后，Ashton-Tate很快就全面投降，决定从此嫁入Borland。
Ashton-Tate的被并购和走入历史
1991年，不可一世的Philippe Kahn以极大的霸气和本钱并购了当时已经快速走下坡
的Ashton-Tate。Philippe Kahn购买Ashton-Tate的真正目的是为了与Bill Gates一
争长短，以图成为PC软件界的霸主。另外一个目的则是为了彻底消灭dBase，因为
Philippe Kahn认为Borland自己的Paradox比当时问题多多的dBase IV好得太多了，
一旦dBase退出市场，那么Paradox即可席卷PC数据库市场，让Borland同时成为PC开
发工具以及PC数据库市场中的老大，进而同主掌PC操作系统的Microsoft和控制PC计
算软件的Lotus分庭抗礼。
在Borland以不可思议的高价购买了Ashton-Tate之后，立刻引来了华尔街的批评，因
为华尔街的分析师都认为Philippe Kahn出的价格太高，Ashton-Tate在当时并不值440
Million多美金。不过对于Philippe Kahn来说，用4亿多美金来与Microsoft/Lotus一
较长短的大企图相比，实在不算什么，因为Borland有的是钱。
在1991年Borland并购Ashton-Tate时，Borland的市值其实比Ashton-Tate小。当时的
Ashton-Tate是排名第5的软件公司，而Borland只排名到第9。但是Ashton-Tate已经
在走下坡，手头拮据。反观Borland则是蒸蒸日上，现金多多。Borland并购Ashton-
Tate一事，媒体都以"小鱼吃大鱼''为标题进行报道。当时Ashton-Tate的营业额大概
是250多个Million美金，而Borland的营业额则大约是230多个Million。因此，在Borland
加上Ashton-Tate之后，立刻成为一个年营业额将近500 Million的软件公司，排名跃
为当时全球第3大的软件公司，仅次于Microsoft和Lotus。读者可以想想，现在的Borland
年营业额才200多Million，但是10年前却已经拥有500 Million，可见当时Borland的
盛世和规模之大。在Borland完成了Ashton-Tate的并购之后，Philippe Kahn每日都
得意洋洋，因为在Philippe Kahn看来，成为全世界第一大、击败Microsoft的日子已
经不远了。
Ashton-Tate被Borland并购之后，其光辉灿烂将近10年的时光也随之消逝。Ashton-
Tate原本很有机会成为今日的Oracle，继续占据PC数据库市场龙头的地位，没有想到
Ashton-Tate却把好好的一盘棋下到了死局，硬生生地把自己的命脉产品玩完。虽然
Ashton-Tate是一个很好的负面教材，但人类似乎永远学不会历史，数年后的Informix
也走上了和Ashton-Tate极为类似的道路。
不甘之作，dBase For Windows 5.0
在Philippe Kahn得意不久之后，Microsoft也并购了FoxBase这家公司，并且快速地
推出了FoxPro这套可以在Windows下执行的、与dBase兼容的软件。由于Microsoft掌
握了原本DOS下dBase程序员急需一个Windows下的dBase开发工具的心态，因此当FoxPro
For Windows推出之后，立刻吸引了许多原先dBase III/dBase III Plus的使用者。
虽然Borland在Microsoft推出FoxPro For Windows之后开始流失使用者，但是，由于
其时Paradox For DOS的销售仍然良好，因此，Philippe Kahn并没有放在心上，仍然
认为最终Paradox For Windows可以击败FoxPro For Windows。在这里，Philippe Kahn
显然犯了轻敌的错误。
在Microsoft连续推出两个版本的FoxPro For Windows之后，Borland终于察觉原先dBase
的使用者正处于快速地流失之中。虽然Borland已经推出了Paradox For Windows，而
且销售也在预期之中，但是很显然，Paradox For Windows并不能阻止dBase客户的流
失。Philippe Kahn此时才开始着急。此外，Borland也面临还在使用dBase For DOS
使用者强大的压力，他们要求Borland推出dBase For Windows。
其实，dBase For Windows产品本身还是不错的，不过由于已经太晚加入Windows平台
数据库战场，而且是在匆促上阵的情形下，本身的臭虫当然不少，再加上得面对轻装
上阵的FoxPro For Windows，dBase For Windows几乎没有什么胜算。随后的结果果
然如同许多人预期的一样，dBase For Windows在推出之后不但无法憾动FoxPro For
Windows的江山，反而引来原本期待的dBase使用者的绝望。dBase的使用者在苦等Windows
版的dBase数年之后，Borland仍然无法提供一个高品质的产品。顿时之间，大量不满
的dBase使用者都转向了Microsoft的FoxPro For Windows，也造成了dBase For Windows
不可挽回的败势。
在dBase For Windows失利之后，许多人都开始把矛头对向Philippe Kahn，认为是
Philippe Kahn的自大和轻敌搞死了dBase For Windows这条原本有机会的产品线。如
果Philippe Kahn能够在并购Ashton-Tate之后好好地开发dBase For Windows，并且
在Microsoft的FoxPro For Windows之前推出，那么Borland将可让大部分dBase For
DOS使用者转入Windows的市场。唉，如果时光能够倒转，如果Borland能够早一步推出
dBase For Windows，再进而开发出后来的关系数据库(Relational Database)产品，
那么，Borland现在可能仍然是前3大的软件公司。
最后的帝王--Visual dBase 7
很显然，Microsoft以极小的代价购买了FoxBase，并且用FoxPro For Windows抢走了
Philippe Kahn花大钱购买来的dBase使用者，的确是等于狠狠地打了Philippe Kahn
一巴掌，让Philippe Kahn知道，先出手并不代表会赢得最后的胜利。
这对于日日夜夜想打败Microsoft的Philippe Kahn来说，当然是无法忍受的耻辱，因
此，Philippe Kahn念念不忘的就是如何扳回一城。在dBase For Windows 5.0失利
之后，Borland决定再次重新出发，准备推出新版本的dBase For Windows，来挑战
FoxPro For Windows。不过，市场情势的发展却出现了变化，PC数据库市场已经开始
走入关系数据库的时代，桌面型数据库的市场已经开始出现下滑的现象。
1997年12月，Borland推出最后一版的dBase For Windows 7.0来角逐市场。dBase For
Windows 7.0的品质和功能才是Borland早该在几年前推出的产品，如果Borland早几
年推出dBase For Windows 7.0，那么Windows下dBase的市场绝对会由Borland寡占，
FoxPro For Windows将不是对手。只可惜时不我待，在dBase For Windows 7.0推出
之际，Windows下dBase的市场已经大势已定。虽然dBase For Windows 7.0的确是一
个好产品，但是它再也无力改变市场了。此外，此时PC桌面型数据库的市场也逐渐萎
缩，Microsoft也准备走向关系数据库市场，Windows下dBase的市场对于Microsoft来
说，已经不那么重要了。
在dBase For Windows 7.0推出之后，Borland事实上也察觉到了PC数据库市场的变化，
准备以InterBase进入关系数据库的市场。至此，延续数年之久的PC桌面型数据库
的战火也终于近乎停止状态了。
当Borland的Visual dBase小组发现整个数据库市场的变化之后，内部产生了相当大
的矛盾，许多Visual dBase的工程师在不看好dBase产品的情形下纷纷决定转换跑道。
"弃船"也许是当时最适当的形容词，几乎所有的Visual dBase的工程师都希望进入
Borland Java开发小组，没有人愿意继续留在Visual dBase小组。因此，当时Visual
dBase小组在Borland内部引起了不小的骚动。每一个人都想到Java小组，许多Borland
C/C++小组的工程师也都希望进入Java开发小组，但是Java小组并不能容纳这么多人。
最后许多无法进入Java小组的工程师不是离开Borland，就是随着Borland卖出dBase
时跟随Visual dBase到了新的公司。
最后的晚餐
1998年的Borland Conference应该是Visual dBase在Borland最后一次的盛会了。当
时使用Visual dBase的使用者已经不多，因此在BorCon 1998年中Visual dBase的讲
座也不多。不过对于一些dBase的忠诚使用者来说，Visual dBase 7.0仍然是他们的
最爱。因此在BorCon 1998年，当时在Visual dBase界中最著名的支持者Alan Katz负
责了许多Visual dBase的讲座，也号召了许多dBase的使用者参加这次的Borland
Conference。
Alan Katz的努力显然是希望Borland不要放弃Visual dBase，能够继续开发dBase的
产品。不过，这些努力仍然无法挽回市场的形势以及Borland的决心，BorCon 1998也
终于成为Visual dBase最后一次的舞台。
生命的延续--dBase 2000
1998下半年，Borland终于决定把Visual dBase卖掉，因为Borland已经不想在Desktop
的数据库市场竞争了。在Borland决定卖掉Visual dBase的信息传出之后，立刻引起
了许多dBase使用者的强烈反应。他们认为Borland不负责任，因为如果Borland随便
把Visual dBase卖掉，那么Visual dBase便注定会从此消失。由于当时dBase使用者
的压力太大，因此Borland不得不小心翼翼地处理这个烫手山芋。当时的Borland已经
是放也不是，不放也不行了。
为了缓和dBase使用者的强烈不满，Borland宣布会谨慎地选择购买dBase的公司，而
不会随便把dBase卖出去。这个时候，Alan Katz也知道了Borland的决定。出于对
Visual dBase的热爱，Alan Katz决定找寻资金来源把dBase的版权从Borland的手中
买下来。很快，他找到了一些dBase的爱好者，每人拿出一定的资金来集资购买Visual
dBase的版权。在Alan Katz取得了资金之后，便立刻和Borland联络，准备和Borland
谈判。当然，在Alan Katz集资的过程中，Borland也试着寻找对Visual dBase有兴趣
的公司或是个人，不过这个过程并不顺利。
因此当Alan Katz和Borland接触之后，双方立刻有了交集，双方都有很高的意愿。不
过，在深入的谈判之后，Borland很快发现Alan Katz的资金和Borland想要求的版权
费有很大的距离。原本Borland不太想再谈下去，不过，在Alan Katz和Borland接触
的消息传出之后，却获得了许多dBase使用者的欢迎。Alan Katz在dBase界的高知名
度以及多年来对于dBase的贡献都让dBase的使用者觉得，如果由Alan Katz收购dBase，
那么dBase仍然将有美好的未来。于是dBase的使用者开始向Borland施压，希望Borland
能够成功地和Alan Katz谈好条件。
虽然Borland不太接受Alan Katz的条件，但是在遍寻不到适合的买主、再加上dBase
使用者的强烈要求和Borland急于解决Visual dBase的情况下，Borland终于在半买半
送的条件下把dBase所有的原始程序以及版权卖给了Alan Katz。在Borland决定出脱
dBase给Alan Katz之后，Alan Katz便立刻和朋友成立下KSoft软件公司，准备延续
Visual dBase的产品生命。
1999年3月12日，Borland终于廉价售出了1991年花费数亿美金并购来的dBase产品，
dBase在Borland不受重视的日子也终于结束。Alan Katz在购买了dBase的版权之后不
久，便把公司更名为dBase Inc.公司，1年之后，也就是2000年的12月，dBase Inc.
推出了自己的新dBase产品，取名为dBase 2000，至此dBase系列产品也终于正式延续
了产品生命。dBase在80年代诞生以来，持续生存了近20年的时间，可说是PC软件中
生命力最为强韧的软件了。dBase被Philippe Kahn的狂妄自大所牺牲，IntraBuilder
因Delbert Yocam目光如豆而夭折。虽然dBase因为再转卖给其他公司而得以延续生命，
但是对于Borland来说，dBase和IntraBuilder终究是在遗憾中结束了生命的产品。
Paradox
对于Borland来说，Paradox一直是棵摇钱树，为Borland赚进了大把的钞票，同时也
让Borland称霸PC数据库市场。不过Paradox并不是Borland自己研发的(嗯，写到这里，
我才突然想到，Borland数据库产品几乎都不是自己开发的，都是并购来的)，是从一
家叫做Ansa的小公司购买来的。在1985年，为了进入PC数据库市场，Borland看上了
Ansa公司的Paradox产品，于是在1985年的秋季正式购买了Paradox，成为Borland第
一个数据库开发工具。
其实，在Borland所有的数据库产品中，Paradox是最受Borland照顾的，这也许是因
为Paradox是Borland的第一个数据库产品，也或许是因为Philippe Kahn对于Paradox
情有独钟。但Paradox对于Borland也有着很大的影响，因为Paradox后来不但成为Borland
的主力产品之一，存取Paradox的数据存取引擎也成为数年后Delphi的主要数据库和
存取引擎，BDE/IDAPI也是从Paradox Engine演化而来的。
Borland取得了Paradox之后，很快就开发出了Borland Paradox For DOS，正式进军
PC的数据库市场。由于Paradox当时独特的Query By Example(QBE)以及每一个版本都
维持兼容的良好特性，很快就吸引了许多的使用者，Paradox也成为当时dBase系列之
外另外一个非常流行的数据库产品，在国外非常的盛行。而Paradox之所以没有在台
湾/大陆等地流行起来，原因便是Paradox一直和Double-Byte的兼容有问题，无法正
确地处理中文信息。
由于Paradox在DOS以及Windows初期的版本中表现得非常抢眼，因此Philippe Kahn一
度想以Paradox称霸PC桌面型数据库市场，投入许多的资源研发Paradox For Windows，
并且不惜压制Borland自己的dBase产品来壮大Paradox在Windows市场的占有率。不
过，很显然Borland的脑筋仍然没有转过来。在dBase、Paradox和FoxPro等PC数据库
开发工具被使用了多年之后，已经开始慢慢地进入一般计算机使用者的市场来解决日
常数据处理的工作，因此在PC桌面型数据库市场，已经开始需要一些比dBase、Paradox
和FoxPro等更简易、好用的产品了。在这方面Lotus便掌握得比Borland好，因为Lotus
开始开发适合一般计算机使用者的桌面型数据库工具，那就是后来的Lotus Approach。
Paradox的导向一直是以程序员为主，后来Paradox引以为傲的开发语言Paradox
Application Language(PAL)也以面向对象为宣传重点，强烈地吸引着想使用面向对
象技术开发数据库应用程序的程序员。正是因为Paradox从头到尾都是以程序员为导
向，所以在Paradox到达了巅峰之后，仍无法吸引一般的计算机使用者，也无法进入
这个新兴的市场--Paradox对于这类计算机使用者而言实在是太困难了。因此，当
Lotus的Approach步步为营(嗯，"Approach"这个名字还真符合当时的状况)，掌握
了新起的PC桌面型数据库工具市场之后，Borland等于同时失去了dBase市场给FoxPro，
又无法通过Paradox渗入新的数据库工具市场。
当Borland也察觉到Paradox的瓶颈以及新兴起的PC桌面型数据库市场之后，急于让
Paradox进入Lotus Approach掌握的市场。因为Borland相信，以Paradox这么优秀的
品质，绝对有机会同其他新的竞争对手一较长短。因此，Borland开始了Paradox
For Windows 5.0的研发工作，准备为Paradox加入许多简易的功能，以打开新市场
的契机。
虽然Borland很努力地想要转变Paradox的产品形象并且打入新的市场，无奈Paradox
的产品定位已经非常的固定，而且此时Microsoft也进入了PC桌面型数据库工具市场，
并且以Microsoft Access屠杀和血洗Lotus Approach，Paradox当然再也没有机会在
这个市场称雄了。不过也还好，Borland晚了一步进入这个市场，才没有让Paradox
和Approach一样被Microsoft的Access以极为不合理的手段所消灭。
1994年3月，当时的Novell还想在Office产品线中和Microsoft一争长短，因此大手笔
地并购了WordPerfect公司，并且从Borland买走了Quattro Pro以及Paradox的使用权。
Novell当时的想法是让这些Office产品和Novell的Network OS连接在一起，以便与
Microsoft抗衡，挽救Novell日益下滑的局面。不过，当时我根本不看好Novell的这
个举动。连开发商业应用程序为主的Lotus都不是Microsoft的对手，更何况从来不以
商业应用程序为擅长的Novell呢？而且除了NOS之外，Novell还开发出过什么知名的
产品呢？因此，Novell真正的目的恐怕并不是和Microsoft竞争，而是为了固守Novell
NOS的地盘，防止被Microsoft进一步地侵蚀。从这个现象，我们可以知道Novell早
在1994年便开始逐渐采取防守的策略，已经无力和Microsoft竞争了。
Paradox的告别作
Paradox和Borland的缘分似乎已经快到了尽头，虽然Borland试图在Paradox For
Windows 5.0时改变Paradox的策略，转向一般计算机使用者，不过Borland的努力显
然失败了，Paradox的核心就不是为这个市场设计的。因此，在Paradox For Windows
5.0表现得不如人意之后，Borland又决定把Paradox定位在专业的P C桌面型数据库工
具市场，准备推出下一个Paradox重要的版本--Paradox For Windows 7.0。
1995年12月，Borland推出了几乎是品质最好的Paradox，即Paradox For Windows 7.0。
严格地说，Paradox For Windows 7.0是当时所有PC桌面型数据库开发工具中功能最
强大、品质最稳定的工具，可以说是当时的王者。可惜时不我待，其时大部分的桌面
数据库应用都被Microsoft Access抢走，一般PC使用者的人数远超过数据库程序员的
数量，因此，Microsoft Access的销售量是其他所有PC桌面型数据库开发工具的数倍
之多，再加上关系数据库也快速地流行于PC的应用之中，PC桌面型数据库开发工具在
上/下夹攻之中，市场也逐渐地消失了。
对于PC桌面型数据库开发工具市场的不断萎缩、以及关系数据库市场的快速兴起，
Borland也了解到必须正视市场的变化。因此，Borland开始着手从Ashton-Tate取得的
InterBase，准备进军关系数据库市场，同时卖出Paradox以集中资源开发InterBase。
此时，刚好Corel夹着CorelDraw以及绘图软件取得的雄厚资金从Novell手中又买下了
PerfectOffice所有的软件。因此Borland也决定一次性把所有的Paradox版权卖给Cord。
1996年1月底，Borland正式和Corel签约，卖出最后Borland保留的Paradox权利给Corel。
从此，Borland不再拥有任何Paradox的权利，也不再继续开发Paradox。这也就是为什么
Delphi/C++Builder之中的Paradox数据库规范最高只到Paradox 7，因为Borland再也
没有权利开发新版本的Paradox以及Paradox引擎和数据库规范了。
Corel在取得了Paradox之后，也持续地开发Paradox For Windows一直到9.0的版本，
但对于市场已无任何举足轻重的影响，因为延续10几年的PC桌面型数据库市场已然退
出市场的主流，不管是dBase、FoxPro、Paradox还是其他的类似产品，也注定被Access
和关系数据库所逐渐取代。
后言
Borland在PC桌面型数据库以及关系数据库方面的战役一直是问题连连。除了Paradox
之外，Borland接连错失了以dBase主掌天下的大好时机，也没有及早通过InterBase
进入关系数据库市场。如果当时Borland能够在一开始从Ashton-Tate取得InterBase
之后，立刻研发和进入关系数据库市场，那么以当时Borland的力量绝对可能成为关
系数据库的霸主。因为在那个时候，Oracle等公司还是非常小的，而Microsoft也没
有关系数据库的产品，但是Borland手中却有InterBase。无奈，Philippe Kahn没有
看到未来数据库市场可怕的成长潜力，任手中的宝贝闲置了好几年。等到其他的关系
数据库厂商已经闯出了名号后，才发现原来自己家中早已有一个好东西，但是在落后
别人已多的情形下想要追赶，却已不容易了。
Borland在PC数据库市场上犯了过多的错误以及失去了许多宝贵的机会，否则很有可
能主宰PC数据库市场、持续地和Microsoft竞争，并且站稳软件大厂的地位。回顾Borland
在PC数据库市场的搅和，实在是令人不解而又令人叹息!既然有眼光并购潜力十足的
各个数据库厂商，为何又放任大好的契机流失呢？这个问题的答案恐怕只有Philippe
Kahn才知道了。
^v^v^v^v^v^v^v^v^v
第七章 中途岛之战--Borland和组件技术
"没有中间件技术，我们就没有未来!"
Golden Gate Strategy
1996年，Borland察觉到软件技术将会开始朝中间件的方向发展。由于Borland一向只
开发工具软件，因此如何面对这个软件趋势便成了重要的问题。当时Borland陷入一
片混乱之中，新任CEO Delbert Yocam还尚未进入公司，软件和产品线的开发方向几
乎都是由担任Borland R&D Director一职的Paul Gross负责。1996年7月，Paul Gross
和Delphi的负责人Zack共同激活了一个崭新的计划，其目的是为了让Borland能够在
未来的软件业界中保持高度的竞争力。
当时，Borland已经开始想往企业市场发展。但是，Borland缺乏企业市场需要的大型
架构技术，那就是所谓的中间件(Middleware)。中间件通常都非常复杂，而且需要许
多时间才能够开发完成，更何况中间件服务器都需要运行在许多不同的硬件平台上，
例如SUN、HP和IBM等大型机器中，而那时Borland只是一个开发PC软件的公司，不但
对大型机器的开发完全没有经验，而且也没有相关的硬件设备来支持开发。尽管如此，
Borland和Paul都知道，在未来中间件技术绝对是软件产品的主战场之一。如果Borland
不趁早往这方面发展，那将永远没有机会成长为大型的软件公司。因此，Paul和Zack
知道，Borland必须想办法克服所有困难，以取得中间件技术。当然，最快的方法就
是并购拥有这方面技术和产品的公司。在寻寻觅觅了一段时间之后，Paul终于找到了
在Boston的一家软件顾问公司。虽然这家公司不大，但是却拥有使用RPC(Remote
Procedure Call)通讯协议技术的中间件市场的领导产品--Entera。
RPC是一个存在了非常久的软件技术，发展得非常成熟。Entera被许多如HP之类的大
型公司使用。于是Paul想通过并购这家软件顾问公司以取得Entera，再通过Entera把
Borland打入企业级市场。如果Borland能够整合Entera和Borland的开发工具，那么
大型企业可能也会开始使用Borland的工具。这对于Borland来说，算是很好的机会，
因为如此一来，Borland不但可以取得中间件技术，更可以让开发工具进入以往Borland
难以进入的市场。
就在Paul心动之际，又恰逢这家位于Boston的软件顾问公司经营发生了问题，也在寻
找新的资金来源，因此和Borland可以说是一拍即合。不久之后，Borland便宣布，Entera
正式成为Borland的产品之一。在Paul决定并购Entera之后，立刻激活了Golden Gate
Strategy(金门战略)，开始要求Borland的开发工具必须和Entera整合在一起。同时
Borland也第一次开始大量购买大型的硬件，准备研发Entera，至此Borland通过Entera
正式进入了大型的以及基于UNIX平台的软件市场。
在Borland取得了中间件技术和产品之后，便很高兴地把Golden Gate Strategy呈现
给世人，宣示Borland已经成为整合科技的领导厂商之一。当时Paul还特别拨了一笔
预算，拍摄了一个宣传Borland Golden Gate Strategy的动画影片，其中使用的宣传
语是"We don't want to own the world，we just want to make it work better(
我们不想拥有世界，只想让它运作得更好)"。相信许多读者可能会记得这个影片。
Borland在取得了Entera之后，算是进入了陌生的中间件市场。虽然Borland通过Entera
企图打入企业市场，但严格地说，Entera只是让Borland这个招牌被较多的企业知晓。
而Borland在销售Entera方面表现得并不好，因为Borland一开始并不熟悉RPC技术，
另外就是Borland当初的销售体制无法成功地销售企业级的软件，因为新的公司体
制尚未建立起来。由于Entera在之后的表现不如人意，后来几乎只有Entera的旧客户
才购买新版本，Entera已经无法吸引新的客户了。这当然也是因为市场上的中间件技
术主流已经慢慢转换为使用CORBA和DCOM技术。因此，不久之后，Borland便把Entera
的维护和开发新版本的工作交由Borland亚洲研发中心新加坡来处理了。
Borland一直到取得了CORBA技术之后，才开始真正掌握中间件技术，并且逐渐打入企
业市场。
并购Visigenic，取得CORBA技术
Borland在第一次的中间件尝试不甚成功之后，还是没有放弃想在中间件开发的决心。
当企业市场的中间件主流技术转为使用CORBA之后，Borland又看到了第2次机会。
当CORBA技术逐渐被企业和PC界视为明星技术之后，提供CORBA相关产品的IONA和
Visigenic便成为许多人眼中的潜力软件公司了。不过由于IONA已经早一步推出了CORBA
产品并且也已经拥有了许多客户，因此IONA成长得非常快速。相反Visigenic是刚成立
不久的小软件公司，而且还处于亏损状态。
Visigenic是由Roger Sippl先生创立的。Roger Sippl是信息业界非常有名的人，因
为他也是Informix的创始人。像Roger Sippl这样的人，在美国被称为"创投冒险家"。
这群人的特点就是拥有极为敏锐、先趋的眼光，不断找寻新的信息契机成立软件公司。
一旦新公司有了一点成果之后，便立刻果断地卖出公司以求获利，而甚少长久经营一
家公司。
Roger Sippl创立了Informix公司，在有了一点经营成果之后，立刻把Informix卖掉，
大赚一笔，此后又再试图建立其他的小公司寻找机会和买家。Visigenic就是后来Roger
Sippl看好CORBA技术之后成立的小公司。Borland看到CORBA的潜力，但没有足够的本
钱并购IONA，因此看上了规模还小的Visigenic。Borland找上Visigenic，表示愿意以
数百万美金和股票分配权购买Visigenic公司，当然Roger Sippl立刻答应了。因为如
此一来，Roger Sippl不但可以让Borland负责Visigenic的负债，还能够赚进大把的
现金和Borland的股票，何乐而不为呢！
因此在1997年11月，Borland正式购买了Visigenic，而Roger Sippl也成为Borland当
时的CIO。当时我就知道，Roger Sippl一定是暂时性的担任Borland的CIO，目的就是
帮助Borland顺利接收Visigenic的产品线。一旦Borland掌握了之后，Roger Sippl一
定会立刻离开Borland，再次找寻新的机会。果然当Visigenic的产品在Borland稳定
之后，Roger Sippl也就离开去创立其他的软件小公司了。不过，对于Borland来说，
这并没有损失，因为Borland要的本来就只是Visigenic的CORBA产品。1998年，我还
在Borland的总部Scott Valley聆听了已经快要谢顶的Roger Sippl的演讲，宣示Borland
未来在中间件市场的光明前景。那也是我最后一次看到Roger Sippl。Borland取得了
CORBA产品之后，果然没有再败坏家产，而是立刻投入资源开发Borland自己的CORBA
产品线，那就是VisiBroker。很快，Borland就有了成果。当时Netscape正和Microsoft
火拼到最高点，Netscape为了增加Navigator在企业级市场的优势，决定在Netscape
中内建CORBA客户端引擎。在Netscape评估了IONA和Borland的CORBA产品后，决定使
用Borland的CORBA引擎，因为当时Borland虽然没有像IONA一样拥有比较完整的CORBA
产品和CORBA服务，但是VisiBroker却拥有体积小、执行速度快的优点，正好适合在
客户端的浏览器中使用。
当Netscape找上Borland的时候，Borland简直是喜上心头。当时的Netscape是如日中
天的软件公司，全世界使用Navigator浏览器的人数超过数百万。如果Netscape决定
使用VisiBroker，那Borland不但得到了最大的客户，而且还可通过Netscape的名气
立刻让全世界的人、包括企业级的使用者都知道Borland这家公司，了解Borland是有
能力提供企业级的软件解决方案的。
在Netscape和Borland磋商之后，立刻就有了结果。Borland答应以极低的价格授权
Netscape在Navigator中使用VisiBroker。虽然在这次的商业谈判中，Borland几乎
没有什么赚头，但是，Borland却达成了极为重要的形势胜利。首先是通过Netscape
的授权使用，Borland的VisiBroker在CORBA市场的占有率立刻超越了IONA；第二是
VisiBroker通过Navigator打入了企业市场，让许多大型的企业开始对VisiBroker产
生了兴趣，以致后来VisiBroker在金融和电信领域突破IONA的阵地，成为更受欢迎
的CORBA引擎；第三点当然就是Borland可以通过Netscape这个成功的案例宣传Borland
的CORBA产品，让VisiBroker再也不会矮上IONA的产品半截了。
在这次成功地出击CORBA市场之后，Borland终于开始让IONA正视自己为最强劲的竞争
对手了。这也开始了Borland和IONA之间无止境的CORBA大战，双方在各个CORBA应用
领域厮杀惨烈，一定要分出高下。
当然，Borland在CORBA的成功也让Patti和Zack的Golden Gate计划显得比较圆满，而
且在Paul和当时Borland R&D Director Joe Bently的要求下，Delphi和C++Builder
也都开始支持CORBA的功能。至此Golden Gate计划逐渐走向成型阶段，Borland终于
在中间件技术杀出了一条血路。
Paul Gross的愤怒和Golden Gate的坠毁
但不幸的是，当Delbert Yocam在1999年4月被Borland董事会踢出门之后，担任Borland
R&D副总裁的Paul Gross便一直认为Borland新的CEO职位应该非他莫属了，于是开始
积极争取CEO一职。不过，Borland的董事会却认为如果公司真的想进入企业市场，就
必须拥有专业的销售团队，需要一个在销售领域非常有经验的人来担任CEO。Paul Gross
出身于R&D，对于销售没有太多的经验，无法为Borland建立起所需要的销售团队。因
此，Borland董事会决定从外面寻找新的CEO。
在得知了Borland董事会的决定之后，Paul Gross非常愤怒。因为他认为Golden Gate
Strategy是他策划的，Borland能够进入企业市场，取得中间件技术，都是因为他的
眼光和功劳。现在Borland董事会居然不考虑由他接任新的CEO，Paul Gross心中充满
了怨言，对于Borland产品线的开发工作也就顿时失去了兴趣。
在Borland开始向外寻找新的CEO之际，Microsoft也得知了这个信息，于是马上就和
Paul Gross接触，想了解Paul Gross的动向。此时正是Paul Gross最不满的时候，因
此和Microsoft相谈甚欢，很快便答应到Microsoft工作。由于Paul在Borland已经是
R&D部门的副总裁，因此Microsoft答应给Paul的职位也是Microsoft开发工具部门的
副总裁，负责Microsoft的Visual Studio以及Internet方面的产品研发工作。这又是
一个Microsoft直接挖角Borland人才到自己公司担任类似工作的例子。Paul Gross虽
然是以副总裁的角色被挖走，Microsoft给予Paul的待遇也很高，但和Anders Hejlsberg
比起来还是差多了。这也说明美国对于技术专才的重视，高层管理人员的待遇不见得
会比第一流的技术人员高。
注：从Paul Gross的事例中，似乎可以看到技术人员的宿命。技术人员最高的职位好
像就是技术副总裁了，想做CEO是不太可能了的(除非是技术人员自己开的公司)。这
是真的吗？
看来，Paul Gross在Gold Gate Strategy中写错了那句名言。Paul Gross是想拥有全
世界的，所以才加入Microsoft，不是吗，Paul？
随着Delbert Yocam、Zack Urlocker以及Paul Gross等人一一离开Borland，Golden
Gate Strategy就再也没有人提起了。虽然Borland已经拥有了当初Golden Gate Strategy
规划的所有软件技术，不过在Java快速兴起并且掌握了企业市场之后，软件的发展似
乎已经移转到了Java应用程序服务器市场。这个软件趋势也造就了BEA的快速成长。
等到Borland的下一任CEO Dale Fuller先生任职之后，他立刻投入大量的资源进入Java
应用程序服务器的竞争市场。至此，Golden Gate Strategy也就正式成为历史灰烬了。
到EJB的阵地吧！
虽然Borland在CORBA领域逐渐超越IONA，并且开始成为市场的领导者，不过，Java的
日渐兴盛也开始让CORBA面临考验。而在Windows平台，CORBA也必须面对Microsoft的
COM/COM+中间件技术的竞争。当SUN提出Java的RMI技术后，一些对CORBA并不了解的
人开始鼓吹CORBA已经是日薄西山了，他们认为CORBA这个已经存在许久且复杂的技术
可能会被Java方面的RMI取代。不过，后来事实很快就证明RMI根本无法取代CORBA。
先不说RMI的功能和CORBA比起来简直是九牛一毛，更何况RMI的执行效率根本不是CORBA
的对手，因此关于RMI是否能取代CORBA的争论很快就平息了下来。
不过，当SUN提出了J2EE架构准备力推EJB技术时，又有许多人不看好CORBA的命运，
认为CORBA的长路将尽，Java世界终将使用EJB而不是CORBA。一开始，SUN也认为EJB
是最好的中间件技术，认为企业应该采用EJB作为中间件的引擎来开发企业应用系统。
不过当SUN真正试着把EJB打入企业市场时，才发现CORBA早已在企业市场根深蒂固，
许多大型的应用系统都是使用CORBA技术开发的。如果SUN要把EJB推上企业中间件
的主流，那么EJB一定要能够同CORBA兼容和沟通。因此后来SUN修改了EJB的规格，让
它和CORBA兼容，以顺利解决大型企业需要整合CORBA以及新的EJB技术的需求。
Borland很早就发现CORBA和EJB根本不冲突，反而有很高的兼容性，CORBA的跨平台特
性又非常适合用来实现EJB的功能规格。因此在1999年，Borland开始进行用VisiBroker
作为实现EJB服务器引擎的研究工作。Borland在中间件市场付出了庞大的成本，奸不
容易才在CORBA方面有了一点成果，如果又被EJB抢走中间件市场的主流，那么Borland
岂不是损失惨重？而且Borland好不容易通过Golden Gate计划进入中间件市场，从RPC、
CORBA一路走来，既然已经在中间件市场投下了重注，那就没有理由现在因为EJB而
退出市场。更重要的是Borland看到了未来EJB市场的潜力，如果SUN真的能够把J2EE
架构打人大型企业应用的核心，那么掌握EJB服务器的厂商将会拥有巨大的商机，因
此Borland无论如何都不能放弃这个市场。
为了在EJB市场成为领导厂商之一，Borland不惜巨资投入了许多的资源来研发EJB服
务器的产品，并且以开发工具和CORBA产品赚得的资源源源不断地资助EJB开发小组，
以期能够早日开花结果，让Borland在EJB的中间件技术市场再下一城，奠定Borland
在这个领域技术至尊的地位。不过事情发展得却并不像Borland预期的那样简单。
几乎也在同一时期，另外两位重量级的厂商BEA和IBM也分别投下了巨大的资源进入EJB
市场。BEA选择的方式是快速并购Tuxedo，并且以Tuxedo为引擎开发EJB服务器；而IBM
则是占有最丰富的资源优势，以最大的团队规模投入Java和EJB市场。虽然Borland也
投入了巨资，但是Borland的"巨资"和这两家比起来根本不够看。很快BEA和IBM就有
了成果。当然，由于UNIX服务器战场的关系，当BEA和IBM推出EJB的服务器之后，立
刻引起HP等大厂商加入EJB来火拼。SUN自然也不会置身事外。一场EJB的世界级大战
展开了。
这么激烈的EJB战场，是当初Borland可能没有想到的。加入中间件技术大战的厂商每
一个的规模都比Borland大上几十倍，甚至是数百倍。这种大规模的阵仗是Borland前
所未见的。因此，当Borland开发出了EJB服务器引擎之后，才发现在大型中间件市场
不是光比技术和产品。除了技术和产品之外，还要比公司招牌的知名度、专业服务、
专业顾问咨询和专业的销售团队。此外，更需要极大的公司资源准备打一场长期的消
耗战。
一直到进入了EJB市场，Borland才真正了解到这个市场的对手是如何对战的。为了在
这个割喉市场生存下去，Borland公司策划了第三次的转变，以便为Borland建立专业
的销售体系，准备以不同的手法开打EJB的战争。这在稍后Borland的演变一文中有详
细的说明。
够强壮再玩下去吗?
到了2002年，中间件市场已经到了成熟而且是最后关头的时刻。EJB厂商之间的竞争
已经快见分晓，Borland是否能够坐稳除了BEA/IBM之外的第三领导厂商地位，事关
Borland能否在EJB服务器市场存活下去。又或是Borland与BEA成为联军，一起攻占
其他EJB竞争对手的最后滩头堡呢？这个答案也许在2003年会揭晓。不过，不管如何，
现在的Borland似乎又在中间件市场找到了另外一线生机，那就是.NET平台下的中间
件战争。这个故事将在稍后"EJB对抗CORBA？有趣的假设"一章中讨论。
^v^v^v^v^v^v^v^v^v
第八章 Borland的成长和改变
许多人都用过Borland的产品，就像我和正在阅读本书的读者一样。有的人非常喜欢
Borland，有的人则只把Borland当成一个普通的软件公司。不可讳言，软件人员对于
自己使用的工具或语言，总有着一股喜爱和狂热。当然，在爱屋及乌的效应下，他们
对于推出工具或语言的公司自然也有了类似的情结。
对于许多软件人员来说，"Borland"这个名字是非常可敬的。因为Borland敢于对抗
Microsoft，历经十几年仍然屹立不倒，而且还能不断地推出令人惊喜的产品。这令
人印象深刻，使人打心底里佩服。当然，Borland的产品品质有高有低。面对优秀产
品，总会让人高兴不已，让人有少康中兴、打败Microsoft、一吐心中闷气的愉悦；
相反，对于并不令人满意的产品，又有一种恨铁不成钢、混杂着担心Borland未来的
焦虑感。这种既期待又悸动、心情上下反复的感觉，是那些不喜欢Borland产品的人
所不能体会的。
在十几年的发展中，Borland展现了强劲的生命力。在每一个关键时刻，Borland以不
同的产品、技术和策略度过了一次又一次的挑战和难关。虽然Borland始终代表着除
了Microsoft以外的最大独立软件开发厂商，可事实上，她从创立一直到现在，已经
历经了三个重大的转变。这些转变不但影响了Borland产品的走向，也影响了Borland
的组织架构以及未来的发展。不知喜爱或是关心Borland的读者是否注意到这些转变？
在继续阅读本章的内容之前，不妨先回头想想您是否知道这些转变。
Philippe Kahn，产品和技术为主的Borland
Borland的创始人Philippe Kahn代表的是Borland第一时期。在Philippe Kahn主掌期
间，Borland从无到有、茁壮成长至全盛，成为全球瞩目的、世人最看好的软件公司
之一，继而业绩快速下滑终至差点解体。Philippe Kahn创造了Borland最辉煌的软件
王国，也差点成为亡国之君。先不论Philippe Kahn的功过如何，总之，在他主控的
时期，Borland最注重产品和技术，甚至日后Borland的命运也似乎和Philippe Kahn
的个性有着密切的关系。
恃才傲物的Philippe Kahn从来不给美国华尔街的分析师什么好脸色。1991~1993年，
是Borland最会赚钱的时代，也是Borland内部生产力最高峰的时期。当时Borland的
股票价格高高在上，最高时期曾经每股单价超过了100多美元。在那个时候，Philippe
Kahn几乎是Borland的国王，拥有Borland大量的股票。功成名就的Philippe Kahn认
为Borland的成功都是他的功劳、都应归结于他的领导，况且Borland的实力和产品非
常坚强，不需要为那些华尔街的分析师进行什么公关工作，Borland的股票仍然将是
投资大众的最爱。因此，当华尔街的分析师希望Philippe Kahn能够向他们说明Borland
未来的开发方向以及公司在管理和财务方面的信息时，Philippe Kahn并不理会这些
分析师。所以，在Philippe Kahn时代，Borland和华尔街的关系并不好。
有一次，华尔街的分析师邀请了许多公司的CEO演讲，其中也包括Philippe Kahn。没
有想到，Philippe Kahn的现场演讲却完全不给这些分析师面子，还嘲笑他们是笨蛋，
因为Borland完全不需要任何的分析，Borland就是最好的公司，投资Borland准没有
错。Philippe Kahn这个自大而且不给面子的行为终于惹火了许多华尔街的分析师。
这不但使Borland和华尔街的关系更为紧张，而且，许多分析师也常常借机修理Borland，
宰杀Borland的股票。更糟糕的是，在Borland从1994年逐渐走下坡之后，许多分析师
更是落井下石，看坏Borland的未来。因此，不时地有Borland将会关闭、被并购或
是被拍卖的不实消息散出，让Borland的股票价格快速地往下落底。这都是Philippe
Kahn种下的恶果。
Philippe Kahn对于产品和技术的坚持造就了Borland，但是太过坚持反而变成了刚愎
自用，他完全听不进去其他的意见。通常来说，Philippe Kahn一定会参加Borland许
多的产品开发计划会议。对于好的或是他喜欢的产品，Philippe Kahn坚定支持，即
使产品可能没有市场，他也不去理会。或者是因为太过于坚持产品、一定要尽善尽美，
即使严重地延误了产品应该上市的时期，造成产品已经没有推出的价值，Philippe
Kahn也不管。因为Borland是他的，他有100％的决定权。此外Philippe Kahn在许多
会议中太过于强势，喜欢主导产品的研发，造成产品开发主管不知如何是好，因此惹
火了许多有天分的研发人员，致使他们纷纷求去，Borland C/C++的Eugene Wang就是
一个很好的例子。
Philippe Kahn少年得志，以至于最后目中无人、狂妄自大，终致鞠躬下台。不过，
Philippe Kahn毕竟是所有Borland CEO中最重视产品开发的。自他之后，再也没有任
何的CEO能像他一样，知道唯有产品和技术才是Borland的命脉。Philippe Kahn对于
Borland未来发展的规划也是以产品和技术为主轴。当时的Borland最重视软件开发人
才、工程师和产品经理。但从Philippe Kahn下台之后，整个形势慢慢地有了改变。
不过，总体来说，这个时期的Borland，是我最喜欢的。
Delbert Yocam，强势Marketing为主的Borland
Borland第二个重要的时期应该是Delbert Yocam上台之后。在Philippe Kahn被赶出
公司之后，Borland历经了一段没有真正CEO的时期。在这个时期，担任CEO的人都只
是暂时的，因为Borland董事会决定从业界寻找有实际大型企业管理的人物接手Borland
CEO一职，以带领Borland走出低潮。事实上，从这个时期开始，Borland已经逐渐走
向一般大型软件公司的路线，而不再以充满软件开发者理想的公司自居，因为此时的
Borland需要的是大量的收入和有效率的管理，以拯救Borland濒临破产的命运。Borland
放弃了Philippe Kahn，建立起Borland理想而务实的生存之路。
寻寻觅觅了一段时间之后，Borland终于找上了曾任Apple副总裁的Delbert Yocam。
由于Delbert拥有丰富的大型企业经验，并且对软件公司很有兴趣，因此和Borland董
事会一拍即合，答应担任CEO以重振Borland。事实上，在Delbert之前，Borland的董
事会也曾找了许多知名的美国大型企业经理人，希望他们担任CEO。但由于当时Borland
已经岌岌可危，许多专业经理人都不感兴趣，致使Borland一直无法找到理想中的CEO。
所以，Delbert的应答立刻让Borland董事会精神大振，认为Borland终将起死回生，
回复以往光荣的历史。不过始料未及的是，数年后的事实证明，找Delbert担任CEO是
一个错误的决策。
不知读者是否发现问题：Borland董事会中应该会有经验丰富的人选，为什么不直接
从中寻找而要从外面找人呢？其实，原因也同样，那就是Borland董事会中有资格担
任CEO的人也认为这个工作艰巨，不敢轻易尝试。另外一个问题则是，既然数年后证
明当时找Delbert Yocam管理Borland是一个错误，那为什么这些经验丰富的董事会成
员却无法预知当初就不应该找他担任Borland的CEO呢？可见，要成功地管理一个公司
是不容易的，即使是经验丰富的专业人土，也不见得能够找到适当的管理人才。
Delbert Yocam成为Borland的CEO之后，立刻开始了两项工作。第一是把他在Apple的
工作团队带入Borland。Delbert逐一安插他的工作团队到Borland的每一个重要职位，
以便完全掌握Borland并且执行Delbert的意志。Delbert从Apple引进Borland的人物，
大多属于管理阶层的经理人，只有Rick LeFaivre属于信息技术方面的人。当时，Rick
LeFaivre被任命为Borland的CTO(Chief Technology Officer)，负责掌管Borland
的信息技术和产品开发。
Delbert在成功地建立了自己的管理阶层之后，第二步便是开始掌握Borland的产品。
为了实现改造Borland的计划，Delbert很快就提升Zack为Borland Marketing副总裁，
开始试图改善Borland一向积弱不振的Marketing表现。
刚开始接手时，Delbert是有心好好地管理Borland。因此，在Delbert管理的早期，
Borland还有盈余。除了Delbert个人比较奢侈的享受外，并没有太大的错误。我也曾
经在Borland的总部听过Delbert对员工讲话，那是因为当时的那一季Borland表现得
很好，Delbert很高兴地鼓励大家继续努力。演讲之后，公司还举行了一个小Party，
提供有大量的食物和饮料。嗯，当时我还大饱了一顿口福。
不过，随着时间的过去，由于Delbert过度干涉产品的开发，Borland开始走向亏损，
公司股价也始终没有出色的表现。更麻烦的是，Delbert砸下巨资让Zack领导的Marketing
部门不但没有太大的表现，反而招致更多的抱怨，让Delbert管理下的Borland烽火连
天、麻烦处处。Borland董事会开始质疑Delbert的管理能力。在后期并购工作失败、
而且Delbert带入的管理团队看到大势不妙、纷纷跳船求去之后，Borland董事会也终
于决定换掉Delbert，另觅新的CEO，自此Delbert的时代宣告终结。
基本上，我认为Delbert想要改善Borland在Marketing方面的弱势是正确的步骤，因
为Borland一直拥有好的产品和技术，但在Marketing方面却一直混乱一团。当时，
Borland的收入主力仍然是Box-Moving的产品。这就是说，Borland主要是以销售盒装
的开发工具为主，尚未进入以组件和中间件为主的时期。因此，强化Borland在市场
的知名度以及领导地位，再配合好的产品，Borland是大有可为的。但是，Delbert过
于心急地干预产品开发时程和方向，这不但没有改善Borland Marketing的弱势，还
把产品搞坏了，实在是赔了夫人又折兵，也让Borland元气大伤。
Dale Fuller，高效率Sale Force的Borland
Delbert离开Borland之后，Borland的CEO真空了一段时间，因为董事会还在搜寻适当
的人选，希望他能够带领Borland走出困境。不过在Borland找寻CEO的同时，软件业
界进步和竞争的脚步并没有停顿下来。在开发工具和软件产业中，除了Box-Moving的
产品之外，组件和中间件的力量愈来愈强。BEA便是在这段时间通过购买了Tuxedo之
后快速地在EJB应用程序服务器的市场中成长。而Borland在并购Visigenic、取得了
CORBA的技术和产品，而且也推出EJB应用程序服务器之后，Borland传统的销售Box-
Moving方式却不适合用来销售中间件。因为Box-Moving的产品可以靠Channel卖出，
但是中间件产品却需要搭配教育培训、专业咨询服务来一起销售。另外，中间件产品
需要较长的销售期间，更需要专门的销售人员来服务客户，这些都是当时Borland没
有建立起的公司制度。因此，即使Borland拥有最好的组件和中间件技术，却因为不
知道如何销售而任凭好时机消逝。此外，在Windows平台上的开发工具也已经逐渐达
到了饱和。虽然Windows平台上的一些开发工具厂商慢慢地淡出，使Borland和Microsoft
能够逐步蚕食其他厂商留下来的市场，但无疑这已经所剩无多。因此，Borland需要
新的市场、新的刺激，才能够持续成长。
Borland下一任CEO面对的挑战是很艰辛的，因为Borland需要再次改变，以适应销售
组件和中间件的产品。另外，新的CEO必须开拓新的市场，让Borland的开发工具产品
能够拥有成长的空间。最后，新的CEO必须能够带领Borland走出亏损，并且想办法拉
高Borland的股价。Borland的董事会在接连找了数个失败的CEO之后，此次对于新的
CEO特别谨慎，希望新的CEO不要再把Borland搞砸了。
Borland董事会找上Dale Fuller，是因为当时正值Internet/Intranet热潮兴起之时。
Dale Fuller成功地创办了自己的公司、并且在经营了一段时间之后又漂亮地把公司
以高价卖出。因此，Borland董事会对于Dale Fuller高明的手腕和眼光深感兴趣，开
始接触Dale Fuller，看看Dale是否有意愿接手Borland。在卖掉了自己的公司之后，
Dale此时也正需要另外一个一展身手的舞台，所以，当Borland的董事会和他接触之
后，Dale开始注意Borland这家软件公司，并在思考了一段时间之后决定接任Borland
CEO。当然，我不知道Borland董事会和Dale之间的约定，不过，在Dale开始接任Borland
CEO之时便有谣传，说Dale Fuller是希望以高明的手腕看看能否为Borland找到归属。
因为，Dale Fuller选择了大量的Borland股票权而不要求高薪，希望用股票选择权大
赚一票。
和Corel的合并案
Dale上任之后不久，便逐渐接近公元2000年全球Internet/Intranet疯潮以及股市狂
飙的时期。当时所有和电子商务以及Linux、CORBA有关的软件公司的股票都狂飙不已，
例如RedHat、BroadVision和IOAN等。但是奇怪的是，虽然Borland也拥有CORBA的技
术和产品，可是Borland的股票却从来没有狂飙过，真是令人不解。Dale Fuller眼看
Linux概念股都开始狂飙，立刻决定投入Linux市场，责令Borland的RAD部门必须立刻
开发出Linux上的开发工具(这就是Kylix的源起)，希望能够通过这个举动吸引全球看
好Linux的热钱大买Borland的股票。
此外，Dale Fuller和当时Corel的CEO Michael Cowpland经人介绍之后，两人一见如
故。当时Corel决定开发Corel Linux，而Borland也决定开发Linux上的开发工具，更
重要的是两人都看好Linux的热潮，而且当时Corel的股票已经开始上涨到30多美金。
因此，Dale和Michael在试探了彼此合作的意愿之后，立刻一拍即合。公元2000年的
2月7日，Corel和Borland宣布了两家公司准备合并的消息。
在Dale Fuller和Michael Cowpland宣布合并的消息之后，原本以为靠着Linux概念和
两家公司(一个开发Linux操作系统，一个负责Linux开发工具)的完美组合，肯定会带
动两家公司股票价格的上涨。
没有想到，消息公布之后，却不被业界看好。因为当时许多业界的专家都已经预测Corel
撑不了多久，原因是Corel的产品的市场占有率快速地下降，花下大把银子推出的Corel
Office根本无法动摇Microsoft Office的地位。此外，Corel的现金也即将用完、情
形不妙。
果然，合并消息发布之后不久，Corel的股价很快地往下跌，而且居然跌到比Borland
还低。至此，Borland和Corel的合并应该算是破局了，因为Borland不可能和比自己
价值还惨的公司合并。于是在公元2000年5月17日，Dale Fuller终于叫停了这桩合并
案。Dale提出的理由有三：
■ Corel 2000年第1季的收入锐减
■ Corel宣布接下来的2个Quarter的情形也是一样
■ Corel宣布在3个月之后现金将会用完
当时Borland虽然亏损，但是仍然握有大量的现金，而Corel却是现金即将用完。如果
不停止这个合并案，那么Corel也很快会把Borland的现金耗尽，到那个时候Borland
便万劫不复了。因此Dale毅然坚决地停止这桩合并交易，并且付给Corel一笔金钱作
为取消合并的赔偿。
在此事件之后，Michael Cowpland也从Corel辞去了CEO一职。而Dale Fuller在遭遇
了这个挫折并且无法找到适当的合并公司之后，决定开始改变自己的角色，准备再次
转变Borland，让Borland成为适合当前竞争的软件公司。
开始打造成销售的Borland
Dale Fuller在抛开了被合并或是并购其他公司的想法之后，第一件事情便是开始回
头检视Borland的状况和产品线，看看为什么Borland会陷入亏损的地步、以及如何让
Borland重振雄风。其实，当时Borland虽然处于亏损，但拥有的现金仍然相当充裕，
有稳定而大量的使用者群组，并没有亏损的理由。因此，Dale首先决定，稳定Borland
开发团队的军心，弥补Delbert Yocam对于Borland产品带来的伤害，并且大幅整理
Borland的管理阶层，尝试为Borland建立一个更有效率的专业管理团队。此外，Dale
大刀阔斧地进行了下列工作：
■ 稳定开发工具产品线，回归产品开发的本质
■ 扩充新的产品线
■ 建立专业销售团队
他首先将Borland的产品线划分为三个主要部分，分别是负责Windows/Linux RAD开发
工具的RAD部门；负责Java开发工具的Java部门；以及负责组件和中间件的Enterprise
部门。每一个部门都建立了明确的管理组织架构，力求改善Delbert时混乱的产品管
理。
第二项工作便是扩充新的产品线。由于Microsoft在Windows平台上占尽了优势，虽然
Borland仍可和Microsoft一搏，但Dale认为，Borland如果要持续成长，必须拥有更
多的收入。因此，Dale决定在Linux上增加新的产品，除了原先Linux上的开发工具之
外，也要开发下一代产品。
Dale发现Borland拥有CORBA和EJB的技术和产品，但是却没有这方面专业的销售团队，
使用的仍然是传统的销售方法，造成了这些产品叫好不叫座的状况，迟迟无法打开市
场。因此，Dale执行的第三个计划，便是为Borland建立专业的销售团队，使用适当
的方式销售CORBA和EJB产品。于是，Dale开始在Borland的销售区域中建立专业的管
理和销售团队，并且开始改变Borland的一些公司政策，以便配合新的销售策略。
Dale的努力果然逐渐显现出成效来。Borland从2000年开始便逐渐转亏为盈，而且营
业额不断增加，进而创造了Borland在2001/2002年连续获利和营收上升的表现，在全
世界一片不景气的情形中呈现出亮丽的成果。Borland的年营收额从当时Delbert的180
几Million美金成长到现在超过220几Million美金，开始愈来愈接近10几年前Borland
全盛时期的营业额了。
Dale改造Borland的行动也影响了Borland的日常工作方式。例如，在我以前为Borland
工作时，除了负责产品和技术之外，也兼做一些Presale的工作，因为那时Borland没
有正式的Sales人员，所以技术人员有时也必须客串一下Sales。但是在Dale引入了专
业的销售人员之后，有许多工作现在都是由专门的Sales人员负责，技术人员则配合
Sales进行工作。现在的Borland编制中有了以前没有的Sales团队。
Dale的改造除了增加了Borland的营收之外，也改变了Borland的组织结构。Sales人员
和Sales部门现在是Borland强势的力量，和以往Philippe Kahn时以技术人员为主、以
及Delbert Yocam时以Marketing为主完全不一样。现在Borland的技术人员和Marketing
人员必须配合Sales来工作，所有员工的表现也以Sales绩效为衡量的根据。虽然我非
常怀念Borland以往的时光，但是我也知道这个转变是不可避免的，因为这是让Borland
更有竞争力的必要步骤。只是我认为，太过强势的Sales在长期来说仍然不太好。Dale
应该在Borland逐渐成为有效率的销售公司之后，再回头好好加强在技术和研发方面
的力度，让Borland能够再开发出几个划时代的伟大产品。
在Dale Fuller成功地打造富有成效的销售企业之后，Borland不但每季都赚钱，更重
要的是，在2001/2002年全世界不景气中居然还不断地成长。同时，Borland开始在欧
洲和亚洲快速地成长，不断带动Borland营收创造新高。这也让许多专家跌破了眼镜，
创下软件公司在不景气的气候中还持续成长的范例。Borland的股票价格虽然没有狂
飙，但是已经比许多当时有名的软件公司的股价还高。Dale成功地完成了Borland第
三次的转变。Borland除了技术和产品之外，同时也成为拥有高效率管理和销售的公
司，的确是和以前不一样了。现在Borland手中不但拥有大量的现金可以并购对Borland
有帮助的小公司，更有许多知名的软件大公司现在都和Borland合作。例如，Sybase
和Borland合作推出了JBuilder-Sybase Edition、JBuilder-WebLogic Edition。从
2000年到2002年，Borland的确打了一场漂亮的胜战。
第四波的演变
Borland在历经了三波的改变之后，已经逐渐成了一个比较典型的美国软件公司。虽
然不再有Philippe Kahn时代以开发者为主、带有理想主义色彩的软件公司形象，但
是在本质上比以前好多了。特别是经Dale Fuller大力整顿之后，Borland的营运效率
比Delbert时代好上数倍。不过，Borland虽然比以前更有效率、更有竞争力，但是却
得面对比以前更为险恶的生存环境和竞争。
首先是软件平台和技术的改朝换代。虽然Borland努力在Java方面有了一定的成就，但
是又面临了Microsoft .NET的推出。其实，Borland一开始也为了是否要跟随Microsoft
进入.NET新平台而犹豫不决，因为Borland当时想要趁Linux的热潮改走跨平台的方向，
而不是在Windows平台辛苦地和Microsoft竞争，这也是为什么Borland在.NET方面进入
得比较缓慢的原因。不过，随着Linux在2000/2001年从爆炸性成长逐渐回归成正常的
发展之后，Borland很快发现，光靠Java和Linux市场将无法获得足够的利润。另外，
在所有知名的信息研究机构的分析都指出.NET在未来将和Java一起占有相当大比重的
市场之后，Borland才知道是不可以失去.NET市场的。于是，Borland这时匆匆地投入
了.NET产品的研发。
第二则是随着软件利润的趋于下降，Borland必须想办法维持公司的成长，开辟新的
产品线。从2000年开始，Borland推出并且扩充了Kylix产品，研发了新的.NET产品，
并且有数个内部不公开的技术和产品在进行中。这些行动让Borland投注了许多的资
源，是否能够成功，是对Borland开发产品的功力以及公司是否能够在市场和策略方
面合理搭配的考验。在现在这个时代推产品，已经不像数年前只要品质够好就可以，
还需要其他许多方面的配合。
第三则是随着软件技术愈来愈多，应用也愈来愈多元化。这使得产品的潜在客户群被
分散。如何凝聚使用者成了开发工具厂商重要的工作。Borland除了需要巩固原有的
使用者外，也急需开发新的潜在客户才能够达到经济客户规模。因此，Borland必须
在使用者族群方面建立良好的支持社群，并且强化和使用者互动的关系。
第四，Borland除了需要持续增加效率之外，回归基本面、好好地着重产品开发并且
建立坚强的开发者社群是最重要的工作。
软件高科技公司的命运
如果读者是在信息产业经历了一段时间，那么可以观察到目前著名软件公司在经营上
风格的异同。每一家公司在成立之初，创办者都有特定的理想或是技术，软件公司也
一样。不过随着公司的成长和发展，软件公司的风格却逐渐地出现差异。我说的风格
当然不是指每一家的企业文化，这当然会有不同，我指的是软件公司的创始人目前是
否仍然是这家公司的主要负责人。
美国企业喜欢并购，许多公司的创始人也喜欢在公司有了一点成就之后立刻卖出公司，
以股票换钞票，许多的美国公司董事会也喜欢动不动就换CEO。这造成许多公司的CEO
只注重炒短线的工作，只想把公司股票价格炒高，然后卖了公司就闪人。如此做法会
让软件公司的产品和营运快速地走下坡路。Borland就历经过这种CEO。但是请读者观
察，只要是公司创办人仍然还在掌舵或是担任重要职位的软件公司，对于产品就会坚
持，不会随意以炒股票来恶搞。例如以Microsoft来说，虽然这是一家饱受争议的公司，
但是她的创始人Bill Gates仍然掌握Microsoft，因此Microsoft仍然在源源不断地开
发产品和提出新的构想。不管这些产品是好是坏，我们都不可否认，Bill Gates仍然
在努力地实现他的理想，即使一般大众都认为这是狼子野心。这让Microsoft持续地保
有活力和竞争力。
再比如，Oracle的创始人Larry Ellison仍然执掌Oracle。虽然Larry Ellison也是属
于好大喜功的人，但是我们不可否认，在Larry的领导下，Oracle仍然振奋向前。这
些现象可以从其他的、正在力争上游的软件公司看出，例如Developer Express、
Atozed software以及目前正和Microsoft在多媒体市场打得不亦乐乎的RealPlayer等，
这些公司的特点便是对于产品的努力和坚持。
反观一些走下坡或是关闭的公司，其中许多都是由于公司的创始人离开而导致。例如
以前著名的数据库厂商Informix，就是由于创始人Roger Sippl卖掉Informix的股票
另起炉灶。后继者对于公司没有热忱，最后因为经营不善而终于成为历史。Informix
如此，Netscape又何尝不是呢？Netscape被American Online并购之后，快速地走下
坡路。前一阵子我看到的新闻消息指出，目前Netscape在全世界的占有率只剩下3％。
这个曾经占有超过90％市场并给予Microsoft强烈威胁的浏览器巨人，也在创始人离
开之后消声匿迹，逐渐被人淡忘，真是令人不胜唏嘘。
Philippe Kahn的Borland是只会做产品的公司，Delbert Yocam时的Borland只会短线
操作，以致让Borland快速走下坡路。现在，Borland在Dale Fuller的主掌之下好不
容易地回稳，并且在2001/2002年全世界不景气之中仍然呈现稳健的成长，算是相当
难能可贵的。Dale Fuller虽然不是Borland的创始人，但是似乎对于经营Borland真
的发生了兴趣，愿意管理Borland，也愿意投入心力规划Borland的产品线，是相当认
真的CEO。Borland在经过了多年之后终于找到了一位不错的CEO，希望Dale Fuller能
够以公司创始人般的热忱，带领Borland再创另外一个高峰。
当然，公司创始人是否仍然是软件公司的重要人物不是判断一间软件公司唯一的指针。
如果软件公司能够适当地吸引专业的管理人才来改善公司的体制是很好的事情，因为
这样的公司有可能结合创新的理想，对产品的坚持以及有效率的专业管理，这是对公
司以及使用者最好的保障。没有了创始人的存在，软件公司总是少了一股对于理想的
坚持，不是吗？
Borland Conference
Borland Conference对于Borland的使用者来说是非常重要的事件。就像回教徒一生
一定要去麦加朝圣一样，Borland Conference也是许多Borland开发者想要参加的重
要技术研讨会。Borland Conference已经有了相当久的历史，在美国也算是评价很高
的技术研讨会，每年几乎都会被专业媒体评选为最值得参加的Conference之一。
我一直都非常喜欢参加Borland Conference，因为这绝对是超值的盛会。Borland
Conference最近几年都维持一个惯例，那就是一年在美国东海岸举行，下一年在美国
西海岸揭幕。我曾很幸运地参加过3次Borland Conference，分别是1995、1998和1999，
每一次参加都收获满满。参加Borland Conference除了可以聆听许多精彩的Seminar之
外，也可以遇见许多信息界重要的人物，例如我就在Borland Conference中见过Bruce
Eckcle、Martin Fowler和Peter Codd。当然，也可以和Delphi、C++Builder和JBuilder
的开发团队见面而且和他们交谈、互动。通过和这些R&D研发小组见面，我也认识了许
多Borland R&D中重要的人物，Chuck、Danny和Blake等。也只有在Borland Conference
中才有机会、有比较多的时间和他们交谈，否则就必须飞到Borland总部Scott Valley
才能见到他们了。
早期的BorCon是比较偏向开发工具的Seminar，每一个开发工具各自提供多场的Seminar
让参加者选择。因此，在BorCon上很容易就可以从参加者的人数和反映来了解Borland
每一个开发工具产品在市场上的表现。C/C++的参加者在较早的BorCon中占据了大部
分的Seminar，每一场C/C++ Seminar都是挤得水泄不通。但是在1995年Borland推出
了Delphi之后，每一年参加BorCon的人中Delphi的使用者占据了愈来愈多的比例，而
C/C++的参加人数反而快速地下降。一直到了最近几年，Delphi的人数还是BorCon中
占有最大比例的群组。但是，在BorCon的参加者中，Java的开发者也占有愈来愈高的
比例，由此可见开发工具和语言使用的趋势。
在Borland陆续取得了组件和中间件技术、推出CORBA、EJB产品之后，最近数年的BorCon
更是呈现了多元化的发展。BorCon中的Seminar愈来愈多，同时也有许多的Seminar是
围绕着COM+、CORBA、EJB以及软件设计、开发和管理的主题。在早期参加BorCon时，
我大都选择参加开发工具和技术的Seminar。但是到了后期，却非常喜欢参加软件设
计和架构的Seminar，因为在这些Seminar中可以听到非常多的、宝贵的知识和经验，
这是很难在其他地方能听到的。
我喜欢收集BorCon的T-Shirt，不但免费、好穿，更有纪念价值。现在我仍然拥有一
件1995年的、紫色的BorCon T-Shirt，夏天时穿在身上好不神气。每一届BorCon都有
专门设计的Logo和代表本次BorCon的T-Shirt。下面是我收集的一些BorCon Logo和参
加BorCon的小花絮，与读者一起分享。
1998年，我参加了在丹佛举办的BorCon。不过在丹佛实在有些无聊，除了白天的Seminar
之外，晚上不知道做些什么。丹佛的BorCon结束之后，Borland又另外举行了内部工
程师训练，因此我总共在丹佛呆了一个多星期，都快发霉了。好在是和朋友一起参加
的，彼此间还有个伴。另外也巧遇了几个从台湾去的人，居然其中还有相识的，感觉
特别温暖。
费城的BorCon是非常令人难忘的。我和李匡正(Tom Lee)在赴会途中被整惨了。先是
从台湾坐飞机到Newark机场，因为空中交通拥塞，飞费城的飞机在延滞了4个多钟头
之后才取消，我只好和Tom Lee从Newark坐巴士，这样又花了4个钟头才到费城。当时
香港和新加坡的同事还在苦等我和Tom Lee，很久未到，以为我们出事了，吓出了一
身冷汗。
但在费城参加BorCon时却很愉快。因为一行中有高官相随，所以吃了费城最好的牛排，
也抽了点时间游览费城市区。但是从费城回台湾又是噩梦一场。因为从费城到LA的班
机延误，所以当我和Tom Lee到了LA机场之后，回台湾的班机已经出发了，而且随后的
一班飞机也没有空位。害得我和Tom在LA机场空等了12个多钟头，才搭上回台湾的飞机。
更惨的是行李却已经直接Check-in，而我的长袖衣物都在check-in的行李中，害得我
在LA机场差点被冻僵。
我很想参加2002的这次BorCon，因为很想看看Anaheim市的模样。当然，这也是因为
Anaheim有一个Anaheim天使队，Tom Lee很喜欢这支球队。不过，由于当时我正忙于
工作，无法分身参加，实在遗憾。2003年将是BorCon 20周年的庆典。听说这次Borland
将要隆重举办，提供最丰富的BorCon。我也想参加不可错过的BorCon 2003，拿几件
T-Shirt作为永远的纪念。想想，一个技术Conference能够举办20年，可真是不容易，
不知道参加的时候，是否能够有机会在异乡巧遇我的读者呢？
并购、自保和集团战
商场真是诡谲多变，没有人知道会发生什么事情。但是，2002年底，数个令人震惊的
软件公司并购案可能会大大地影响2003年软件公司的竞争，也有可能影响到我们每一
个人的饭碗。
200l/2002是Borland绝处逢生、营运蒸蒸日上的时段。Borland靠着在Java开发工具
市场所向披靡的机会连续11季产生盈余，并且在大多数软件公司赔钱的情形中快速地
累积了大量的现金。虽然就公司营运的角度来看，拥有大量未使用的现金不见得是好
事情。但是，在这段不景气的时间中，"Cash is King"，拥有现金就是拥有力量。在
蓄积了强大的能量，并且思索了如何在Java和.NET平台的竞争下找出一个康庄大道后，
Borland终于在2002年底出手了。
首先，Borland确定了在.NET上的开发之路，誓言成为除Microsoft之外最好的.NET开
发工具和企业解决方案提供厂商。此外，Borland也决定在Java战线上往上再提升一
个层次，拉大和对手的竞争距离，以确保Borland在Java平台的优势。
由于未来软件的竞争势必是Java和.NET两大平台主宰，因此，如何在两大平台保持竞
争力，是每一个软件厂商都必须严肃面对的。坦白地说，别说是Borland，现在已经
没有任何公司能够再建立一个新的平台同SUN的Java和Microsoft的.NET竞争了。所有
的软件厂商都必须在这两个平台下提供最好的工具、技术和解决方案，软件厂商如何
同手握平台主宰力量的SUN/Microsoft竞争，这便是每一个软件厂商能否生存下去的
重要话题。
对于Borland来说，既然无法取得系统平台的优势，而单靠工具以"点"为单位作战的
时代也已经过去，如何进行"面"的全面备战便是Borland必须思考的战略问题。还好，
Borland还是有一些聪明的人，想到了既然如果无法争取到系统平台的优势，那么为
什么不在系统平台上提供一个"中立的应用平台"呢？这真是一个好想法，并且也值得
一试。
所谓"应用平台"，是指Borland要在Java和.NET上提供全方位的软件解决方案。这也
就是说，Borland除了以往的开发工具、中间件和J2EE之外，将提供完整的软件供应
链。在2002年的产品线中，要想实现软件供应链，Borland仍然有很大的缺陷。例如
Borland几乎只有开发工具和后端的中间件，缺少了效率调整、整合测试、Modeling
工具、自动测试等软件和工具，更不用说许多在中间件方面的服务，例如Messaging
服务、Transaction服务等。这些工具都是小规模的软件，因此Borland面临了是需要
自己开发还是通过其他途径来取得所缺少的软件的抉择。
其实，Borland面临的选择已经不多而且很明显了。如果Borland决定自己开发从未进
入过的软件市场，那不仅需要花费长期的开发时间，而且在开发出来之后，又必须面
对市场已经存在的竞争对手，胜算不大且缓不济急，等到Borland开发了新的软件之
后可能已经来不及。因此，Borland决定通过现金并购的方式来取得这方面软件，所
以展开了稍后的一系列Borland大并购行动，继而也震惊了软件界，引发了另一波软
件公司并购的热潮。
并购行动的展开
Borland出击的第1步，便是根据Blake Stone的建议，并购VMGEAR公司的OptimizeIt
产品线。由于JBuilder已经是Java开发工具市场的老大，许多程序员经常会询问为什
么Borland没有提供Java效率调整方面的工具，也都非常希望Borland能够为Java程序
员提供这样的工具。当时，市场上Java效率调整工具主要是由Sitraka的JProbe和VMGEAR
的OptimizeIt在进行激烈的竞争。在Blake看好OptimizeIt的情形下，Borland很快就
决定并购VMGEAR，因为OptimizeIt不但可以让JBuilder的战斗力更为坚强，还能够帮
助Borland填补欲形成的软件供应链的缺陷。
2002年1月22日，Borland以现金快速收购了VMGEAR，很快成为Java效率调整工具的领
导者，OptimizeIt也很快整合到JBuilder中并且扩充功能，增加了OptimizeIt Suite
这个新的产品。Borland并购VMGEAR并且在很短的时间内便推出新的OptimizeIt产品，
可见这次是玩真的，而不像以前往往在并购了新的公司和软件之后便放在那里不闻不
问。
在购得了VMGEAR之后不久，同年的10月9日，Borland以更大的动作收购了闻名的团队
开发以及软件管理公司Starbase。这个收购行动当时出乎许多人和软件公司的意料。
因为在2000年，Starbase公司的市值还超过Borland，其股票的价格也远远高出Borland
的股票价格。没有想到两年之后，Borland居然有能力并购Starbase。由此可见两年
来Borland和许多软件公司势力的消长。Borland购得Starbase公司之后，意欲提供软
件应用平台的计划也隐约可见了。
在Borland当时的计划中，软件应用平台应该包含需求分析工具、分析和设计工具、
开发工具、测试工具以及执行应用软件的服务器工具。Borland购得了Starbase之后，
就拥有了Starbase的团队开发工具以及软件需求分析和管理工具，再加上从VMGEAR
取得的效率调整工具、Borland自己的开发工具以及CORBA/J2EE服务器，距离Borland
想要形成的软件应用平台仍然缺少重量级的Modeling工具。
其实，从Borland开发工具的演进过程中，已经可以发现若干Borland欲往Modeling方
向发展的蛛丝马迹。先从JBuilder开始说起，在JBuilder 6中，Borland已经开始想
为JBuilder加入Modeling的功能，随后出现在JBuilder中的Refactoring和Class
Diagram的功能就是一个证明。
虽然急着往Modeling的方向开发，但是Borland也知道自己开发这方面的软件将是旷
日费时的。因此，Borland决定使用并购的方式快速取得这方面的技术和产品。放眼
望去，Modeling工具市场几乎只剩下两强相争的局面，那就是Rational和
TogetherSoft。由于Rational的市值远比Borland大了许多，虽然Borland已经和
Rational有商业的合作，但是Borland仍然没有可能并购Rational。既然如此，那
剩下的答案就非常清楚了。
在Borland完成了VMGEAR和Starbase的并购之后，Borland的软件应用平台几乎已经完
备，剩下的缺角就是设计和分析工具了。
虽然TogetherSoft并不像Rational一样是Modeling工具市场的第一，也不像Rational
拥有比较完整的产品线，但是TogetherSoft的Modeling工具在Java/C/C++市场享有盛
名，其软件功能和图形使用界面远远超过了Rational的软件。就软件品质来说，
TogetherSoft已经超越Rational甚多。只是TogetherSoft没有Rational的三位知名大
师而已。
在Borland决定和TogetherSoft合作之后，TogetherSoft也非常欣然地接受了Borland
的提议，因为TogetherSoft正想往开发工具市场发展，以补足TogetherSoft没有适当
开发工具来结合其Modeling工具的遗憾，这也是为什么TogetherSoft在早一步从
WebGain购买Visual Café权利的原因。现在，Borland拥有最佳的开发工具，再结合
TogetherSoft的Modeling工具，两家公司有机会共创双赢、打败Rational而成为盟主。
于是TogetherSoft很快就答应了Borland的建议，同意和Borland合并。世事真是难料，
没有想到当初Visual Café和JBuilder恶斗数年之后，竟然由Borland取得了Visual
Café，也让Visual Café最后在Borland的手中成为历史。
正是因为Borland并购TogetherSoft，成了压垮骆驼的最后一根稻草，所以在消息宣
布之后，立刻引起了许多软件公司的震惊和不安，这也激活了软件界的并购风暴。我
当时的预测就是Rational将首当其冲。
并购的涟漪效果
Borland宣布并购TogetherSoft，立刻引起了软件界的轩然大波。由于Borland和
TogetherSoft的合作，对于Rational产生了巨大的影响，而Borland又和Rational有
软件合作，因此为了缓和对Rational的冲击，Borland便下令公司内的人必须对这件
事情封口。当时我就认为Rational也不是傻瓜，他们一定会了解事情的严重性，即使
Borland不提，Rational也一定会有动作。果然在不久之后，Rational便通知Borland，
结束和Borland在Java Enterprise Studio以及Windows Enterprise Studio的合作，
反将了Borland一军。当然这也正式代表Borland终将进入Modeling市场的大战。
Rational和Borland的战事尚未真正开火，就被"螳螂捕蝉，黄雀在后"的IBM盯上了，
IBM开始正式向Rational下手。为什么IBM会找上Rational呢？这要从IBM和BEA之间愈
演愈烈的EJB服务器战争说起。
由于IBM的WebSphere和BEA的WebLogic已经进入最终的市场第一位争夺战，两方人马
都是无所不用其极地想要干掉对方。不过，由于EJB服务器的市场已经进入成熟的阶
段，现在光靠EJB服务器核心已经无法作为胜出的筹码了。这也是为什么WebSphere和
WebLogic都开始加入其他的辅助功能，例如Portal服务、管理服务等，以求能够压过
对手。不过，当大部分的软件服务都被加入之后，剩下来的当然就是从整合开发工具
以及分析/设计软件上动脑筋了。
这也是为什么当初BEA会和WebGain合作而IBM也不愿意放弃VisualAge For Java的原
因。即使Visual Café和VisualAge For Java已经无法在Java开发工具市场成为第一
位的工具，但由于使用EJB技术的企业愈来愈多，也有愈来愈多的企业要求结合Java
开发工具和Modeling工具以便开发大型的Java以及J2EE应用系统。IBM很显然也注意
到了这个市场和需求，于是在Borland并购了TogetherSoft、Rational感觉到巨大压
力的时候，立刻找上Rational。由于IBM出手阔绰，再加上Rational自知要独自面对
Borland和TogetherSoft的联军没有多大胜算，因此也很快答应了IBM的条件，正式由
IBM接收了Rational。
在IBM确定并购Rational之后，这股软件公司之间重量级的并购潮不但没有结束，反
而更为暗潮汹涌，因为IBM并购了Rational之后，开始对BEA和Microsoft产生更大的
影响。IBM在取得了Modeling工具之后就在EJB服务器中取得了整合的优势，对于BEA
将有更强大的攻击力。而BEA在原本已经逐渐落居下风的EJB战役中如果还面临IBM整
合Modeling的攻势，那么情势必将更为恶劣。因此，当时我认为BEA将是IBM这桩并购
案最大的受害者。果然之后不久，许多专业媒体都评论了BEA不利的局势，预言BEA最
强的支持者将会是Borland，甚至许多人也传出BEA将并购Borland的消息。对于这个
传言，BEA的响应似乎是正面的，因为现在BEA已经和Borland有所合作，而BEA和Borland
的产品线也非常互补，没有什么严重的冲突。不过，我个人还是希望Borland能够维
护独立的软件公司。
另外一个受影响的软件厂商则是Microsoft。Microsoft在以前早就和Rational有合作，
不过Microsoft还是那个调调，在自己没有Modeling工具之前希望和Rational合作，
但是一旦有了类似的工具之后(即Visio)，就停止了和Rational的合作，这种做法类
似当初Microsoft和Sybase的合作关系。不过，在IBM取得了Rational之后情势又不同
了，因为现在IBM拥有了非常完整的产品线，IBM可使用这条产品线，以强大又完整的
J2EE架构正面攻击Microsoft的.NET。因此，后来也传出了Microsoft有意并购Borland
以取得Modeling工具的风声。如此一来，Microsoft不但可以在．NET上提供全世界最
好的开发工具、Modeling工具，又能够取得.NET需要的组件模型，即CORBA.NET，以
对抗EJB，可以说是一举数得。不过在开发工具方面，Microsoft和Borland有严重的
重复，又可能会引起独占市场的疑虑，因此我个人认为，这是不太可能的结合，真的
要说，那么双B(Borland和BEA)的组合反而比较可能。
不管未来的发展如何，应该发生在2003年的大战终于在2002年末正式提前开打，Borland
也即将进入另外一个新的转变。
^v^v^v^v^v^v^v^v^v
第九章 软件技术和平台的大竞赛
2002年的2月，Microsoft终于推出了.NET，也击败了许多爱看Vaporware好戏的人。
.NET的出现，代表了窗口平台的软件开发将进入一个新的领域，对于窗口平台上开发
工具厂商也有深远的影响，因为.NET是有史以来变动最大的窗口平台。第一次，
Microsoft把窗口变成一个虚拟执行环境，通过SOAP/Web Service技术，把窗口和各种
行动以及电子装置整合在一起，提供了下一代的整合虚拟数字世界。这个影响是深远
的，它不但冲击了操作系统，影响了下一代窗口操作系统的发展方向，也改变了开发
工具在这个虚拟执行环境中的角色。开发工具厂商必须重新定义、定位开发工具在.NET
中扮演的角色以及未来的发展趋势。
Windows3.0和3.1曾为窗口平台带来了最辉煌的时代，造就了C/C++四大天王(Borland、
Symantec、Watcom和Microsoft)、C/S双雄(PowerBuilder和Gupta)、COBOL两大家(RM
COBOL和Acu COBOL)以及无数充满活力的开发工具厂商。图形用户界面的盛行也让各种
Framework充斥于市。随着C/C++语言的流行，其他语言很快便退居2线。MFC的出现让
Symantec和Watcom退出市场，VB和Delphi的快速成长则让C/S双雄饮恨不及。开发工具
市场在Windows 98之后有了快速而巨大的变化。最后，除了Microsoft和Borland
等少数厂商之外，大部分的开发工具厂商都逐渐退出了这个竞争最激烈、门槛最高的
市场。随着.NET的推出，Microsoft又把竞争门槛再度拉高。这次Microsoft瞄准的是
企业信息市场以及Java平台，程序语言和开发工具的竞争不再是Microsoft关心的重
点，Microsoft的重点是如何在窗口平台提供类似Java已经发展将近10年的计算环境。
不过，这个目标却苦了开发工具厂商，因为他们必须面对新的虚拟执行平台、新的编
译技术和新的Framework。更糟糕的是，开发工具厂商必须在.NET中找到一条新的生
存之道，由于.NET包含了：
■ 一个虚拟执行环境--Common Language Runtime(CLR)
■ 一个庞大且完善的Framework--.NET Framework
因此开发工具厂商必须在这两者以及两者交错产生的软件元素中找到新的技术、新的
应用和新的利基，才能够持续在.NET中生存。更麻烦的是，Microsoft已经提供了一
个开发工具范例--Visual Studio.NET，它比当初SUN的失败作品Java Workshop好得
太多。这不但证明了Microsoft是一个比SUN更精于开发工具的厂商，而且，其他的开
发工具厂商要想凸显其产品更在Visual Studio.NET之上，也将是一件更艰苦的工作。
也许.NET的出现会加速淘汰更多的开发工具厂商，让.NET平台上的开发工具厂商更纯
化，最后只剩下最具实力的少数厂商。目前各家开发工具厂商如何适应.NET的冲击？
它们会提出什么新的软件技术同Microsoft以及其他厂商竞争？谁会是最后的胜利者？
这都将是非常有趣的事情，仔细观察并分析这些问题，或许从中也能学到许多的宝贵
经验。
.NET和Java的发展过程提供了许多耐人寻味的东西。有趣的是，.NET和Java虽然在现
在以及未来的发展有许多类似的表现，但是这两个平台的骨子里却有一些重要的差异。
其中最明显的，就是JVM和CLR分别如何执行最终的应用程序以及单一语言对语言中立
的考验。除此之外，Java和.NET对于中间件组件技术的对抗也是最激烈的一环，因为
中间件技术将是未来主宰系统架构的主要因素，SUN和Microsoft都希望自己力推的平
台成为新的应用标准。
Java和.NET的竞争，虽然从虚拟执行环境、程序语言、Framework一直延续到最新的
软件技术--SOAP/Web Service和数据存取技术，但是组件模型仍然是其中最重要的，
因为它代表的目标市场--企业信息领域，才是这两家必争之地。Java和.NET的组件模
型是程序语言设计之奇、Design Pattern之美、数据存取架构之广以及设计构想之深
的结晶。组件模型不但是SUN和Microsoft市场的关键，也代表了两家领导厂商的软件
技术实力以及系统架构的思想逻辑。因此在讨论Java和.NET竞争时，充分了解J2EE以
及.NET在组件模型方面的发展是很重要的。通过了解这两个阵营在组件技术的竞争，
我们也可以很容易掌握未来Java和.NET的发展趋势。因此随后的文章将从Microsoft
和SUN发展组件模型的历史和趋势开始讨论，让读者了解Java和.NET中位居关键地位
的技术演进，以及组件模型如何影响Java和.NET的未来走向。在本文后半部分，我们
将讨论.NET对于窗口平台中开发工具厂商的影响，以及未来开发工具的适应和发展趋
势。
Microsoft的COM组件模型
Microsoft的COM组件模型一直在很稳定的发展中。舍弃繁杂的OLE细节之后，COM才真
正地奠定了Windows组件模型的核心，开始可以提供制作企业逻辑对象的能力。DCOM
开始提供远程访问和分布式计算以及对象回收的机制，让COM组件模型能够提供企业
级计算的能力。不过在DCOM的时代，客户端仍然是通过Proxy/Stub直接和COM对象互
动，还未到达像EJB组件模型那样由虚拟服务器控管以提供系统服务等功能。但是，
Microsoft很快在MTS 1.0中正式加入了这个功能，至此，COM组件模型能够顺利地加
入企业核心服务，例如Object Pooling、Role-Based安全权限和交易管理等功能。严
格地说，在MTS出来之后，COM组件模型才有资格成为关键性系统的核心组件模型。也
因为MTS，才有后来的Microsoft DNA架构。在Windows 2000中，MTS正式成熟演进到
COM+1.0，除了把MTS调整得和操作系统更契合之外，最重要的进步是大幅提升了执行
效率，因此，Microsoft的TCPP数据大都是以COM+加VC++撰写的。
在不久前推出的Windows XP中，COM+又进步到1.5版。在COM+1.5版中，Microsoft对
COM+进行了许多改善，其中最重要的便是再次提升了COM+的执行效率，让它比COM+1.0
更快。此外，延展性也是COM+1.5的调校重点。Microsoft为COM+1.5加入了Partitioning
功能，企图让COM+的Application能够在不同的Container服务器(DllHost.exe)中执
行，提供对象并联的架构，以增加COM+应用系统的延展性。不过，从COM+1.5目前实
现的程度来看，这应该是初步的规划，未来应该还有很大的进步空间。
此外，COM+1.5也加入了Application Pooling的机制，让程序员可以控制COM+ Container
服务器执行的数目。当Container服务器的执行数达到右图中集区大小的数目之后，
Windows操作系统便会重复使用已经存在的Container服务器，而不会允许客户端继续
建立新的Container服务器，如此一来，就不会让客户端启动太多的Container服务器
以拖垮Windows操作系统。
而应用程序回收(Application Recycling)功能则是Microsoft为了克服COM+内存泄漏
(Memory Leak)问题加入的。在COM+1.5中，程序员可以指定COM+的Application在一
定时间、或是在COM+的Application的内存使用到达一定的数量、或是被调用了一定
的次数、或是被启动了一定的次数之后就重新启动COM+的Application。这样，可以
让Container服务器结束运行，而操作系统则可以回收因为COM+对象泄漏的内存。在
COM+尚未像EJB或是.NET一样以虚拟执行环境进行Garbage Collection之前，这倒不
失为一个好方法，因为Windows 2000和XP在进程安全控制方面有了大幅的精进。
此外，COM+1.5的组件服务程序也允许程序员直接管理和设定旧的COM/DCOM组件，不
需要再使用DCOMCNFG.exe程序。1.5的组件服务程序整合了所有型态的COM组件，是相
当不错的功能。
从COM+1.5的发展来看，其他的许多功能都属于小进步，未来COM+的发展将会很小，
进而COM+会真正地转变成Windows的核心服务之一。未来Windows的组件模型应该是由
.NET的组件架构来接棒，因为Microsoft仍然需要一个提供虚拟执行环境的组件架构，
以提供良好的Garbage Collection和Partitioning的功能，进一步和EJB竞争企业系
统的延展性，而这个征兆可以从稍后讨论的.NET发展看得出来。
SUN的EJB组件模型
经过了将近2年的时间后，SUN终于在最近推出了新一版的EJB 2.0功能规格，很快也
被BEA和Borland的BES实现出来。SUN在EJB 2.0中提出了许多先进而复杂的功能，目
的是为了大幅强化EJB作为企业核心组件架构的本钱，以便在企业系统中和Microsoft
下一代的.NET组件竞争。
从SUN定义EJB的规范开始，就展现了其和COM不一样的观念。EJB一开始就非常重视
Design Pattern和组件种类，例如Session Bean和Entity Bean各自负责不同的角色，
再借助于Java的Garbage Collection，提供了成为企业信息系统组件必要的基础。但
是，在EJB 1.x中，所有的Bean Instance之间的调用都是使用Remote Interface方式，
因此在许多的应用方面付出了较大的开销，导致一些情况下执行效率不佳。在EJB 1.x
中发展出了许多的Design Pattern来改善这种现象，例如鼓励使用Coarse-Grained对
象，以减少网络Round-Trip和Bean之间的调用次数。
在EJB 2.0中，SUN终于为改善这个问题而提出了Local Interface。所谓Local
Interface，是指当Bean Instance在同一个EJB Container中时，EJB Container可以
使用Local Interface调用来代替Remote Interface调用，这样可以增加3倍以上的对
象启动效率。另外，SUN加入Local Interface功能的重要原因是为了支持EJB 2.0中
大幅强化的CMP(Container Managed Persistence)功能。
简单地说，EJB 2.0中的CMP允许程序员使用EJB Query Language来定义Bean之间的关
系。只要程序员使用EJB QL定义了一个Bean和另外一个Bean的关系(Relationship)，
那客户端便可以在存取了主要Bean之后，再通过Bean定义的Finder或是Selector方法
取得所有的从属Bean。如果读者不太了解这个意思，可以参考下面的示意图。在客户
端建立主CMP之后，可以通过主CMP的Finder或是Selector方法取得所有的从属Bean，
此时，主CMP便可以通过EJB QL向数据源查询所有相关的数据，再由EJB Container根
据查询的数据自动建立从属Bean、并且和主CMP建立关联。如此一来，2.0的CMP可以
免除程序员自行撰写存取数据和建立CMP的程序代码的麻烦，并且允许EJB Container
使用最佳化的方式从数据源存取数据和建立CMP。为了增加这个过程的执行效率，EJB
2.0的功能规范要求这种Bean必须支持Local Interface，当然，这也代表着这些会
建立关系的Bean必须执行在一个相同的EJB Container中。EJB 2.0的CMP增加了功能
和效率，但是也增加了Bean之间相互依靠的关系，这会影响EJB程序员在设计系统时
的布局。此外，EJB 2.0的CMP虽然提供了这么强大的功能，但这也是不同厂商实现的
EJB服务器执行效率有差距的地方。不同EJB服务器使用的实现方法的不同，会大大影
响执行效率。这就是为什么SUN定义了ECperf标准来检验和评比EJB服务器的真正执行
效率的原因，这稍后会谈到。
因此，在EJB 2.0功能规格中，SUN定义了数个机制来增加EJB服务器的执行效率，这
在EJB的架构已经很完整的情形下是很自然的下一步。当然，除了上述的功能外，EJB
2.0功能规格也增加了MDB(Message Driven-Bean)，MDB可以让程序员使用异步的方式
传送信息，事实上把原本JMS的功能加入到EJB的功能规格中，是为了对抗Microsoft
把MSMQ整合进COM+。请看EJB进化的示意图，我认为EJB 2.0最重要的进步便是执行效
率、OR Mapping以及EJB的查询语言。EJB的查询语言开启了未来和JDO(Java Data
Object)的整合，目的是和Microsoft在.NET中定义的OPath和数据对象相互竞争，这
在稍后也会再说明。至于OR Mapping，则是一个非常复杂的机制。它规范了Bean
Instance和数据源之间的关系，这个标准可能会让许多小的EJB服务器厂商退出EJB市
场，或是无法完整地支持EJB 2.0的功能规格。
再看看Local Interface的意义。在EJB 1.x中，客户端调用Bean Instance时，在
Container中Bean和Bean之间都是使用Remote Interface的方式进行调用，如下图所示：
事实上，图中显示的启动模式是非常浪费资源的，因为图中的Bean都属于同一个
Container之中，为什么要使用缓慢的Remote调用模式呢？因此在EJB 2.0中定义了
Local Interface。如下图，现在只有在跨越网络或是跨越不同的Container时才需要
使用Remote调用模式，这大大地改善了使用的资源和调用效率。
更好的是在EJB 2.0中，一个Bean可以同时定义Remote Interface和Local Interface。
如此一来，Bean的使用者和组合者(Assembler)可以更有弹性地分发和部署EJB Bean。
在EJB 2.0中，Bean只要从EJBLocalObject继承下来，就可以拥有Local Interface的
功能。例如程序员可以用下面的程序代码来提供Local Interface的功能。本质上，
实现和定义Local Interface的方式和原本的Remote Interface非常类似，因此EJB
的程序员可以很自然地学会这个新的EJB功能。
public interface YourobjectClass extends EJBLocalObject
public interface YourobjectClass extends EJBLocalHome
了解了EJB 2.0增加的功能之后，现在就可以回到前面朋友询问我的问题了，为什么
在EJB中没有看到任何像COM一样的线程模型之类呢？事实上这很简单，因为EJB是一
个标准功能规格，并不包含如何实现的细节，在一般的EJB书籍中当然看不到类似的
东西。而且，COM之所以有这么复杂的各种线程模型，是因为COM发展的包袱以及历史
的因素所造成的。不过，这并不代表在EJB中没有线程模型的问题，因为EJB厂商如何
实现EJB功能规格会深深地影响EJB服务器的效率。因此，线程模型反而是EJB程序员
应该知道的东西，只是依据不同的厂商而有不同的结果，不像COM功能规格是由
Microsoft定义的，也是由Microsoft实现的，因此会有一致的执行行为。
EJB的线程模型应该是使用Object Per Client的模型。这个意思是说，EJB Container
会为每一个请求的客户端建立一个独立的Bean服务。因此，如果EJB厂商没有特别进
行最佳化的工作，那EJB使用的模型应该是类似COM中的STA，也就是说，一次只有一
个Worker线程在Bean Instance中执行。下图就显示了这个架构，对每一个客户端就
启动一对Worker Thread/Bean Instance。
上图叙述的是正常的情形，那如果让两个客户端同时存取一个Bean Instance时，会
发生什么情况呢？下图就显示了这个架构。在这个情形中，如果有两个客户端要同时
存取Bean Instance，那EJB Container如何控制呢？在一般的EJB书籍中，似乎也没
有看到和同步处理有关的范例，难道说，可以不进行任何的处理就让两个客户端同时
存取吗？这当然不会，因为此时EJB Container就会进行管理，以STA的模式控制同步
存取，因此客户端的存取必须依序(排队)来调用Bean Instance。
这个情形也可以直接从Bean的实现程序代码中看出，例如下面的程序代码是EJB的标
准范例Entity Bean的实现程序代码。请注意，在这个Bean类别中定义了数个private
变量，并且在Bean的方法中直接存取和处理这些private变量，完全不需要考虑任何
的同步处理机制，这就是因为EJB Container一般就是使用Object Per Client的模型
以及类似COM的STA的线程控制模型。
这只是一般的EJB Container可能会使用的模型，但有一些EJB服务器提供了最佳化的
机制，可能会提供更为有效率的方式。下面的表格列出了COM/COM+和EJB在线程模型
方面的比较：
因为不同的应用程序服务器厂商实现而不同
读者必须注意的是，上表并不代表COM+是比较好的，只能说COM+提供了较多的选择，
可以让有经验的程序员调整执行效率。但是，相对地也让情形复杂了许多，而且COM+
的MTA线程模型也不容易实现。
正由于EJB功能规格会因为不同的EJB厂商实现而有不同，因此，除了前面提到的EJB
2.0中CMP和OR Mapping会影响EJB服务器的执行效率之外，如果再结合线程模型和对
象建立的技术，那下面列出的问题是影响执行效率的重要因素：
●如何实现和控制Worker Thread。事实上这就是EJB Server中Thread Pooling的机制
●如何实现和控制EJB Bean Instance。这就是EJB Server中Object Pooling的机制
为了让EJB服务器有公平的效率比较基础，SUN定义了ECperf标准让使用者能够用来评
量各家EJB服务器的执行效率，以避免各说各话的情形。从这一点也可以看出，SUN现
在开始注重EJB服务器的执行效率因素了。
为什么我说线程模型会因为不同的EJB服务器而有不同呢？现在让我们以实例来看看
EJB服务器的行为。下图是我使用4个Delphi建立的客户端应用程序，并且使用SIDL技
术来调用Borland Application Server-BAS中的一个Stateless Session Bean的结果。
从图中可以明显地看到，即使是在有4个客户端的情形中，BAS仍然使用了MTA模式，
只建立一个Stateless Session Bean，并且让4个Worker线程同时存取，因此执行效
率非常高，使用的内存资源也非常少。
而下图则使用4个Delphi客户端应用程序调用Stateless COM+对象(使用Both线程模型)，
从图中可以看到，COM+使用Object Per Client的模式，建立了4个COM+对象服务4个
客户端，虽然执行效率也非常高，但是使用的资源稍比BAS多。
接下来，再让我们讨论一下未来Microsoft的组件模型以及SUN的组件模型的演进趋势。
Data Access Technology
在未来，Microsoft和SUN的组件模型大概都会强调数据存取的技术，因为从前面讨论
的EJB 2.0 CMP的内容中我们可以知道，现在SUN已经在为对象和数据之间建立连接的
技术了，而未来的JDO技术将进一步紧密结合数据对象的观念，让程序员面对的所有
东西都是对象，不再有数据和对象不一样的观念和使用方式。
不过别以为Microsoft只会呆在原地，在PDC 2002中Microsoft已经宣示了未来ADO.NET
的发展方向。ADO.NET未来将会结合数据和组件的观念，让.NET的程序员以对象的观
念来代表数据，就像EJB中的CMP/BMP一样。如此一来，.NET的程序员可以像EJB一样
声明代表数据源中数据的数据类型，并且使用以XML格式封装的数据对映叙述器(Data
Descriptor)来连接数据对象和数据源之中的数据。如此一来，.NET的组件模型也提升
到和EJB 2.0加上未来JDO一样的层次。
例如程序员可以定义如下的数据类型：
public abstract class Customer {
public abstract string Name{get; set;}
[Link(Account)] public abstract IList Accounts {get;}
}
public abstract class Account {
public abstract float Amount {get; set;}
public void CalculateTotal() {
// business logic
}
}
并且定义上述Customer和Account之间的连接关系，这和EJB2.0中新的CMP功能一样，
然后再定义如下的对象/数据对映器，把对象和数据源连接起来，请特别注意下面
relationship的部分：
最后，程序员可以使用如下的形式通过数据对象存取数据，并且在数据对象之间自动
形成关联的关系。这非常有威力，和EJB/JDO不相上下。事实上，ADO.NET和EJB/JDO
实现的观念和想法非常类似，这是巧合还是模仿呢？基本上可以说，这两大阵营都有
互相参考对方技术的地方。
下图就是未来ADO.NET的数据对象架构，程序员只需要修改Schema Mapper就可以连接
到不同的数据源，例如MS SQL Server或是Oracle等。
除了ADO.NET的数据对象外，Microsoft也开始定义类似于EJB QL的对象查询语言，目
前暂时称为OPath。当然，我们可以进一步地讨论更为深入的组件技术问题，不过由
于篇幅的限制，就让我们以后在专门讨论技术的书籍中继续说明好了。
下图很清楚地说明了Microsoft和SUN组件模型的发展趋势。从图中，我们几乎可以知
道这两者非常类似，发展的方向也趋于一致。未来比较的因素可能是执行效率、延展
性、能够执行的平台以及开发工具的支持程度和使用的方便性吧。
综合上述内容，从最近Microsoft的COM+/.NET的推出、SUN的EJB 2.0功能规范的完成、
以及中间件厂商实现的EJB应用程序服务器来看，Microsoft似乎也已经开始采用类似
Java的虚拟执行环境以及EJB的模型来重新塑造.NET的组件模型了。COM+将逐渐退居幕
后提供系统核心服务，甚至会慢慢地消失于未来.NET的执行平台之中。不过由于.NET
的进入门槛不低，而且目前仍然有大量的原生Windows开发人员以及Windows应用程序，
因此，这个从COM组件模型完整转换到.NET的过程可能仍然需要数年之久，而COM在现
在开始的数年内仍然是Windows平台上最重要的中间件技术。
据Gartner Group的调查和估计，在2003到2004年使用EJB技术开发的Java应用系统将
占整个Java平台的40％左右，这表示EJB技术已经获得了大型企业和专业软件厂商的
认可，是企业级的组件模型。EJB 2.0必须开始增加执行效率，故此加入了Local
Interface。此外延展性也成为EJB应用程序服务器的发展重点，因为EJB应用程序服务
器势必将承载更多的存取，以担负起企业的关键应用。因此，EJB厂商开始在EJB服务
器中切割虚拟伺服环境，并且在每一个虚拟伺服环境中执行不同的软件。例如一个虚
拟伺服环境负责执行JSP/Servlet Container，而另外的虚拟伺服环境则执行EJB
Container等，如下图所示。这样做的好处是不但每一个Container更安全，而且应用
程序服务器的延展性将更为优秀，因为在多CPU的机器中可以分配专门的CPU给不同的
Container，并且在一个EJB服务器中可以同时执行多个EJB Container。
这里有一个很有趣的区别，那就是由于Microsoft掌握了操作系统，Microsoft可以尽
量地把.NET的虚拟执行环境移往操作系统的核心，提供更为良好的执行效率；但是由
于提供EJB的厂商没有这项优势，因此必须以更好的实现方式来开发EJB应用程序服务
器，这也是为什么SUN以ECperf这个标准来评定各家EJB应用程序服务器的执行效率的
原因。但是从目前EJB服务器的实现观念和技术看，仍然是领先于Microsoft的.NET。
不过不要小看Microsoft，虽然.NET在2002年的第一季才推出，但是Microsoft已经在
开发.NET的第2个版本了，.NET的发展步伐是很快速的。
中间件技术将会继续不断地发展下去，各种新的组件观念和实现技术也将持续地出现。
组件模型技术和中间件已逐渐取代早期的程序语言和数据库服务器，成为现在信息架
构的主导力量，Microsoft和SUN都希望成为这个领域的领导者。不过谢谢信息市场的
竞争力量，让这两家大厂都无法消灭对方，反而由于竞争的力量造成了组件模型不断
地创新，使信息人员能够持续地使用新的、更好的、更成熟的中间件技术，来实现日
趋复杂的信息系统，虽然这个学习的过程很辛苦，但这也是信息行业让人感觉到有趣
味的地方，因为你不会总觉得工作是一成不变的。
只是现在Web Service的兴起让组件模型的界限开始显得模糊了，而Web Service也是
Microsoft.NET和下一版Java JDK强调的重点功能。看起来，Web Service技术将会开
始把组件模型逐渐地转换为面向组件服务，让组件模型的决胜点从面向功能逐渐转向
面向服务。以后哪一个组件模型能够提供企业级的服务模型，将会是决定系统使用的
架构的关键点，而这个现象已经可以从一些中间件厂商最近的动作中隐约的看出。
.NET对于开发工具厂商的影响
.NET的推出，对于所有开发工具厂商而言都是一大挑战，这除了牵涉到技术层面之外，
还包含了复杂的产品定位的问题。相对于当初Windows 3.0/3.1推出时各个开发工具厂
商百家争鸣的盛况比起来，如今的.NET平台就显得逊色了许多。当然这主要的原因在
于.NET中语言不再是重点，再加上语言可以内嵌在Microsoft的Visual Studio.NET中，
这顿时让许多的开发工具厂商失去了定位以及竞争优势。如果开发工具厂商只是做一
个语言的Plug-In到Visual Studio.NET中，那将很难生存下去。
对于像Borland的Delphi、C++Builder以及Sybase的PowerBuilder而言，如何在新的
.NET环境中保持竞争优势是很重要的问题。因为在.NET中，应用程序执行环境、Common
Language Runtime(CLR)以及.NET Framework都是由Microsoft所掌握，其他工具厂
商如何在Microsoft一手控制的环境中营造出竞争优势呢？另外在.NET中，开发工具
厂商必须把应用程序编译成Common Intermediate Language(CIL)的格式，再由JIT编
译器编译成原生机械码执行，如下图所示。
因此，如果开发工具厂商要在.NET环境中继续提供竞争产品，那至少必须在下面的三
个领域中找到答案，并且做出实际的解决方案：
■ 编译器的竞争--如何把程序语言最正确且有效率地编译成CIL
■ .NET Framework的竞争--如何在.NET Framework上进行加值的工作，并且定位产
品竞争力
■ 开发工具本身功能集(Feature Set)的竞争
从编译器角度来说，由于.NET的CLR内建的Virtual Execution System(VES)支持一般
的程序语言功能，同时又提供了丰富的对象模型支持能力，以提供面向对象语言对映
到CLR的能力，因此.NET可以说是OOP-Friendly的执行环境，这非常有助于面向对象
程序语言在.NET中实现，例如对C/C++、Object Pascal等真正的OOP来说是个好消息，
而Microsoft的新语言C#就是一个好的OOP实现范例。但是对于使用脚本语言作为骨架
的开发工具(例如PowerBuilder)来说，可能就需要花上许多的功夫重新规范，以便能
够适当地使用CLR的特性。当然除了程序语言之外，如何开发出一个有效率的CLR编译
器更是开发工具厂商需要费心的地方。
在Framework方面，Microsoft的.NET Framework摆明了要和SUN的J2EE/J2SE/JEME等
竞争，而且花了许多的资源打造.NET Framework，力求能够提供给程序员最好的开发
功能。但是，对于开发工具厂商来说则是有喜有忧。一方面，Microsoft虽然提供了
良好的.NET Framework，可以减少开发工具厂商需要花费的成本；但另一方面，开发
Framework的权力掌握在Microsoft手中，特别是Microsoft也有Visual Studio.NET作
为竞争产品，因此如何定位便成了重要的问题。就我的看法，如果开发工具厂商无法
在.NET Framework上进行增值的工作，那最后仍然难逃被淘汰的命运。
即使开发工具厂商能够克服前面讨论的两个问题，最后仍然要回到产品本身的竞争力
上来。没有集成开发环境、组件架构、调试环境和高生产力，仍然无法和Visual Studio
.NET竞争。开发工具厂商不但要像以往一样提供一个集成开发环境，甚至还必须做得
比Visual Studio.NET更好、更具创意。这也不是一件容易的事情，因为这必须有突
破性的想法。例如，其中的一种可能就是再把.NET的通用性延伸，除了像.NET不把语
言的差异作为重点之外，也不把CIL产生的结果作为差异。由于CIL是一组标准的中介
信息，开发工具厂商可以继续把CIL转化为.NET、原生窗口应用程序、Linux应用程序，
甚至是移动设备上的程序代码，如下图所示。
如此一来，这种开发工具将更为广泛和实用，也是开发工具极好的竞争优势，特别是
现在仍然有许多的软件厂商需要继续开发小而快的原生窗口应用程序。
Microsoft .NET的出现不单对于Microsoft本身有重大的意义，对于窗口平台上所有
开发工具厂商和SUN都有巨大的影响。开发工具厂商正面对着从Windows推出以来最严
格的考验，这是一场生与死的竞争。对于SUN来说，.NET代表的是Microsoft正式全面
地向Java平台挑战，时间将决定JVM和CLR的胜负，而Java单一语言的通用性也将面临
.NET语言中立的考验。至于传统的窗口程序设计人员而言，也许正如"魔戒传奇"中的
哈比人一样，明知前途坎坷，仍然必须选择走向严寒的雪山或是诡谲的地道，因为目
的只有一个：在新一波的软件技术和平台中找到一条生存之路。
^v^v^v^v^v^v^v^v^v
第十章 令人焦虑的时代
"通向未来之路在哪里？"
时间进入2000年之后，许多事情变得似乎都不确定了，世界经济的走向和信息技术的
趋势变得更令人困惑。在经过了Internet/Intranet、Linux和Open Source的洗礼之
后，目前信息技术的发展似乎已经趋向多元化的状态。虽然许多的信息系统仍然在使
用我们早已熟悉的技术(例如Web和主从架构)，但各种新的信息技术也在层出不穷地
出现(例如SOAP和Web Service)，再加上.NET和Java两大平台之间逐渐升温的战火，
让许多软件开发人员眼花缭乱，继而心生疑惑--"自己未来的前途到底在哪里？"
其实，信息人员产生这样的疑惑是很正常的。因为信息技术的发展到达了前所未有的
阶段，不但各种程序语言之间掀起了混战，操作系统平台、虚拟执行平台、开发工具、
组件模型等都兴起了热战。而虚拟执行平台让跨平台模糊了以往壁垒分明的开发领域，
程序语言的多样化稀释了原本由数种语言瓜分天下的态势，而Web和多层架构又逐渐
瓦解了传统的信息架构。这些信息技术的多元化发展，不但让传统的开发人员面临难
以抉择的命运，虚拟平台、程序语言和信息架构等众多的组合变量，也让开发人员顿
然之间感觉负担沉重，担心自己已经跟不上信息发展的快速脚步，那软件开发人员的
未来到底在哪里呢？
信息技术多元化的发展
和许多人的工作一样，也许你还在使用Delphi/C++Builder开发主从架构或是Web或者
一般的应用系统，又或许是使用JBuilder开发Java应用系统。总之，你可能已经熟知
目前所使用的技术，并且大量地应用在日常的应用系统中。但是，身为软件开发人员，
必须了解软件趋势的发展，必须随时注意新的软件技术，因为唯有不断地增加自己的
附加价值，才能够在这个竞争激烈、演进快速的产业中生存下去。
其实从整个软件技术发展的趋势中，细心的软件人员已经能够看出未来的方向。在软
件开发的过程中，每一个时代都有主导的软件技术在影响着当时的产品以及软件公司
的兴衰。当然，能够掌握软件趋势的人或是公司也都获得了成功。从下图中我们可以
看到，在不同年代中不同的信息技术掌握了当时的主宰力量。60/70年代是由数据处
理和程序语言独领风骚，到了80年代便由数据库当家作主，90年代各种组件和中间件
又主导了系统架构。
但是从60/70/80/90年代的软件技术来看，每一个时代都是由一个点的信息技术来主
导。不过在Internet/Intranet时代，面向对象和Modeling等技术对于信息系统的影
响愈来愈大，信息技术的演进逐渐从点形成了面，上图就显示了在2001年之后主要的
软件力量来自平台的整合和竞争、以及全方位的软件技术。其实，作为软件人员，我
们也可以从自己的信息生涯中咀嚼出这个趋势，问题只是在于有没有花时间进行自我
思考。
数年前的软件人员可能只需要了解程序语言即可，例如只需要会C/C++就可以找到工
作。那时数据库也几乎属于专门的技术领域，当时的DBA只要会管理数据库就行，因
为还有许多专门写SQL的程序员。但随着时间的推移，软件人员开始需要同时会程序
语言、SQL以及管理数据库。接着又需要了解组件技术、Web技术、终至面向对象和
Modeling等技术。为什么对软件人员的要求会愈来愈高？这是因为整个软件的发展
趋势正在走向信息技术整合的道路。
未来的软件趋势是走向软件和系统整合，这代表着软件人员必须知道得更多，掌握更
多的技术才能够顺利迎接未来的挑战。唯有掌握每一个独立的软件技术，软件人员才
可能有能力拥有系统整合的能力。从许多的观察、分析和统计中，我们可以抽离出下
面这些最重要的软件技术或是软件特质。这些技术需求和软件特质是未来成功的软件
人员都必须具备的，唯此才能够持续地在竞争愈来愈激烈的软件业中保持高度的竞争
力。
■ 了解多种程序语言
■ 熟悉更多的系统架构
■ 面向对象和UML模型技巧成为软件人员的基本要求
■ 快速学习和开发的能力
■ 精致化的开发能力
对于上述的技术和特质，许多读者会认为这本来就是正常的事项，为什么还需要在这
里再次提出？这是因为其中许多的事项由于时空因素的关系，不是有了新的意义，就
是有了更大的压力。在本章和第13章中我会分别做详细的说明。
软件人员在发展本身技能并且了解信息技术发展的趋势之时，当然也需要了解目前各
种软件平台和软件领域发展的状况，以便规划本身的发展方向。目前，如果我们以平
台作为分类的标准，便可以概略分成UNIX/Mainframe、Windows、Java以及.NET四大
平台。由于未来趋势的演进，在这些不同平台中的软件人员也会有不同的境遇和发展。
不过总体来说，UNIX/Mainframe和Windows平台的前景都属于逐渐下滑的趋势，其原
因就在于这些平台已经处于成熟、饱和或是即将由新的平台所取代。
如果仔细观察Java平台，可以发现它已经开始进入爆炸成长期。事实确实如此。Java
在历经了数年的奋斗之后，的确开始在全世界开花结果。Java除了在美国和欧洲快速
占据市场之外，在亚洲也开始快速崛起。例如Java在台湾的表现一年比一年好，不但
使用Java的人数增长了许多，Java的开发工具(例如JBuilder)也一年比一年卖得好。
JBuilder已经隐然有和Delphi/C++Builder分庭抗礼的趋势。也由于Java的势力日盛，
因此Java软件人员的身价也水涨船高。
更有趣的是.NET的发展。虽然.NET在2002年才正式推出，但是许多的分析和预测都显
示了.NET的发展将不会像Java一样需要花上6/7年才达到一定的高度，.NET的脚步将
快上许多。从上图中我们也可以看到.NET平台的趋势已经处于温和上升的状态。根据
Microsoft最新公布的信息，到目前为止，全世界已经有4千万台的PC安装了.NET的虚
拟执行环境。估计在2003年，Microsoft推出下一代的操作系统Microsoft .NET Server
之后，将有为数更多的PC安装.NET虚拟执行环境。当然这也代表了.NET的时代可能会
比我们想像中更早到来，这同样预示着.NET软件人员的需求会开始浮现。
根据Gartner Group的调查显示，以后的信息势力会由Java/.NET平分市场，最有可能
的结果是Java将会称霸中/后端以及UNIX/Linux/Mainframe市场，而.NET则可能控制
客户端、Microsoft的行动消费端，并且逐渐朝向中间件攻城略地。未来更有可能通
过Intel/AMD高阶CPU的计算能力以及Microsoft的.NET Server而在原本由UNIX控制的
低/中/高阶工作站市场取得一定的优势。
下面的分析图更是显示了四大平台之间势力消长的情形。.NET将很快取代Microsoft
原本的DNA架构而成为Windows平台下的企业系统核心技术和架构。我认为这个现象是
合理的，但是更有趣的问题是.NET何时将穿透Mainframe和Java平台呢？
看完了平台之间的竞争后，再让我们看看2002年应用程序开发种类的趋势。
应用系统分布趋势
每一位读者实际开发的应用系统种类可能都有不同。有的读者可能是开发MIS应用系
统的，有的可能在开发Web解决方案，也有读者是在开发分布式应用系统或是低阶的
系统软件、嵌入(Embedded)式软件，或者驱动程序系统。不管读者主攻哪一种信息系
统，了解整个信息产业的开发分布状况都会是很有帮助的，因为这些信息有助于信息
人员准备和规划自己的职业生涯，了解整个信息产业的走势。
下图显示了2002年信息人员开发的应用系统种类统计结果。从图中可以看出，主从架
构仍然是第1名，如果结合数据库的开发，一共拥有24.8％的占有率。同时我们也可
以看到，Web的开发几乎已经超过主从架构，估计到了2003年，Web开发将超越主从架
构，成为最流行的应用系统开发种类。
在Java和.NET企业平台愈来愈有影响力之际，未来最重要的系统种类是什么？其实答
案已经相当明显了，那绝对不会是低阶的系统种类，而是多层架构、Web/Web Service
系统、组件系统等应用。各位读者可看到了未来所需求的人才？
组件架构使用趋势
Java的EJB和Microsoft的COM+都想在企业市场竞逐，成为企业对象应用系统的核心组
件架构。但是EJB和COM+却选择了两个不同的发展方向。对于EJB，SUN只是定义出其
标准功能规格，再由各个EJB厂商根据标准EJB规范来开发EJB服务器。而COM+却是由
Microsoft定义标准规范并且自己实现。正由于EJB和COM+采取不同的策略，因此EJB
获得了较多厂商的支持，推出了许多不同的EJB服务器，但是COM+却凭借着内建于
Microsoft的操作系统而拥有较多的使用者。
目前EJB的功能规格已经发展到2.x版本，Microsoft也准备推出COM+1.5版。SUN和
Microsoft推广了许多年的EJB和COM+，到底这两个组件架构在业界被使用的状况如何？
两者是不是雷声大雨点小呢？
根据去年调查的结果显示，EJB的确已经开始在企业生根，已经有19.3％的企业在使
用EJB技术；另外有15.3％的企业准备开始使用EJB。这个趋势和Gartner Group对于
EJB的预测非常符合，估计到了2004年，有40％左右的企业会使用EJB。从这个现象来
看，EJB实在可以说是已经成功了，其实用性也获得了证明。台湾EJB的实用性正日渐
普及，许多的大型企业、ISV都已经开始使用EJB作为关键企业应用系统的核心技术，
EJB的人才需要也日渐升高。
由于COM+是内建在Microsoft的Windows的操作系统中，理所当然地其使用率应该是不
低。只是COM+的前身COM/MTS等由于其延展性受人质疑，因此使用COM/MTS作为企业核
心技术的并不多，大多数是使用COM作为客户端的可重复使用软件组件。但是COM+推
出之后，由于其执行效率和延展性都大幅精进，再加上Microsoft在TPCC上显示的惊
人效率也都是使用COM+组件，因此COM+逐渐打入企业市场，成为Windows平台核心的
组件架构，被许多企业的应用系统所采用。
根据2002年调查结果显示，COM+使用率已经超过了34.5％，同时还有13.9％的企业有
兴趣采用。Microsoft在努力推广COM技术数年之后终于有了一定的成果。不过Microsoft
现在面临的挑战是.NET对于COM+的影响，由于Microsoft的平台正从原生窗口转换到
.NET的阶段，许多人也开始困惑起来，.NET中的组件架构仍然是COM+？还是有其他的
组件架构来代替？如果.NET仍然要使用COM+作为组件架构，那么纯.NET的开发工具又
无法开发原生的COM+组件，如此一来在.NET中COM+不就又不是First Class的组件架
构了吗？如果纯粹使用.NET的组件，那么纯.NET组件的延展性尚未经过实际的验证，
也不提供Two-Phase Commit和分布式Commit的能力，又如何能用来作为企业应用系统
的核心组件呢？看来Microsoft在这方面还有很长的一段路要走。
CORBA呢？在EJB/COM+的强攻之下，CORBA似乎失去了原有的光彩，但是不可否认的是，
CORBA仍然是架构/服务最完整、经过最长时间验证的组件模型。根据2002年的调查结
果显示，CORBA仍然有相当数量的使用率，而且未来也仍然保有稳定的使用率，可见
CORBA仍然受到相当的欢迎。
随着Microsoft .NET的出现和成长，CORBA似乎反而可以在.NET平台有更大的潜力，
相关的讨论请参考下一章"EJB对抗CORBA？有趣的假设"。
信息技术到了现在的阶段可以说是"平台逐渐整合，但是程序语言则呈现百家争鸣的
情形"。再加上UML等Modeling的技术和软件愈来愈贴近软件人员，数据库和SQL技术
更已经成为软件人员最基本的技能，因此软件人员本身也自然朝向身通18般武艺的阶
段。只是好的软件人员耍起来虎虎生风，而一般的软件人员在愈学愈多的情形下则一
无精通，到最后反而是害了自己。
回到前面的问题，目前的信息技术的确是朝着多元化的方向发展。太多的技术、产品、
架构、程序语言、数据库、客户端种类等技术，造成了许多软件人员的困惑和焦虑，
这是很自然的现象。但是另一方面，平台在收敛，系统开发正走向整合阶段，对软件
人员的要求也走向整合。因此，除了焦虑之外，软件人员在了解了软件趋势之后，更
应该提出疑问：
你准备好了吗？
快速的开发周期
上大学时，要学习系统分析和设计(System Analysis and Design)课程，正好看到一
个统计，说程序员一天只写一行有效的程序代码，当时我简直乐坏了。心想一定要进
入信息行业，又有高薪又有地位，更重要的是工作如此轻松，一天写一行代码，闭着
眼睛都可以做到。没有想到，在真正进入了信息行业之后，情形却大为不同。不但工
作繁重，每日更需撰写成百上千行的程序代码，这哪里是一天写一行的日子？不禁心
生感叹，自己似乎入错了行。
所有的读者都可以感觉到，现在系统开发的时程要求得愈来愈快。我记得5/6年前，
系统和项目开发的速度还是1年到1年半左右，到了3/4年前已经缩短成10个月左右，
在Internet/Intranet快速兴起之后，许多系统和项目甚至缩短到了3个月就要推出的
迫人时限。信息机构的调查显示，系统和项目的开发时程将持续地缩短，到了2012年
居然只有一天的时程，这种超高标准的要求可能会吓坏许多的软件人员。不管这份调
查的数据是否100％正确，但是从这份信息调查趋势以及我本身的经验来看，愈来愈
短的开发时程却是不争的事实。
面对愈来愈短的开发时程，软件人员应该如何适应？这是许多人面临的困扰。其实许
多的程序语言、开发工具、软件工程都强调帮助软件人员提高生产力，以适应快速开
发的要求，只是随着时程的要求愈来愈高，许多传统的程序语言和开发工具都已经呈
现力不从心的现象。既然如此，那解决问题的方案是什么呢？
数年前，业界对于软件开发的速度要求愈来愈快，这造成了软件品质的下降。许多软
件在完善率尚未达到一定的水准下便仓促推出，造成了更多的问题，因此软件业曾经
被许多人讥笑为"不可靠行业"。为了改善这个现象，许多软件工程技术相继出现，以
求提高软件品质。其中最为突出的是以面向对象的各种软件工程，强调软件IC、可重
复使用的软件组件为特质，以加快软件开发的速度并且提高软件品质。面向对象的大
旗造就了3位面向对象大师，也让UML等模型工程独领风骚，进而让Rational公司成为
近年来最重要的软件公司之一。不过几年下来，UML对于软件开发的贡献一直受到争
议，许多软件人员对于UML过于复杂的流程和过多的UML图形产生怀疑，因此前一阵子
又兴起了Extreme Programming的热潮，强调轻便、动态、快速开发的特性。其实这
个现象正反映了软件业界对于开发"速度"的要求已经超越了过份强调软件工程流程的
重要性。现在的信息业界需要的是"灵活的"开发速度。
右边的图片明确显示了从2002年下半年起，许多企业和软件公司对于软件开发特性的
要求，其中列为最重要的特质就是"灵活性"，接着仍然是强调速度的Extreme
Programming的特质。其实，这些对于软件开发的要求也正回应了上一张图形显示的
对于开发速度的要求。
我认为UML/RUP和Extreme Programming/Agile Development之间并没有冲突，反而是
相辅相成的。对于大型、复杂的系统开发，UML/RUP仍然是目前为止最好的方法之一，
只是需要适当的修正，不要过份强调所有的形式流程。而Extreme Programming/Agile
Development则特别适合中/小型系统，需要快速反应时间的开发要求。
既然快速开发已经成为现在最重要的软件开发要素之一，那传统软件人员应该如何适
应呢？其实这个原理也不难了解，答案就隐含在上图中Developer-Centric包含的意
义。想想看，现在的许多企业是如何增加效率的呢？答案之一就是组织扁平化，尽量
减少不必要的重复浪费。软件开发也是一样，软件工具应该尽量以开发人员为中心，
让开发人员使用较少的循环能够完成更多的开发阶段，并且提供更可靠的软件。例如，
新一代的开发工具允许开发人员在一个开发环境中，同分析/设计人员以UML的模型来
沟通，并且能够在一个开发环境中撰写程序代码，以可视化方式检视程序代码的关系
和可靠度，能够在相同的开发环境中进行单元测试、压力测试、负载测试，并且和测
试人员合作。另外，在这个开发环境中也能够和开发团队共同进行项目管理和版本管
理的工作。如此一来，开发人员可以在较短的时程内提供更高的生产力，缩减开发循
环。当然，这意味着以后软件人员必须知道得更多、要求也更高，但是，这的确可以
让开发人员更有效率，并且增加整个团队开发的生产力。
面对要求愈来愈高的动态开发时程，身为专业软件人员的你：
可准备好了吗？
程序语言的战争
从程序语言的发展史来看，数年前似乎就有统一的趋势。在商业应用上COBOL几乎是
事实标准，在科学计算上Fortran有不可取代的地位，而C/C++则几乎垄断了大部分其
他的应用。但是随着Internet/Intranet以及RAD工具的兴起，这个由数个主流语言掌
握的局面很快被打破了。特别是在各种脚本语言(Scripting Language)和Java在Internet
应用上逐渐取得了优势之后，各种新的程序语言纷至沓来，让人眼花缭乱，不知如何
选择。程序语言战场在寂静了数年之后却突然陷入了前所未有的热战之中。
其实，各种程序语言的不断出现，反映的就是以往的程序语言已经不足使用或是不适
合使用在特定的应用中，因此才需要新的程序语言来解决问题。新的程序语言代表了
信息应用的多样化，而以往由COBOL、Fortran、C/C++主掌的情势也被快速地打破。
如今的软件开发人员可能必须同时熟悉数种程序语言，并且在不同的应用中选择使用
最适当的程序语言。
以Web应用系统的开发为例，看看目前这个最流行、最重要的应用系统是由什么程序
语言开发的。在台湾地区，不可否认的是ASP绝对是最多人使用的解决方案，这是由
于台湾大部分的Web应用都属于中、小型系统，而且Web应用系统分布的区域并不算广
大，因此ASP就足够满足大多数的需求，软件人员选择的标准是好用、开发迅速的程
序语言。
但是，对于美国或是大陆这种幅员广大、并且拥有许多大型系统的应用而言，很可能
和台湾地区的情况大不相同。那么，到底世界上的软件人员是使用什么程序语言来开
发Web应用系统呢？对于这个问题的答案，我很有兴趣，因为可以拓宽自己的视野。
下图显示的是信息机构对美国软件人员调查的结果，从图中可以发现使用最高的居然
是XML，而不是ASP或JSP。不过XML、ASP和JSP这3者加起来占据了3分之一强，可见这
3种程序语言是Web应用开发的主流。另外值得注意的是，虽然PHP最近声势不断地增
长、并且拥有Open Source的优势，但是居然只占有4％的使用率。PHP的成长率很惊
人，这在稍后也会说明，不过PHP要想在Web开发领域占有显著的地位，仍然需要多多
努力。
除了Web的开发之外，如果不注重开发工具的区别而纯以程序语言的角度来看，下图
显示的就是目前针对程序语言所做的调查统计结果，Java、Visual Basic、C/C++和
C#是目前4大主流程序语言。不过下图中的C#数字是指C#在2003年的表现，而不是在
2002年的情形。
图中的调查结果，显然和我国台湾地区以及大陆的情形有些出入。在台湾，Java正快
速爬升，C/C++的影响力则持续下滑，而最大使用的程序语言应该就是Visual Basic
和Object Pascal了。台湾地区的情形和大陆稍有不同，目前在大陆Java也是快速地
兴起，不过尚未形成最有影响力的语言之地位，反而是C/C++仍然为大陆目前最有影
响力的程序语言，Object Pascal、Java和Visual Basic则紧迫在后。根据CSDN网站
统计的结果，目前各程序语言讨论的文章数分别如表所示。
从右边图形和数字，我们可以了解在大陆使用C/C++语言的人数实在是众多，而Java
已经超过了Visual Basic。不过未来的发展情形则更令人好奇，因为在全世界的C/C++
都开始逐渐走下坡之际，C/C++在大陆的市场会不会也发生类似的现象呢？Visual Basic
和PowerBuilder会不会持续下滑？Java何时会成为霸主？C#又何时会迎头赶上？这些
问题都非常值得观察，因为这不但影响了各程序语言之间势力的消长，也代表着软件
工作市场的需求和变化。
有趣的是，在Windows和.NET平台上，程序语言正以前所未有的生气蓬勃发展，而且
不同的程序语言间互相激荡、相互影响，再产生新的程序语言或是在原有的程序语言
中加入新的机制以符合新的需求。但是在Java平台，却几乎只有Java语言，没有其他
的选择。那么读者是喜欢单一程序语言的单纯，还是喜欢多种语言产生的灿烂火花呢？
我个人是比较喜欢多种语言的，因为我认为，我们可以通过欣赏不同程序语言的设计
精神和思想来吸收更多的知识和技术，通过不同程序语言彼此竞争的结果，可以嗅出
未来程序语言的发展方向，这大概也是因为我从大学时就特别喜欢程序语言和编译器
课程的结果吧。
知己知彼，百战百胜
就让我们以EJB服务器市场这个实际的竞争范例来看看信息产业是如何竞争和演化的
吧。三四年前，当EJB市场开始成长时，许多软件厂商相继投入这个潜力十足的市场。
当时，所有EJB厂商竞争的基准大概都是符合EJB规范、使用最新JDK标准以及执行效
率最良好的EJB服务器。当时竞争的EJB服务器可以用满山满谷来形容，为什么呢？因
为在这个阶段纯粹是以技术为决胜点，这个门槛并不高，拥有技术的软件人才多得是。
因此，这个阶段中有眼光和智慧的厂商便了解到，光凭EJB服务器引擎是无法作为胜
出的要件的，必须想办法增加竞争门槛以阻绝竞争对手持续逼近，或是增加"软件服
务"以提供竞争对手没有的功能。
到了EJB服务器竞争的第2阶段，逐渐胜出的EJB厂商便开始为EJB服务器加入各种服务，
其中一类是以增加商业应用服务为主，例如Portal Service、ERP Service等。而另
外一类则是以技术服务为主，例如分布式交易服务、安全服务等。由于这些软件服务
的加入，在EJB服务器竞争的第2阶段便逐渐产生了EJB服务器的领先群，许多其他的
EJB服务器厂商在眼看竞争无望之下自然地退出了市场，HP就是一个例子。
现在EJB服务器市场又进入了最后厮杀的阶段，因为在领先群中的厂商大都提供了类
似的服务。那么接下来要如何竞争呢？IBM很快就看到了关键点，那就是为WebSphere
加入整合开发平台的能力。通过并购Rational取得Modeling工具和技术，IBM可结合
原有的Java开发工具为WebSphere形成一个关键开发平台，同时吸引企业使用者以及
开发人员为WebSphere形成的企业平台开发更多的客制化服务，以便为WebSphere形成
势力强大的专属力量。这是WebSphere最大竞争对手WebLogic目前没有的优势。
从EJB服务器竞争的过程来看，致胜的关键便是软件人员是否能够看到别人看不到的
优势、并提供额外的服务。对于软件人员的发展，道理也是同样。大部分的软件人员
都只注重在特定的开发工具或是程序语言中精进，但似乎都是随着别人的脚步而前进，
少数软件精英除了在信息技术领域有高人一等的修为外，真正胜出的却是能够为自己
增加附加价值、提供创造力的能力。就像JBuilder的Chief Scientist--Blake Stone，
为什么他能够在年纪轻轻的情形下成为领导者？许多资历、年纪都比Blake Stone
多的研发人员反而只能当工程师呢？很简单，因为Blake Stone更早地看到了JBuilder
的发展趋势和竞争策略，掌握了Java开发工具发展的动脉，能够为JBuilder开发团队
提供更多的价值，再加上坚强的技术实力，终于成为家喻户晓的Java天才。
我一直认为任何软件技术终将被大众所熟知和掌握，就像数年前的主从架构一样，因
此光凭借技术并不能让人领先多久。反而是通过平日不断培养的眼光和趋势、再加上
专业的技术才能够让软件人员保持在领先群中，并且掌握软件趋势的动脉。拥有这种
特质的软件人员能够不时的提供服务，不时地为团队提供持续的创新力，自然也就能
够百战百胜了。
结论
人类对于新事物的害怕，通常都是由于对新事物的无知所引起。同样，软件人员对于
未来的困惑和焦虑则来自不知如何是好，这也是对于未来趋势发展的无知所引起。本
节中，我们通过分析、观察和统计了解了以往、现在和未来软件趋势的发展，当事实
的走向豁然开朗之后，困惑和焦虑不再重要，软件人员反而应该反躬自省地自问：面
对未来，我们准备好了没有？
不管Java和.NET两大平台之间的战争如何，不管哪一个软件组件或是程序语言会获得
最后的胜利，世界对于软件系统快速开发的要求不会因为那一方胜出而改变，软件人
员必须准备好面对这个趋势。想想，JBuilder以每半年一个新版本出现，Java JDK和
.NET也几乎以1年半之间推出两个版本的速度在彼此争战之中，连传统的开发工具现
在也几乎以一年一个版本的速度出现。更夸张的是，Internet/Intranet的技术现在
几乎每3个月就有一番新的面貌，开发人员应该如何自处呢？
机会可能会降临在每一个人的身上，但是只有时时准备好的人才能够把握住机会，不
让它从手缝中溜走。
^v^v^v^v^v^v^v^v^v
第十一章 EJB对抗CORBA？有趣的假设
"组件模型的两大巨头终将对决？"
什么是.NET？我们可以从各种技术角度探讨.NET，NET的技术书籍也可以撰写成几十
本、甚至是上百本。但是Microsoft提倡.NET，最重要的目的是提供一个足以和Java
平台对抗的"企业平台"(Enterprise Platform)。Microsoft希望企业能够使用.NET作
为企业应用系统的核心平台，根据这个企业核心平台再开发各种应用系统，连接新式
的移动设备(Mobile Device)，形成企业应用系统需要的完整信息供应链，提供类似
目前Java拥有的企业业务。Microsoft希望通过.NET打入企业市场的企图是不言而喻
的。
为什么Microsoft急于打入企业市场呢？主要因为企业市场是获利最为丰富的市场，
也是Microsoft长久以来最想进入的市场。另外，Microsoft不希望Java独占企业市场、
进而产生对Microsoft的威胁，这是第二个关键因素。其次更重要的原因是，Microsoft
在客户端几乎已达饱和，继续成长的空间有限，需要另外能够持续成长的市场，而企
业市场、消费端市场、通讯市场以及游戏市场就是Microsoft注重的目标了。
Microsoft要想打入企业市场，需要面对的是表现愈来愈好的J2EE架构。目前J2EE已
经被愈来愈多的大型企业用作企业核心的信息技术。根据Gartner Group的调查，EJB
的架构将逐年增加，到了2003年将会拥有超过40％的使用率。这代表EJB将成为企业
应用系统的核心组件架构，更多的企业系统将使用J2EE来建制。
这些现象在大型的信息业界反映得非常真实和明显，例如台湾的台积电(TSMC)、联电
(UMC)和友达光电等都已经在使用Java和J2EE作为新一代信息系统开发的核心技术。
再看看目前EJB服务器的两大领导厂商产品--BEA的WebLogic以及IBM的WebSphere。
WebLogic和WebSphere除了已经成为许多企业的核心J2EE服务器、提供企业开发应用
系统的基石之外，还慢慢形成了企业应用系统的解决方案中心，并从其中衍生出许多
新的软件需求和应用。例如许多的Portal系统、ERP、CRM或Web Service应用都围绕
在这两个J2EE服务器的外部进行增值的应用。这种现象已经开始形成非常巨大的力量，
让EJB服务器的竞争从EJB核心服务器演变到EJB解决方案的地步，宛如一个黑洞在不断
地吸引新的应用和力量进入、使用这个架构。这种软件群聚的效应正是企业级信息技
术应该形成的现象，因为唯有如此，才能够让影响力不断扩大。当初Microsoft的
Windows就是这样，吸引了全世界程序员为Windows开发应用软件，以Microsoft Windows
为应用的核心，这才造就了Windows成为全世界客户端操作系统的霸主。
由此可见，一个核心软件技术对于信息应用的重要性。当初Microsoft在Windows上力
推COM/COM+组件模型，希望它们成为Windows上的核心组件技术，提供企业在Windows
平台上开发企业应用系统的解决方案。其实以效率来说，COM+的确是不错的。根据许
多的测试以及TPCC上公布的结果来看，COM+的执行效率几乎是最好的。而前段时间The
ServerSide上公布的EJB对COM+的评比更是闹得满城风雨。Java业界仍然不肯承认COM+
比EJB来得有效率，但是以目前的数据来看，在Windows上EJB的确远远比不上COM+。
在Microsoft多年的推展之后，COM/COM+的确也有了不错的使用结果。根据2002年北
美关于COM+的信息调查显示，使用COM+技术的人占了34.3％，而且还有9％的人回答
将会采用COM+。虽然COM+在执行效率方面表现很好，但不可否认的是COM+只能在Windows
平台使用，而且在Internet应用中使用不便，延展性也不若EJB，这都是COM+致命的
缺点。
.NET核心组件技术
既然Microsoft希望.NET成为企业应用的平台，那.NET需要提供什么呢？除了开发工
具之外，.NET最重要的便是提供一个类似J2EE架构的软件解决方案，以吸引软件人员
为.NET开发企业级的应用系统，帮助.NET打入企业市场和Java平台竞争。
那现在的.NET中有什么类似J2EE架构的技术呢？从下图我们可以清楚地看到，Microsoft
在.NET中正逐渐建立起同SUN Java平台竞争的技术核心。Microsoft和SUN的虚拟竞争
平台现在几乎非常类似，不过，目前的Java在组件技术的领域远远超过了Microsoft
提供的解决方案。
Microsoft在.NET中的组件技术是以.NET组件配合COM+为主。COM+在.NET中转为操作
系统的核心服务，提供事务管理(Transaction Management)的功能，而.NET组件则可
以同时扮演.NET中的可视化组件(Visual Component)、数据感知组件(Data-Aware
Component)以及中间件(Middleware Component)。然而使用.NET组件作为.NET平台中
间件有许多问题。首先是.NET组件必须依靠COM+组件提供分布式事务管理能力；另外，
.NET组件目前也没有像EJB一样的Fail-Over和Load-Balancing能力，这在企业级的应用
中是明显不足的。
此外，.NET组件必须和COM+一起搭配使用，这意味着程序员必须开发COM+组件，而.
NET的原生工具无法开发COM+组件，程序员还是必须使用原生的Windows开发工具。此
外，一旦使用了COM+，代表此.NET应用系统无法移植到其他的平台。如果Microsoft
把.NET移植到Linux或是FreeBSD上，那使用COM+组件的.NET应用系统将无法移植到这
些平台之中。
那么，Microsoft是不是需要一个新的、能在.NET平台使用的组件架构呢？就我的眼
光来看，如果Microsoft希望把.NET平台定位在企业系统同J2EE竞争，那的确是需要
这种技术，但这对于Microsoft是有一点困难的。首先，Microsoft正忙于在一二年内
达到Java平台花了七八年的成果，正忙于开发.NET本身、.NET开发工具、.NET下的数
据库，并且把所有的Microsoft Server应用程序移植到.NET之下，可能一时无法投入
太多的资源来开发一个全新的企业级的组件架构。
另外，再看看Microsoft建立组件架构的历史就可以了解到，在这方面Microsoft的确
不太在行。期望Microsoft在短时间内在.NET平台定义类似EJB的企业组件架构的规格
并且将其实现出来，似乎是不太容易的事情。
组件技术 结果
16位VBX 失败
32位VBX 失败
OLE 失败
COM 尚可
ActiveX 失败
MTS 失败
COM+ 不错
.NET组件 不适合使用在企业级应用中
既然新创.NET下的企业组件架构不是短时间内可以完成的，那是不是代表着.NET在这
方面已经无法和J2EE竞争而提早出局呢？其实并不一定，因为如果无法快速开发一个
新的组件架构，那为什么不使用已经存在且已经验证是适合企业应用的组件架构呢？
让我们想想.NET的特性和需求是什么，就可以推知什么组件架构最适合在.NET平台下
成为企业级的组件架构了。
什么组件架构已经使用过很长的一段时间，且经过了市场的验证呢？
→ CORBA、EJB和COM+
什么组件架构可以跨平台？
→ CORBA和EJB
什么组件架构允许多种语言开发和使用？
→ CORBA
从上面的问题中，我们已经看到答案是呼之欲出了。更关键的是上面的第3个问题。
由于.NET是一个语言中立的平台，程序员可以使用任何语言来开发.NET应用程序，因
此在.NET平台的组件架构必须能够让各种不同的程序语言来开发和使用，而不像EJB
一样只能使用Java语言。对比一下，CORBA正好符合语言中立的要求。此外CORBA是一
个跨平台的组件架构，可以随着.NET移植到各种平台。因此从各方面来看，CORBA实
在非常适合使用在.NET之中并成为.NET的核心组件架构。
CORBA和EJB
CORBA已经在企业应用系统使用了很长时间，是一个架构成熟、经过了市场严格考验
的组件技术。在CORBA之后的许多组件架构其实也都学习了CORBA。例如J2EE中的EJB
规格可以使用CORBA来实现，在EJB 2.0之后也要求EJB服务器必须和CORBA兼容，由此
可见CORBA组件架构的重要性和成熟性。目前，CORBA仍然是一个在持续发展中的组件
规格，OMG也持续为CORBA定义更为完整的核心和服务规格。
CORBA使用的Stub/Proxy以及组件服务架构深深地影响了COM+和EJB的实现架构，以致
COM+和EJB组件架构和CORBA都有许多神似的地方。
由于CORBA几乎是其他组件架构的始祖，因此CORBA绝对有能力、有份量和EJB分庭抗
礼。如果.NET能够在其平台上以CORBA作为核心组件架构，那么.NET就可以提供同J2EE
一样好的企业应用架构。虽然许多人会质疑在PC上执行企业应用系统会不会力量不够？
但是，随着64位的CPU(Intel和AMD)即将推出，Microsoft也准备推出64位的操作系统。
在.NET虚拟执行环境的保护下，如果再加上安全强固的CORBA，那么.NET的确可以提供
相当有竞争力的企业执行平台，与J2EE在中/低阶的企业应用中竞争。如此一来，
Java/J2EE就不再拥有企业应用中的绝对优势了。
既然CORBA对于Microsoft .NET平台的企业运算有这么大的助力，那么CORBA组件架构
在.NET平台上将以什么样的架构来提供服务呢？
CORBA For .NET
CORBA要如何在.NET平台上提供企业级的服务呢？由于CORBA使用IIOP通讯协议作为调
用CORBA服务的接口，因此传统的CORBA引擎(例如Borland的VisiBroker)，应该会为
CORBA伺服端和客户端产生可连接的DLL或是函数库，这些DLL和函数库就负责让客户
端通过IIOP调用伺服端的CORBA服务器。因此CORBA即使是执行在.NET平台中，也是使
用IIOP作为调用的通讯协议，如右图所示。
不过，在.NET下Microsoft是使用.NET Remoting机制作为远程和分布式沟通的通讯协
议。那么，.NET的CORBA开发工具要如何结合.NET的Remoting机制、并且允许.NET下
各种不同的语言通过IIOP调用远程的CORBA服务呢？
其实，这同在Windows下提供原生窗口开发工具开发CORBA应用系统几乎是一样的，只
是在.NET下CORBA引擎必须进行一些额外的工作以让.NET的开发工具和应用程序能够
使用CORBA技术。
首先，.NET下的CORBA开发工具必须能够提供.NET下主流程序语言的支持，这代表CORBA
For .NET必须为每一种程序语言产生客户端的CORBA.NET Stub和伺服端的CORBA.NET
Proxy。其次，为了和.NET Remoting机制结合在一起并提供IIOP的能力，CORBA For
.NET必须产生一个Adapter和.NET RemotJng作为沟通的机制，.NET Remoting通过这
个Adapter再调用最底层的CORBA For .NET引擎，CORBA For .NET引擎再把.NET Remoting
的调用惯例转换为IIOP通讯协议。经由Adapter和CORBA For .NET引擎的转换之后，
就可以调用远程的CORBA服务和CORBA服务器，甚至通过RMI Over IIOP调用到远程的
EJB服务器，如下所示：
上面说明的架构还是比较详细的。由于在.NET下各种程序语言都会被.NET的编译器转
换为.NET的IL，因此CORBA For .NET工具可以产生一个IL型态的客户端CORBA.NET Stub。
如此一来，不管程序员使用的程序语言是什么，都可以保证能够通过这个CORBA.NET
Stub来调用远程的CORBA服务。这个架构其实比以前Windows下的CORBA开发工具更容
易，因为在Windows下，CORBA厂商还必须为不同的程序语言产生不同程序语言的客户
端CORBA Stubs。现在.NET下CORBA厂商反而因为.NET几的特性而更轻松和一致了。
一旦CORBA厂商能够在.NET下实现CORBA For .NET，那么不但可以让.NET的程序员开
发真正企业级的.NET应用系统，更由于CORBA和EJB是兼容的，因此.NET下的CORBA服
务器也能够通过RMI Over IIOP调用和整合EJB服务器，提供.NET和J2EE无缝整合的能
力，并且允许使用者的应用系统能够从.NET平台顺利地移转到J2EE平台，如下所示。
更何况，现在许多的EJB服务器还能够像管理EJB对象一样地管理CORBA对象，这意味
着执行在Mainframe或是UNIX/Linux的EJB服务器能够管理和整合执行在.NET中的CORBA
对象或是CORBA服务。.NET有了CORBA这个解决方案之后，终于有了进入可提供企业级
应用程序架构的能力了。
巨人终将对决？
CORBA的复杂度使其一直未能被广大的程序员所接受，现在的CORBA本身已经非常安全
强固，而且经过了十几年企业市场的考验(即使是EJB也不过在企业市场才经历了2个
版本的洗礼)，CORBA的开发厂商应该已经清楚，CORBA不被大多数开发人员接受的原
因并不是CORBA不够好，而是CORBA太复杂。因此这些开发厂商应该舍弃CORBA中鲜为
人用的服务，先提供一个完整的CORBA引擎以及企业应用最重要的两个服务--事务管
理服务(Transaction Service)和安全服务(Security Service)。更进一步的是，如
果CORBA厂商能够在客户端提供.NET的组件来封装比较复杂的CORBA调用和存取机制，
并且结合数据存取的能力，那么，.NET下的程序员将能够以非常快的速度学习和使用
CORBA组件架构。如此一来，CORBA将有机会在.NET平台中大展身手，有机会成为.NET
平台中最有潜力的组件架构，也将有机会让CORBA一吐闷气，让世人了解CORBA的价值。
"EJB和CORBA两大巨人终将对决"？不，更正确的说法应该是J2EE/EJB终于找到了可敬
的对手--.NET/CORBA，而CORBA和EJB也将进入"既竞争又合作"的时代，当然前提是有
厂商推出CORBA For .NET的软件产品。
^v^v^v^v^v^v^v^v^v
第十二章 回到C/C++的王国
"让我们重返荣耀之都吧！"
当年Windows平台C/C++开发工具四大天王一战，在Microsoft取得了市场的主导力量
之后，C/C++开发工具的市场和竞争反而缓慢了下来，Windows上C/C++开发工具的进
步也开始牛步化。VC++一连两三个版本的进度幅度并不大，除了稍后推出的ATL还有
新意和技术革新，VC++编译器除了在C/C++语言上更趋近于标准之外，MFC本身几乎已
经没有什么大的进步了。在Watcom和Symantec退出市场之后，VC++也顺利地接受了
Watcom和Symantec的市场。而Borland C/C++虽然也损失了大量的市场，并且失去了
C/C++的王座，但是在数年后，Borland推出C/C++Builder，以C/C++ RAD工具、以及
更符合ANSI C/C++标准和VC++进行市场的区隔，也慢慢地收复了一些失地。虽然
Borland C/C++工具系列已经无法像以前一样是市场第一的C/C++开发工具，但是
Borland在Windows的C/C++开发工具市场仍然占有30％强的市场份额。
C/C++开发工具在C/C++ Framework一战之后，开发的重点却似乎模糊了起来。由于VC
++没有强劲的竞争，因此整个的发展速度缓慢下来。不过C/C++技术在C/C++语言、函
数库(Library)和通用Framework方面却快速地如雨后春笋般兴起。特别是在C/C++语
言的标准化更为完善、以及Template的功能被C++ Standards Committee接受而且被
广泛地由C/C++编译器支持之后，各种支持和使用Template的Framework、C/C++函数
库也快速地占据了C/C++开发者的心灵，成为有力的程序技巧之一。在Java日益兴盛、
开始威胁C/C++的市场时，反而激发了C/C++语言前所未有的高度发展。不过，目前
C/C++开发工具以及C/C++编译器是否跟上了C/C++这么快速的发展脚步呢？在本章继
续讨论之前，也许应该让我们先看看目前C/C++市场的现况。
日不落帝国
曾几何时，C/C++是征服全世界的语言之一。在数年前C/C++语言全盛的时期，我记得
几乎所有的应用系统都选择使用C/C++来编写，如从系统程序、公用程序、软件包到
项目开发，因此也造就了C/C++开发工具横扫软件销售市场的现象。但是随着RAD工具
和Java的逐渐受欢迎，让C/C++开始从许多的市场撤退。特别是当Java兴起之后便快
速取代了以往C/C++在跨平台语言的主导角色，让C/C++语言在这个市场受到Java最大
的威胁。不过，C/C++仍然在许多方面的应用不可否认地具有绝对的优势，特别是在
需要高度执行效率的应用系统中，例如驱动程序和低阶的系统程序等。那么C/C++目
前的市场到底有多少？有没有像两、三年前许多信息机构预测的那样，Java将会大幅
抢走C/C++的市场、并且吸引大量的C/C++程序员呢？让我们以实际的数据来看看目前
的状态。
右图是全世界专业信息机构对于C/C++开发工具市场规模和使用状况的调查结果。从
这个结果图形中我们可以得知几个非常重要的C/C++信息：
首先请读者注意的是，就整体来说C/C++开发工具的市场的确是处于小幅的下降趋势
之中，根据Gartner Group的调查，C/C++市场是以5％的幅度下降，而根据Evans Data
Survey的调查，C/C++市场则是以3％的幅度下降。不过稍后我们会说明，C/C++开发
工具是在哪些平台和应用中产生变化。
另外一个值得注意的地方，是C/C++语言主要是用于三个应用领域之中，分别是客户
端、伺服端和维护现有的应用程序。从图中我们也可以发现C/C++语言被使用的转变
状态，在工业应用方面，C/C++开发工具仍然有很大的成长，这当然是因为C/C++语言
被广泛用于驱动程序的开发，例如显示卡驱动程序、网卡驱动程序等。此外C/C++语
言也被用于移动设备的开发，例如Nokia为了和Microsoft的Smart Phone对抗而推出
的Symbian手机系统。当然，在操作系统、系统程序和低阶核心应用方面C/C++语言仍
然有着不可取代的地位。
但是，C/C++在其他方面的应用的确是在下降之中，特别是在企业的应用系统方面。
例如目前在大型项目、软件包、MIS和企业内部的应用系统中，使用C/C++语言的比例
的确在下降。其中主要的原因是C/C++语言本身的难度较高，因此生产力也不如其他
语言和开发工具。加上较易使用的RAD工具和Java出现之后，C/C++语言在这些领域的
影响力是大不如前的。这个现象也非常契合台湾地区目前的状况，在前几年C/C++兴
盛的阶段，几乎大部分的软件包厂商和SI以及系统厂商的确都是以C/C++开发工具为
第一选择。不过由于C/C++需要的人力素质较高，而且生产力无法大幅提高，因此在
目前软件包和项目的开发大多都由Delphi、VB、PowerBuilder以及Java所瓜分。
至于C/C++开发工具使用的操作系统分配状况，则可以由右面的调查结果来说明。
从图中我们可以发现，UNIX/Linux操作系统平台仍然是占了最大的使用平台，这当然
是由于UNIX/Lmux本身就是使用C/C++语言开发的。而且在UNIX/Linux平台我们可以发
现，C/C++开发工具的规模仍然在成长，可达成10％左右的年成长幅度。由此可知，
虽然Java现在已经入侵UNIX/Linux平台，但是对于C/C++的影响仍然不太显著。
C/C++开发工具第二个最大的平台就是Windows平台了，虽然现在Windows平台是开发
工具百花齐放的状态，但是不可否认的是，C/C++仍然是Windows最重要的数个语言之
一，因为122 Million到137 Million的市场规模是相当大的。而Windows平台的C/C++
开发工具的成长虽然在为数众多的开发工具瓜分之下，仍可达到12％的成长率。这代
表C/C++语言即使是在Java强力竞争之下仍然拥有一定的成长量。由于Windows平台下
的C/C++和Java开发工具是处于同时成长的情形，因此，这可能表示在Windows平台下
许多的程序员应该是同时使用了C/C++和Java开发工具。
至于其他平台的C/C++开发工具则呈现下降的趋势，而且是处于快速下降的情形，这
也可以解释为什么Java在Mainframe和OS/400等大型专属平台成长快速的情形。由此
可见，在这些专属市场中C/C++语言的确是受到Java很大的影响。
除了C/C++语言本身之外，再让我们观察一下目前主流语言应用的现况，通过观察不
同语言之间势力消长的情况，我们也可以了解其他语言对于C/C++语言的影响。右图
即显示了信息机构对于目前几个主流语言之间成长和下降的预估。
从图中我们可以看到，几乎所有的传统语言例如VB、C/C++和COBOL等都呈现下滑的趋
势，相同的现象当然也在第2级的主流语言例如Object Pascal和PowerBuilder等中看
到，但是新一代的虚拟语言却呈现了对比的情形而大幅上升和成长，表示使用这些新
语言的程序员人口正在快速的兴起之中，例如SUN的Java和Microsoft的C#，而Java快
速兴起也可以解释为什么Borland的JBuilder现在已经是Borland最大收入来源的开发
工具。
看完了C/C++整体市场的趋势之后，C/C++语言目前在程序员人口中使用的情形到底是
如何呢？下图是2002年针对美国程序员调查的结果，从这个结果中我们已经可以看到，
在所有调查的人数中使用C/C++的程序员占了45.6％的比率，但是只使用C/C++单一语
言的比率只有3％，可见，现在大部分的C/C++程序员应该已经开始同时使用两种以上
的语言。
而第二幅图则是针对美国程序员对于未来计划使用C/C++语言的调查结果，从图中可
以证明前面图形和分析的结果，C/C++语言的确是以3％到5％的速度在衰退之中，也
有愈来愈多的C/C++程序员开始使用多种语言来进行开发的工作，当然C/C++程序员选
择的最多语言就是Java和C#了。
在"令人焦虑的时代"一章中我们已经讨论了Java语言目前使用的状况以及未来的发展。
从其中我们了解了Java虽然快速地兴盛，但是也看到了Java似乎已经在美国进入成熟
期，开始出现稳定的状态并且有小幅的衰退。既然C/C++和Java这两个拥有共同基因
的语言都处于稳定或是小幅衰退的情况，那么流失的程序员到底到哪里去了呢？当然
答案很明显，这些流失的程序员是转到拥有相同基因的C#语言阵营了。
虽然Microsoft的Visual Studio.NET是在2002年的2月才正式推出，但是C#的编译器
和相关的工具早已在Beta阶段便为许多程序员所使用，因此在2002年便已经吸引了一
些程序员使用，而这些第1波使用C#的程序师大都是从C/C++和Java语言转换跑道而来
的。右图是C#语言在2002年使用的状况调查，C#在不到1年的时间便吸引了美国14.6％
的程序员人口使用是相当惊人的表现。
那么未来呢？C#还能够稳健地成长吗？因为唯有稳健成长的语言才能够有机会成为主
流的语言。右图便是对于2003年C#语言使用状况的评估，从这些数据我们可以看到，
C#语言果然将以稳健的脚步成长，每年以将近10％的速度发展，而C#如果持续地照这
样的速度发展下去，那么C#将在4年之内达成Java花了七八年才达成的现状。当然，
C#这种成长趋势也暗示了Microsoft的.NET将在不久的时间内对于Java平台产生重大
的影响。
对于C/C++、Java和C#这三个拥有类似基因的语言，如果我们把它们的发展放在一起
比较的话，会发现目前C/C++和Java语言正处于激烈竞争的状态。但是C/C++和Java千
万不可忽视C#这个后起之秀，C#正以旺盛的企图快速地向两位老大哥挑战之中，以竞
逐在程序员心中主流的地位。
从上面所有的分析中，我们可以知道使用C/C++语言的人数虽然的确是在下降之中，
但是幅度并不大，这代表C/C++语言有着非常稳定的支持力量，这当然也是因为在许
多的应用中C/C十十语言拥有不可取代的优势，更何况C/C++开发工具的市场仍然拥有
将近600 Million美金的规模。这实在是一个非常大的数字，以Borland来比较的话，
Borland全年所有的软件营收不过是240 Million左右，可见C/C++市场的潜在力量，
对于Borland来说这是绝对不可放弃的开发工具市场。
相对于欧洲的发展模型和美国非常接近，另外一个全世界最大的程序员市场--中国大
陆，并没有在这次的调查中显示出开发工具的使用状态，也许未来应该有全球软件语
言的调查评估。不过从各种迹象显示，大陆的市场目前是以C/C++和Ddphi分占程序员
使用的大宗，而Java则在快速的成长之中。这和台湾地区有一点不同，那就是在台湾
地区是以VB、Delphi和C/C++为主要的语言力量，而Java则是几乎进入成熟的阶段，
开始和VB、Ddphi以及C/C++分庭抗礼。因此对于Borland来说，不管是在中国大陆和
台湾地区，C/C++开发工具都是很重要的，所以Bodand的RAD部门宣称中国大陆的市场
是Borland RAD部门最后的圣地，因为在中国大陆Borland的C++Builder、Delphi、
Kylix和未来的C/C++开发工具以及.NET的开发工具都拥有全世界最大成长潜力的机会。
蓬勃发展的新兴C/C++力量
其实不管是什么程序语言，在面对竞争日益激烈的情势中，程序语言的开发厂商和爱
好者莫不卯足全力地捍卫和鼓吹其支持的程序语言，对于C/C++的发展厂商和爱好者
来说也是一样的情形。更有趣的是，虽然使用C/C++语言最大的平台是UNIX/Linux，
但是Windows上的C/C++开发工具反而是竞争得最为激烈、进步幅度也是最大的平台。
对于Borland来说，在Windows平台上是市场排名第2的C/C++开发工具厂商，而且C++
Builder这条产品线对于Borland来说，占据了开发工具第3位的收入来源，对于Borland
有着重要的贡献，Borland不但不可能放弃，反而更要想办法增加市场规模。在C++
Builder推出并且从Microsoft抢回了部分的市场份额之后，Borland计划推出更新、
更强劲的C/C++开发工具。Borland也在BorCon 2002中透露了一些有关未来C/C++开发
工具的计划。不过在我们讨论C/C++开发工具的未来之前，先让我们看看目前在C/C++
技术方面重要的发展。
首先在C/C++编译器方面Windows平台上厂商的表现实在是差强人意，不管是Borland
或是Microsoft都没有完全实现出符合ANSI C/C++标准的C/C++编译器，这和数年前四
大C/C++编译器厂商彼此竞争激烈、快速进步的情况来说实在是令人不满意，这也可
见失去竞争的市场其进步缓慢的现状。不过Borland已经宣称在发展下一代最佳化的
C/C++编译器，不但能够产生更好的最佳化C/C++编译机器码，而且也将符合ANSI C/
C++标准。相对于Borland在C/C++方面的大动作，Microsoft反而显得比较沉寂，除了
把VC++移植到.NET上的VC.NET之外似乎没有什么大的改善。当然，Borland是不是能
够真地推出宣称的C/C++编译技术还要看在2003年的表现。另外，在C/C++连接器(Linker)
方面Borland也宣称将要搭配新一代的C/C++编译器推出新一代的C/C++连接器，提供
更聪明、更紧密的最终机器码。
除了编译器、连接器和C/C++开发工具之外，另外一股发展快速的C/C++势力便是各种
C/C++的开放函数库和Framework了。许多的C/C++函数库和Framework由于品质良好而
且采用开放源码的设计，因此也快速被许多的C/C++程序员使用而盛行于C/C++程序员
的领域中，除了早为大多数C/C++程序员广泛使用而享大名的STL之外，其中最著名的
当属ACE、Boost和Loki这三个C/C++函数库和Framework了。
C/C++的王牌Framework--ACE
ACE是一个使用面向对象方式设计的C/C++Framework，主要是提供开发通讯应用软件
使用的核心同步处理(concurrency)和分布式设计模式(design patterns)的功能。ACE
提供了C++的封装类别(wrapper)和组件，让程序员在许多UNIX操作系统、Win32平台
和实时操作系统(Realtime Operation System)平台开发高效率的系统服务和应用程
序。ACE Framework提供了将近150000行的程序代码以及450个左右的类。
ACE为了分隔Framework的复杂度，采用了层次的架构来设计，下图就是ACE Framework
的设计架构图。在ACE Framework的低阶层次中封装了OS的Adapter以及C++的封装类
别，以增加ACE Framework在不同平台之间的移植性。而在ACE Framework的高阶层次
中，则提供了延伸低阶C++封装类别的能力，以提供可重复使用的分布式组件以及分
布式计算中间件。由此可知，ACEFramework的目的是提供一个跨平台的中间件
Framework，以便让C/C++的程序员在各种平台中开发高效率的分布式计算应用系统。
由于ACE Framework的流行以及广泛被使用，因此已经被许多C/C++程序员视为主流的
C/C++Framework。目前也有许多的应用程序使用ACE Framework成功的开发出高品质
的分布式软件。例如下图的ACE ORB便是使用ACE Framework实现重要的CORBA规格的
实时ORB引擎：TAO。TAO由于使用了ACE Framework，因此也属于一个免费的ORB引擎，
从遵照OMG规格的CORBA都能够使用ACE Framework来实现这一点，就可以了解ACE
Framework的实用性。读者可以在www.cs.wustl.edu/~schmidt/TAO.html找到TAO的数
据。
另外一个使用ACE Framework实现的著名软件就是JAWS了。JAWS是一个高效率的
Adaptive Web Server，下图是JAWS提供的复杂，强大的功能。读者也可以在
www.cs.wustl.edu/~jxh/research/找到JAWS的数据。
由于目前ACE Framework被使用得愈来愈广泛，所以许多C/C++编译器也开始支持ACE
Framework。因此新一代的C/C++开发工具必须能够支持ACE Framework，最好还能够
提供整合ACE Framework的功能，直接在C/C++开发工具内部支持ACE Framework。
Template和Design Pattern的极美结合：Loki
Loki是一个愈来愈流行的C/C++类函数库，它是由Andrei Alexandrescu先生开发的，
而Andrei也是"Modern C++ Design"一书的作者。事实上，Loki就是因为"Modern C++
Design"一书的介绍才逐渐被许多C/C++程序员使用。
Loki是结合了Design Pattern、Generic Programming和C++语言集成的C++函数库，
充分展示了C++语言的优美和威力，并且提供了C++语言使用新的应用。由于Loki的优
美和盛行，因此现在许多C/C++编译器和开发工具都以支持Loki为重要的功能之一。
最新的C/C++标准函数库Boost
Boost是除了ACE和Loki外另一个快速崛起的C/C++标准函数库。目前Boost已经被C/C++
Standard's Committee提议成为C/C++标准的核心函数库，由此可见Boost的重要性。
目前Boost同样被许多C/C++编译器支持。未来的C/C++开发工具应该在核心部分就会
支持Boost。未来的C/C++开发工具最应该采用的开放架构应该是在核心部分支持Boost
和Loki，并且以开放的Adapter来整合ACE Framework。
著名的C/C++函数库和Framework的开发厂商Rogue Wave
数年前使用C/C++开发工具的程序员可能都知道Rogue Wave这家软件厂商，因为Rogue
Wave就是以提供各种专业的C/C++函数库和Framework著名的。在数年前Borland和许
多的C/C++开发工具厂商也都向Rogue Wave授权使用Rogue Wave的C/C++函数库。我记
得，数年前在使用C/C++语言时最喜欢使用的函数库也是Rogue Wave出品的产品。当
年在C/C++User's Journal、C/C++Report等著名的杂志中，Rogue Wave的产品也是经
常可见的。不过随着C/C++的盛况不再，Rogue Wave的声势似乎也不如前了，许多当
时Rogue Wave著名的C/C++函数库也随着消失，在前一阵子甚至传出Borland可能并购
Rogue Wave的传言。
但是随着C/C++语言最近的重振声威，Rogue Wave似乎也开始有了比较积极的动作，
也推出了许多新的C/C++函数库和Framework，有兴趣的读者可到Rogue Wave的网站上
看看。
不过，Rogue Wave的发展史也见证了C/C+4-语言使用的演变。以前Rogue Wave是以提
供高品质的C/C++函数库著名，例如Rogue Wave曾推出过封装各种数据类型运算方法
的C/C++函数库，但是在STL等开放C/C++函数库流行之后，Rogue Wave的产品自然走
入了历史。另外，Rogue Wave也曾推出过封装ODBC的C/C++类函数库，以提供C/C++程
序员在各种平台使用ODBC存取关系数据库的能力，但是随着0DBC成为历史，Rogue Wave
这样的产品自然也开始消失了。
因此，如何为一个已经流行超过10年的语言不断注入新的创意、技术和应用，是每一
个C/C++开发厂商都必须面对的事情。
C/C++开发工具的未来
那么C/C++开发工具的未来是什么？难道在四大C/C++编译器厂商大战之后C/C++开发
工具的市场便没有创新了吗？除了Microsoft的VC.NET和Borland的C++Builder之外，
Windows C/C++开发工具市场就此沉寂了吗？
当然不，在前面我们看到了C/C++函数库和Framework的蓬勃发展，相较于目前C/C++
开发工具厂商来说是有活力得多了。因此，未来的C/C++开发工具必须能够跟上最新
的C/C++标准以及各种颇具威力的C/C++ Framework。未来的C/C++开发工具除了本身
提供的编译器、集成开发环境和Framework之外，必须采用新的架构设计以提供C/C++
程序员整合Third-Party或是Open Source的C/C++ Framework，而无需C/C++程序员辛
苦地自己修改这些C/C++ Framework才能够使用。另外，未来的C/C++开发工具必须提
供类似Java的高移植性，让C/C++程序员能够在各种平台开发各种C/C++应用系统。除
了一般的应用程序之外，在移动设备、低阶系统程序等都必须能够胜任，而不像现在
的Windows C/C++开发工具一样，各在不同的应用中占有优势。
目前，Microsoft的VC++在窗口平台上的C/C++开发工具发展方向已经非常明显，那就
是维持原生窗口C/C++开发工具的现状并且往VC.NET发展。Borland呢？除了Borland
C++Builder 6.0之外，未来Borland的C/C++开发工具将提供什么新的发展呢？
在前一阵子Borland已经宣布了未来仍将投入大量的资源研发新一代的C/C++开发工具，
将采用下图的架构提供给程序员最具整合威力的C/C++开发工具。
从上图中的架构，我们已经可以预知未来的Borland C/C++开发工具将允许程序员高
度整合最流行的C/C++ Framework，例如前面讨论的ACE、Boost和Loki等。这是非常
重要的，因为未来的Borland C/C++开发工具将提供跨平台/移动设备的能力，而这些
C/C++ Framework也大都提供跨平台的功能。如果Borland能够提供完整的整合能力，
那么这代表未来的Borland C/C++开发工具不管在什么平台，都能够提供最完整和强
劲的功能。
如果Borland真能推出这种新一代的C/C++开发工具，那么这将是Borland从当初Borland
C/C++3.0以来最具创意的产品，也是最值得程序员期待的C/C++工具。Borland是不
是能够遵照承诺推出呢？也许答案在2003年便会揭晓了。
--
[1;36m昨天[0;37m是[1;32m今天[0;37m的[1;33m历史[0;37m，[1;32m今天
[0;37m将成为[1;34m明天[0;37m的[1;33m历史[0;37m。 [m
每当我们回顾[1;33m历史[0;37m的时候，总会发现两样东西 [m
[4m[1;31m嫣红的血[0;37m，和[4m[1m晶莹的泪[m
[m[1;34m※ 来源:·飘渺水云间 freecity.cnzju.net·[FROM: pcq][m
^v^v^v^v^v^v^v^v^v
第十三章 软件科技的发展和Borland的未来
"Into The Future？"
在前面的章节中，本书讨论了许多现象和问题。除了Borland本身的发展故事之外，
也讨论了一些科技的现状和未来的发展。在Java和.NET平台的竞争以及许多科学技术
的发展下，Borland的未来到底会如何呢？Borland又要如何适应才能够持续在信息界
竞争、生存下去，进而茁壮成为更大的信息公司呢？在本章中我将提出一些个人的看
法。
除了软件公司的发展之外，我也观察到了一些信息技术的走向。这些信息的发展在未
来也都将牵动着开发人员的走向。除了在第10章中讨论的事项之外，我也认为更精致
化的程序开发能力、面向对象和Modeling的平民化、Web Service的发展以及.NET平
台的普及化都将在2003年开始对于开发人员产生愈来愈深的影响。其中，Web Service
和.NET是开发人员无法控制的信息发展潮流。开发人员唯有在了解了它们的趋势之后，
及早准备以适应未来的趋势。
而精致化的程序开发能力、面向对象和Modeling技术的平民化，则是属于比较贴近开
发人员的发展，也是开发人员能够掌握和进一步控制的因素，是软件人员必须了解未
来继续从事软件开发工作时必须克服和掌控的技术趋势。
到底这些因素的影响事项是什么呢？为什么它们对于软件人员在未来有很大的影响呢？
这些也是本章讨论的重点。
不都是整理和抽丝剥茧吗？
我在从事信息工作的生涯中使用过数种不同的程序语言、数据库、组件模型以及
Framework。面对许多新的技术不断地出现，开发人员似乎陷入了永远学不完新东西的
梦魇。不过，如果开发人员仔细回味许多技术的本质，却会发现这些技术其实只是把
我们已经了解的东西再以更细致化的方式加以运用，关键在于开发人员是否注意到了
这些本质和趋势而已。
例如，目前在C++中流行得火热的Template、Policy-Based template，在Java、Object
Pascal和C#中当红的接口程序设计，以及各种组件模型和Web Service中的服务接口
等，如果我们仔细地咀嚼，会发现许多的东西正是发挥程序员原本就拥有的整理和抽
丝剥茧精神，再加以发挥的东西。这怎么说呢？让我们以数个例子来说明读者就容易
了解了。
首先让我们想想为什么会出现数据库这类的产品？很简单，因为由于数据愈来愈多，
数据种类也愈来愈繁杂，因此造成了我们需要一种软件产品能够整理这些数据让它们
更容易的被我们处理和使用，因此才有了数据库的想法和产品。
在每一个程序员学习撰写程序代码时，也会发现随着撰写的程序代码愈来愈多，许多
的程序代码不断重复出现和被使用，因此很自然的程序员开始使用例程(routine)/子
程序(subroutine)或是过程(procedure)、函数(function)等机制帮助我们进行程序
代码整理和抽丝剥茧的工作。
这些数据和程序代码整理的工作几乎是每一个程序员的求生本能，只是有的程序员只
做基本的整理工作，而更聪明的开发人员则对于整理的工作有不同的看法，进而促使
了许多延伸软件技术的出现，也开始对软件开发产生了重大的影响。例如，对于原本
杂乱的程序代码以数据和程序代码分离的看法而逐渐产生了面向对象的技术，以分离
例程/子程序和数据类型为看法的应用则产生了类似C/C++中的template技术，而以函
数面对服务的看法，认为开发人员应该面向服务的开发模式则造成了接口程序设计
(Interface Programming)的应用热潮。虽然现在这些从程序代码延伸出的技术都独领
风骚，在软件开发界中产生了重大的影响和开发模式的改变，但是，如果我们追根究
底来观察，这些技术不都是从对程序代码和数据的分析、整理和抽丝剥茧之后，以更
精致的方式来处理和开发软件吗？
因此，本着相同的想法和精神，聪明的开发人员开始脱离单一程序语言的架构而进入
了开发出可重复使用的软件组件模型，让不同的程序语言都能够在统一的组件模型中
达成团队开发的功效。这个更聪明的整理和抽丝剥茧的想法造就了CORBA、COM/COM+
和EJB等组件模型的驱动力。
除了脱离程序语言之外思考的开发人员外，另外有一些开发人员则再次回头检视本身
和他人的程序代码，并且努力搜寻优良和成功程序代码的基因，因此发现了这些优良
和成功的程序代码似乎都有着类似的模式和架构，再经过进一步的分析之后终于产生
了Design Pattern，这成为目前最重要的软件开发模式和技巧之一。在这之后，这些
聪明的开发人员了解到如果能够成功运用Design Pattern，并且把程序设计转变成以
服务为目标的方式，将更能够简化、标准化和结合Design Pattern的运用，并且隐藏
复杂的实现技巧，这就进而产生了Service Interface Programming的观念和技巧。
由此可见，只要开发人员能够发挥细心整理和抽丝剥茧的能力，那么即使无法创造出
伟大的新软件工程或是软件技术，但是仍然能够帮助我们增加生产力和软件品质。因
此，对于开发人员来说重要的不是无止境地学习层出不穷的各种新技术，而是到底有
没有了解这些技术之后代表的观念、思想，以及学习最重要的对于软件开发整理和抽
丝剥茧的能力。在我的工作生涯中，一直认为技术终究是会被大多数的人学会的，但
是在辛辛苦苦地努力这么多年后，到底我们的思想、眼光和抽丝剥茧的能力是否有所
精进呢？如果没有，那么我们永远就像被蒙着眼睛，只能尾随着他人告诉的技术前进，
永远找不到自己的方向。
现在，再让我们以一个C++的例子来证明只要开发人员能够看透程序语言和技术背后
代表的真实意义，那么即使是在已经被众人熟知的技术中，仍然能够创造出新的技术
和含义。在Andrei Alexandrescu先生所著的"Modem C++Design"一书中，我们再次看
到了聪明的开发人员对于程序语言的了解和对于程序代码撰写整理以及抽丝剥茧的惊
人能力。Andrei的想法不算复杂，但是却巧妙地运用了对于C++ template深刻的了解
而创造出了自己的精彩之作。其实，全书呈现的思维之妙，让读者可以从一开始的小
范例就看出如何运用已经广为人知的技巧之后呈现出的不同风貌。
例如，Andrei想法是以Policy-Based想法为主，以各种不同的准则来提供服务函数，
那么通过C++ template的能力，让开发人员能够根据自己的需求来选择需要的Policy
和数据类型，结合于C++的template，可以捉供开发人员前所未有的自由度，并且开
启了以往函数库开发人员无法想象的挥洒空间。例如，下面的程序代码中提供了三个
不同的类别，这三个类别都可以建立指定类别T的对象实例(Object Instance)，但是，
这三个类别各自使用了不同的方式来建立T的对象实例。在这里提供了建立T类别的对
象实例的准则Create()方法，但是却允许开发人员自由地根据自己的需求选择要使用
那一种方式来建立对象实例。
由于上面的三个类别提供了相同的Policy(其实，从Service Programming的角度来看，
可以说它们都提供了相同的服务)，因此，开发人员可以再自行定义一个consumer类别，
并且结合C++的template功能，让这三个服务类别成为客制化数据类型，再通过template
的能力，自由地被开发人员选择使用。例如在下面的程序代码中，WidgetManager
类别通过template功能可以在编译时期动态决定使用那一个Policy类别作为父代类别，
而自动拥有建立T类别的对象实例的能力。
最后，我们可以再次使用template能力在编译时期由开发人员代入欲建立的T类别的
实体类别定义，通过template功能结合Policy服务和各种不同的数据类型。例如，下
面的程序代码即指定了使用OpNewCreator这个Policy服务类别，以传统的new操作数
来建立Widget类别的对象实例，并且定义成新的客制化类型MywidgetMgr：
typedef WidgetManager