borland传奇-第12章
按键盘上方向键 ← 或 → 可快速上下翻页，按键盘上的 Enter 键可回到本书目录页，按键盘上方向键 ↑ 可回到本页顶部！
————未阅读完？加入书签已便下次继续阅读！
不晓得是不是因为在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之后，必须再次对于的支持进行强化。最后，是为下在
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小组才再次激活跨
平台的计划。
为了支持更好的开发能力，Danny修改了Delphi的编译器，直接支持接口的参
考计数值（Reference Count）的维护工作，以免除开发者繁杂的程序代码，提供了类
似Visual Basic的能力。同时Danny也在Object Pascal程序语言本身中加入接口
（Interface）的机制，让Object Pascal和Java一样对接口程序设计都提供First Class
的支持。Danny并且更进一步，巧妙地结合的接口以及Object Pascal程序语言的接
口，让Delphi的程序员更方便地使用和处理接口。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的开发而全力投入的阵营，这当然又是
另外一个极为精彩的故事了。
对于Danny来说，只有一个最重要的目标，那就是再次擦亮Delphi的光芒，让Delphi 4
的失败能够在下一个版本中一雪前耻，并且把Delphi开发成最棒的RAD开发工具。Danny
的决心也让Delphi R&D小组再次安定了军心，在历经了
