第四章 未完之传奇

"成功产品的背后有着更多不为人知的秘密!"

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方面的技术为主。

作，因此他也从事C++Builder中融合ATL方面的工作，在BorCon中，Bruneau Babet演
讲的主题主要是Borland开发工具在COM/COM+的技术支持。

在这里，我无法介绍完所有相关的重要人物，除了上述几位外，许多大家熟悉的人物，
包括Dr. Bob、John Kaster等，我都没有介绍到。这是因为Dr. Bob和John Kaster
是许多人非常熟悉的，他们的照片在网站上可以经常看到，因此就不再列为重点，这
里是以读者不太熟悉的人物为主，让喜欢Delphi/C++Builder的读者能够看看这些杰
出软件人员的长相、了解他们的个人资料，让许多"久闻其名"的人物真实地呈现在我
们面前，作为我们学习的借鉴。