按键盘上方向键 ← 或 → 可快速上下翻页，按键盘上的 Enter 键可回到本书目录页，按键盘上方向键 ↑ 可回到本页顶部！
————未阅读完？加入书签已便下次继续阅读！
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的能力（是
巧合吗？的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在面�