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最后跨平台的诉求也在瞬间瓦解,因此失去市场也是
不可挽回的命运了。