这是一篇非常精彩的文章，无意中在网上发现，
比起原来《程序员》发表的开发工具大比拼更专业。
可惜不知道作者是谁，如果作者看到或者有谁知道作者，
请一定和我联系。（mail:jiangtao@csdn.net） 偶然来找一个文件，却发现这里关于vc++和delphi的讨论很是激烈。看了大家写的一些 文章，觉得有些看法正确，有些就很偏颇甚至错误(也许无知？很抱歉我这样说:-)。我 无意与任何人争论，更愿意把这看成是技术上的讨论。应该本着公正，不带偏见的态度 (这并不意味着非要平分秋色，一切应以事实为准)。我用过除tp1以外的所有版本的 turbo pascal，所有版本的turbo c/borland c++，所有版本的delphi和c++ builder； 以及msc 5.0/6.0，msc/c++ 7.0和visual c++ 4.2/5.0。不敢说有多高的水平，至少也 算有一点经验吧。下面就谈一下我的看法。 1. 编译器 应该说borland的编译器是最好的。因为borland有全世界最好的编译器开发组(虽然 anders hejlsberg离开了)。从技术上来讲，borland领先任何竞争对手至少2~3年。一 般来说，borland的编译器总是能生成更小的代码并且通常(并不是在任何情况下)更快 的代码。 紫云英、曾登高在文章中说vc++编译的程序小，这其实是使用了动态连接的结果。m$把 vc++的运行库(msvcrt*.dll,msvcp*.dll,mfc*.dll,你看看这些文件加在一起有多大) 在安装windows时就放在了system/system32目录中了。两位说“协商接口”的问题，恐 怕是对某些英文文章的理解错误。m$就是不愿意在windows中带上其他公司的运行文件， 没有技术上的原因。 其实delphi/c++ builder不论在动态连接或静态连接的情况下，生成的程序都要比 vc++的小。比如mdi的例子程序：在delphi/c++ builder中选new ... | projects | mdi application，在vc++中用mdi app wizard；生成的程序功能是非常类似的。 下面是比较结果： (delphi打开优化，c++ builder使用最大速度优化，vc++ 5使用最小代码优化) delphi 3 delphi 5 c++ builder 5 vc++ 5 dynamic link 21k 35k 44k 70k static link 253k 398k 467k 490k 凡是使用了应用类库的程序(不管是mfc，owl，vcl以及新的clx框架)都要比不使用的大 不少。这是因为目前的智能连接(smart link)技术还只能针对全局变量/过程，而不能 用于对象结构。哪怕你只使用了某个类(或被这个类间接引用)的一个属性或方法，这个 类以及它所引用的所有类都全部被连接到exe中。目前所有的编译器都没有解决这个问 题。 (ps: 其实能生成最小代码(真编译)的高级语言编译器是turbo pascal，不信你写程序 比较一下： program test; begin writeln('hello,world.'); end. 生成的exe不到1.5k。而同样的c程序： #include ＜stdio.h＞ main() { printf("hello,world./n"); } 最精悍的c/c++编译器生成的代码也有6k。 ) 那么几个编译器生成的代码质量又如何呢？ 举一个例子，比如我们在编程时经常用到的for循环语句： (1) object pascal: procedure foo; var i,j: integer; begin for i := 0 to 15 do j := j + i; end; (2) c++ void foo(void) { int i,j; for (i = 0; i ＜ 16; i++) j = j + i; } delphi 3生成的代码(打开优化)： 字节数 时钟周期 00424aa9 33c0 xor eax,eax 1 00424aab 40 inc eax 1 00424aac 83f810 cmp eax,0x10 1 00424aaf 75fa jnz -0x06 0 (可并行) ----------------- 8 3 c++ builder 5生成的代码(最大速度优化)： 00401535 33c0 xor eax,eax 1 00401537 40 inc eax 1 00401538 83f810 cmp eax,0x10 1 0040153b 7cfa jl -0x06 0 (可并行) ----------------- 8 3 visual c++ 5生成的代码(最大速度优化)： 27: for (i = 0; i ＜ 16; i ++) 00401205 mov ecx,dowrd ptr [j] 1 00401208 xor eax,eax 0 (可并行) 28: { 29: j = j + i; 0040120a add ecx,eax 1 0040120c inc eax 1 0040120d cmp eax,10h 1 00401210 jl foo(0x0040120a)+0ah 0 (可并行) 00401212 mov dword ptr [j],ecx 0/1 (取决于上一条指令的分支预测情况) 30: }; ----------------- 16 4.2 (假定分支预测准确度80%) vc++ 5的最小代码优化生成也有11个字节： 27: for (i = 0; i ＜ 16; i ++) 00401205 xor eax,eax 1 28: { 29: j = j + i; 00401207 add dword ptr [j],eax 1 0040120a inc eax 1 0040120b cmp eax,10h 1 0040121e jl foo(0x00401207)+7 0 (可并行) 30: }; ----------------- 11 4 注： (1) delphi/c++ builder的结果是用turbo debugger直接反汇编的，vc++ 5的结果是从 集成环境的源级调试得到的。 (2) 时钟周期数以pentium处理器为例，实际上，对于没有并行执行单元的cpu(比如 386/486和nx586等)vc++ 5生成的代码速度还要更慢一些。 (3) 分支预测准确度源自intel的"pentium optimization reference"。不过与具体程 序密切相关，一般来说程序中的条件转移指令越密集则分支预测准确度越低。 可以看出，delphi/c++ builder的这段程序有1~1.2个时钟周期的优势。这主要是因为 delphi/c++ builder的编译器比较智能，根本不编译无用的废语句。 (有趣的是，对于这段程序而言，vc++ 5的最大速度优化反而不如最小代码优化生成的 代码运行速度快。) 不要以为1~1.2个时钟周期不算什么，整个程序的快与慢就是这样一个个时钟周期积累 出来的。而且就这几条指令而言相当于快25%~28.6%，是非常可观的数字。 我没有用vc++ 6测试(我从vc++ 5以后不再使用vc了，因为c++ builder 5能完全兼容 vc --- 这种兼容性从c++ builder 3开始就有了，不过一开始并不完善)，不知道是否 有改进。有人有兴趣的话请测试一下。 有兴趣的话，可以去jake's code efficiency challenge(http://www.xnet.com/~johnjac) 看一看。那有代码运行性能挑战。目前delphi/c++ builder在6项测试中保持5项领先。 (ps：delphi 2就曾在1996年的pc week的性能测试中击败过vc++ 4.2) 2. 语言特性 首先我不想评价所谓“pascal是玩具语言”这种无知的说法。某些连basic都用不好的 人是不可能正确评价其它语言的优劣的。至于“只配高中生使用”就更加可笑了： peter norton没上过大学，id software的john carmack没上过大学，你不服气？！ 请不要嘲笑高中生，大多数程序员可能永远也达不到这些“高中生”的水平。创造性工 作需要的是天才，你认为天才相当于什么学位？:-) (1) 预处理，宏以及.h文件 object pascal不支持预处理，其实是不需要。无法直接编译源代码的编译器才需要预 处理器的支持(用于翻译/规范源程序(也包括.h之类)以利于编译)。预处理器的出现是 因为当初ken thompson和dennis ritchie要在只有256k内存的pdp-11上实现c编译器难 度很大，才采取的折衷办法。现代大多数c/c++产品已经把预处理器包含在编译器中了。 (ps：c中采用尽可能短的关键字/运算符也是由于这个历史原因) 至于macro和.h则应该说是垃圾特性，只是由于兼容性的考虑才保留下来的。ansi/iso c/c++规范中明确建议：“不要使用macro和.h，应该使用程序中的常量定义和函数替 代”。因为macro和.h不是c/c++的语言特性(这是真的！)，没有明确统一的语法定义。 还会导致编译速度降低，另外由于macro在每个使用的地方被展开(不是调用)，大量使 用macro会使生成的代码臃肿。 (2) 集合，子界类型 c++不支持这些object pascal的原生类型(编译器能直接识别的)。但可以用类来模拟， 毕竟c++的对象结构是最复杂灵活的(ada除外)。不过性能有损失。 (3) 枚举类型 object pascal不支持为每个枚举元素指定值。 例如c/c++中可以定义：enum aweek {sun = 1,mon,tue ...}; object pascal中只能定义：aweek = (sun,tue ...); (4) 数组 c/c++不支持object pascal中指定下标的数组，下标只能从0开始。 (5) 结构 object pascal不支持struct(在pascal中称为record)中的位域(bitfield)。bitfield 可以bit为单位(不需要整字节)来存储结构成员，可以减小结构的存储空间。不过存取 效率会有所降低。 (6) 字符串 字符串处理是object pascal的强项之一。能够支持灵活高效的串处理。严格意义上讲， c/c++不能算支持原生的字符串类型。char *和char[]更近似于用户自定义类型，因为 编译器不支持字符串的内存自动分配和回收，需要用户自己调用malloc()和free()。 object pascal也支持c/c++风格的字符串(称为pchar)。不过string类型更加强大。从 实现上来看，object pascal的string类型使用前缀表示串长度(1字节前缀的short string和4字节前缀的long string，两种string自动兼容，并且long string也兼容 pchar)，c/c++中的char *和char[]使用后缀chr(0)表示串结束。不同的表示方法对串 处理性能有很大的影响：对于大量，复杂的字符串操作，用object pascal可以写出比 c/c++快几十倍的程序(许多用pascal写的pascal编译器，比如free pascal， pascal pro等，虽然技术水平一般，但编译速度也很快，在某种程度上也得益于pascal 的字符串处理效率)。比如取串长度函数length/strlen()，object pascal的实现只需 要一条mov指令，而c/c++的实现则需要进行重复串扫描直到找到结尾0为止。 object pascal的string类型在支持unicode字符方面也有优势。要知道c/c++的字符串 给现代操作系统支持unicode字符带来了很大的困扰，比如串'abc'的unicode表示为： 41 00 42 00 43 00，这使c/c++程序根本无法处理这种字符串。虽然修改编译器可以很 容易解决这个问题，但光修改编译器是不够的，还要修改操作系统，否则以前的大量 c/c++程序根本无法在新操作系统上使用(这简直是灾难 --- 你连notepad都没了，怎么 办？:-)。windows采用凡是涉及字符串处理的api都提供两套的解决方案。比如textout， 有用于处理ascii字符的textouta和用于处理unicode字符的textoutw。而unix/linux采 用另一种办法：凡是涉及字符串处理的api都使用utf8压缩编码(一种类似于rtf的编码 方法：凡是ascii字符都直接存储，多字节字符则用/进行转义)，虽然(勉强)保证了兼 容性却也代价不小。 (ps：c++中的string/ansistring是用类模拟的，所以性能...) (7) 多重继承 毫无疑问，object pascal不支持多重继承；并且也看不出borland有增加这一特性的意 向(其实增加是轻而易举的)。object pascal通过接口(interface)实现多重继承。 interface不仅可以引入用object pascal实现的对象，也可以引入其他语言实现的 com/dcom/corba对象。你真的需要多重继承吗？我想大多数程序员和我一样都从来没有 使用过多重继承(连vcl这么强大灵活的体系结构都根本没有用到多重继承)。 (ps：java和delphi一样不支持多重继承，也使用interface来实现多重继承。其实这并 不奇怪：jdk 1.2和java 2主要是由borland开发的，sun只挂名而已。不信你看java类 库是不是和vcl很象。:-) (8) 对象模板 object pascal不支持对象模板。因为对象模板不过是宏的语言实现而已(宏本身不是 c/c++的语言特性)。 (9) 重载 object pascal支持函数/过程的重载，不支持运算符重载。c++全部支持。 (ps：我个人倾向于object pascal应该增加对运算符重载的支持) (10) 位及逻辑操作 object pascal和c/c++在这方面没什么差别。 c/c++的＆，|，~，^，＞＞，＜＜，＆＆，||，!等效于object pascal的and，or，not，xor， shr,shl(and，or，not，xor既用于位操作也用于逻辑操作)。不过c/c++不支持逻辑 xor(a xor b = a and not b or not a and b，还是可以实现的)。 (11) 风格 其实这是我更倾向于使用delphi的一个重要原因(由于工作的原因，我也经常使用c++和 汇编)。就象有些文章所说的：“object pascal和c++是同一重量级的语言”，确实难 分轩轾，差别反而主要是在风格上。c++强调灵活，而object pascal更注重整洁和优美。 《程序设计语言：设计与实现》一书的作者也称赞pascal是“一种极优美的语言”。有 人因此认为pascal“笨拙”。其实应该是“大道至简”。我认为即使用c++写程序也还 是工工整整的好，不要卖弄技巧。只有水平不高不低的程序员才喜欢卖弄技巧(水平太 低的卖弄不了，太高的又不愿卖弄了)。就象有人评李昌镐的棋“平淡”，但马晓春再 怎么“鬼才”也只能甘拜下风。 上面说的其实都是c++ vs object pascal。不过也适用于vc++ vs delphi。 (ps：vc++其实并未实现全部ansi/iso c++ 95规范(目前的最新标准)的特性(所以有人 戏称之为c+)。而c++ builder则完全兼容ansi/iso c++ 95规范，并支持at＆t(c的诞生 地)和unix v的全部c++扩展特性。有人称“m$坚持工业标准，borland随意修改”，这 是不对的。delphi也全兼容ansi/iso pascal 1983/92规范，以及apple object pascal (用过code warrior professional的应该知道apple的object pascal)。 ) 3. 功能及其他 (1) 易用性 毫无疑问delphi有巨大优势，这不用多说了吧。 (ps：delphi的真正伟大之处在于并不因为易用而降低技术水准。你需要复杂性就有复 杂性，你需要灵活性就有灵活性；不用可视化也一样写程序(可视化只是object pascal 对象结构的另一面)，不用vcl也一样写程序) (2) 适用范围 vc++几乎能做任何硬件允许的工作。delphi也能。 (“不！！！”，我知道你会这样说，你会举出vxd。:-) delphi不能写vxd(其实如果你用delphi生成obj，再用m$的link连接，是可以的)是有原 因的(你见过非m$的工具能生成vxd的吗？watcom？symantec？gnu？...)，但不是技术 上的原因。vxd的le(linear executable)文件格式最早出现在windows 3.0中，格式很 简单(比ne和pe格式都要简单)，基本上是内存映象文件。但m$不知道出于什么动机就是 不允许其他公司的软件生成它的这种(专利)格式。 delphi是可以写windows nt的sys和新的wdm(windows driver model)驱动程序的，这些 使用普通的dll格式。 (ps：从法律角度讲，你自己写一个程序，未经m$允许生成ms word文件也是不行的) (ps：玩过“奇迹时代”(age of wonders，http://www.epicgames.com)吗？是用 delphi 3写的。画面和速度都优于m$的“帝国时代”。不过我不喜欢玩策略类游戏，我 喜欢的是duke3d和quake系列，还有tomb raider系列。:-) (3) 集成开发环境 delphi的ide更简洁/好用一些。 (4) 数据库支持 在这方面除了delphi的兄弟c++ builder/jbuilder恐怕只有power builder能(勉强)与 delphi相比。不过pb的性能和使用范围就差得太远了(要不怎么叫poor builder呢？:-)。 (ps：我的印象是现在大多数基于网络/大型数据库的c/s和多层结构的应用都是用 delphi/jbuilder开发的) (5) 网络功能 delphi也有一定的优势。尤其是在internet开发方面。 (6) 组件支持 delphi除了基于object pascal的vcl/clx外，也支持基于com/dcom的组件(比如activex)， 另加corba支持。vc++只支持支持基于com/dcom的组件。 (7) 应用框架/设计思想 vcl比mfc至少领先一代，这也毋须多言。mfc充其量不过是对owl的(一种不太成功的)模 仿而已，从设计思想上看甚至还不如owl。作为一种语言的基本类库(不论可视与否)， 应该从大处着眼，力求简洁有效，保持一定的弹性和抽象度(抽象意味着从功能出发， 比如vcl中的tcanvas就是对windows中dc(device context)的一种极好的抽象，比起mfc 中的设计高明了何止一点半点)。而不是面面俱到，一一照搬apis(不幸的是，m$的程序 员多年以来一直在不辞劳苦地做这项工作)。看看mfc的某些类，简直惨不忍睹：通常除 了省了hwnd和dc之类的参数(已经作为类的私有数据保存了)，其方法(method)简直就是 windows api的翻版。这样做有什么意义呢？windows api不就摆在那里吗？比如说，使 用mfc中的线程类还不如直接调用createthread/exitthread/resumethread/ setthreadpriority之类的api更方便快速呢。 (ps：用过delphix(http://www.yks.ne.jp/~hori/)吗？directx这么繁杂的结构可以用 object pascal封装得如此之好再次证明了vcl体系结构的强大) (8) 调试 两者相差无几。vc++的源级调试更用户友好一些，而delphi/c++ builder对多线程程序 的调试支持更好。 (ps：要比单独的调试工具，borland的turbo debugger可就要比m$的codeview强多了) (9) 运行环境/系统需求 应该说差不多。vc++的启动速度确实要快于delphi(这主要是相对于delphi 4+而言， delphi 3的启动还是很快的)。这很大程度上是由于一个事实：vc++主要是一个基于文 本编辑器的传统开发环境。code warrior professional不是启动更快吗？ 至于“一个数据库程序要带上3~5mb的bde运行文件”的说法，这可能是由于在安装制作 工具(installsheild，wise之类)中使用了“全部bde安装”(默认)而不是“部分bde安 装”。如果你只使用access，dbase，foxpro，paradox之类的桌面数据库，只需要几百 k的运行文件就可以了。用m$的工具开发的数据库程序也要带上一大堆odbc，dao，jet， ado，msde之类的运行文件。在delphi 5中，如果使用adoexpress，interbase express 访问数据库的话，可以不带bde。 (ps：不管怎么说，borland在delphi/c++ builder的启动速度方面还是要努力改进!) (10) 产品质量/稳定性 有文章称“vc++的质量好，稳定性高”。真的是这样吗？visual studio的service pack 不是都出到4了吗？什么是service pack？主要不就是bug fix + patch吗？！borland 的工具也并不完美，delphi 3的vcl中确实存在“内存漏洞”，会导致用d3开发的程序 有时(并不总是)退出后不能释放分配的内存。vc++的问题也不少：ie是用vc++写的吧， 上网时多启动几个，开开关关，最后全关闭，看看你的系统资源剩下多少了？还经常导 致“general protection error”。ultra edit是用vc++写的吧，也有同样的问题。其 实说到底，程序质量好不好，运行稳定不稳定，主要取决于开发者的水平/责任心。比 如说tomb raider系列和quake系列游戏同是用vc++开发的，但画面质量和运行速度显然 quake系列更胜一筹。象美国航空航天局(nasa)，俄罗斯宇航局(rsa)，美洲银行(bank of america，资产超过5000亿美元的大银行)，其他诸如american airlines，at＆t， bmw，compaq，bbc television，british telecom等大型机构/公司都在用delphi开发 复杂的，企业级(可笑的是，有人居然称“用vc开发企业级的桌面应用”，殊不知企业 级应用和桌面应用是相对而言的)的应用系统(在http://community.borland.com (borland社团站点)上有关于用delphi和c++ builder开发的产品介绍)，如果有人还要 说“...稳定和可靠是硬道理，只好忍痛割爱了”，那他恐怕只好自制开发工具(外带操 作系统)了。:-) (ps：关于delphi与某些显卡驱动冲突的问题，是由于某些显卡(如s3 virge gx)的老版 本驱动程序不能正确处理windows公用控制中的imagelist的绘制方法造成的，在这种情 况下所有在imagelist中使用多个图象的程序都会有问题) (ps：至于“一看到很多优秀的共享软件冒出具有delphi特色的错误异常就感到悲哀”， 建议此人先搞清楚你看到的“错误异常”消息是这些软件本身出错呢，还是运行时的异 常处理消息(比如“没有找到指定文件”或“索引超出范围”之类)再说。delphi中有完 善的异常处理，所以很多程序员不再写错误处理，而放手让编译器去处理。我认为这不 是一个好习惯，至少弹出的消息对话框可能与你的程序所用的语言/风格不一致。让人 家误会了不是？:-) (11) 帮助/文档 vc++的帮助和文档确实要比delphi/c++ builder的丰富一些。不过这不应当包括msdn， 因为msdn是一套独立的产品，并不是专门给vc++准备的，况且其中包括了相当多的 windows技术资料。作为一名程序员，不管用什么开发工具，可以(也应当)有一套msdn。 windows数据结构/apis是用c风格描述的这一点可能对delphi程序员来说略有不便，不 过delphi中已经包括了大多数转换；另外，如果一个程序员连转换.h文件这么简单的工 作都做不了的话，他(她)可能也做不了什么象样的开发。internet上的一个志愿者组织 (www.delphi-jedi.org/)在这方面也做了大量工作，在他们的站点上有几乎全部有用的 c/c++库.h的object pascal翻译。 (ps：delphi/c++ builder程序员为什么不可以买一套msdn呢？毕竟我们还在用m$的操 作系统，总不至于连windows技术资料都不要了吧) (ps：从msdn看m$ msdn中的技术资料主要是以compiled html(.chm)格式存放的，但m$把全部.chm放在 disc #1，而把索引文件(.chi)单独放在disc #2。这样一来就无法从光盘上直接看这些 文件。要么安装，要么手工把相应的.chm和.chi拷贝到一起。我看不有什么技术上的理 由(谁知道请告诉我)不把一半.chm和.chi放在一张盘，而另一半放在第二张盘。这至少 反映出m$内部某些人的阴暗心理) (12) 国际化支持 vc++中已经包括了十多种语言的rtl资源，delphi中需要自己做资源本地化。虽然 franch，german之类的版本中也包括english资源。:-＜ (13) 应用领域 vc++在windows设备驱动开发(毕竟是m$ windows)和某些桌面应用(比如游戏)开发中用 得较多。delphi更多应用在数据库/多层结构，多媒体和internet开发等方面。 (ps：vc++在游戏开发中用得较多我看主要是价格因素，游戏使用专用界面，通常不涉 及数据库和internet(即使internet play也不过是简单的tcp连接，并且directplay中 已包括此项功能)，昂贵的delphi和c++ builder显示不出优势。只需要$79的vc++标准 版，directx sdk(可免费下栽)，opengl文档(也是免费的)，至多再加一套msdn即可。 比如quake，全是手写的c代码，连c++特性都很少用到。borland也认识到了这一问题， 所以发布了免费的c++编译器) (14) 价格 m$的开发工具确实便宜(相对而言)，不过是否物有所值，只能看你干什么用了。 (ps：别指望你买的toyota能有ferrari的性能。:-) (15) 前景 有人认为m$财大气粗，borland难以对抗。我看不能这么简单下结论。m$有它自己的问 题：法律诉讼，人才流失，资源分散，四面出击(m$现在连鼠标，键盘，游戏杆，玩具 都生产)。而borland/inprise集中精力在开发工具，中件产品(如midas，visibroker和 application server)和企业应用/管理环境(如appcenter和security service)上，应 该还是大有可为的。 况且borland和m$之间并非纯粹的竞争关系，borland开发工具给m$ windows带来的收益 要远大于和m$开发工具竞争带来的损失。毕竟对m$来说，开发工具只占其收入的很少一 部分，即使不搞开发工具也只不过是个面子问题，于m$无损。m$在它面临垄断/不正当 竞争指控的时候，因为长期侵犯知识产权而赔偿给borland一亿美元(称为“授权费”)， 这多少也可以看作是一种和解的举动吧。 另一种经常听到的论调是“m$的产品市场份额大，borland能撑得住吗？”，这其实也 有很多问题。鉴于m$出于竞争的目的，经常虚报数字，影响市场(m$的律师在法庭上承 认m$曾夸大过其ie和office的市场占有率)；m$自己宣传的其开发工具的市场占有率也 很值得怀疑。m$还有重复计算的问题，比如卖掉一套visual studio，在计算vb，vc， vj等的销售量时都计算在内。其实很多人/公司买visual studio只用其中的一两种。其 实borland产品的销售量还是很大的，尤其是在欧洲，北美和澳大利亚，在亚洲...(是 因为d版太多了)。另外，每个公司都有自己的产品/市场定位，你能因为toyota，ford， volkswagen卖的多就说ferrari，maclaren，benz不行了吗？ 4. 结论 delphi(其实应该说borland产品)在技术上有优势，vc++(其实应该说m$产品)也占有相 当的市场份额。 (ps：说了半天等于没说。:-) (ps：m$的c#(读c sharp)能取得突破吗？我看不会。因为m$产品通常达不到所宣传的性 能；而且一种不符合标准(c#不兼容任何一种语言标准，虽然据称更接近c)的产品也很 难取得成功。j++就是一例) 5. 附：我所知道的borland和m$的故事 (1) bill gates是如何拿到ibm订单的 1979年，tim paterson写了最初的dos并以$1000的价格卖给了digital reserch。当时 apple的apple i和apple ii销势很好，所以ibm在1980年也决定搞pc。bill gates知道 后，认为是个机会，就以$5000从digital reserch买下了dos，并逼着手下人在一间没 有空调的小黑屋里日夜不停加以修改。m$当时是个小公司，只有十几个人，名叫 micro-soft。所以尽管dos的开价($20000加每拷贝$30授权费)比cp/m-86(指用于intel 8086/8088的版本，不是指年代)的开价($100000加每拷贝$70授权费)便宜不少，ibm的 人还是倾向于使用cp/m-86。据“比尔.盖茨的秘密”(bill gates' secrets)一书的作 者说，bill急得团团转，只好求助于他妈妈。bill的母亲时任华盛顿大学校长，与当 时的ibm董事长john opal是大学同学(据说...)。bill这一招果然有效，没多久就拿到 了ibm的订单，从此dos成了ibm pc上的首选操作系统。 (2) borland的名字和历史 borland听起来不象一个公司的名字，倒象一个国家的名字。 1982年，philippe kahn带着3000美元从巴黎到了美国，除去机票钱已所剩无几，只好 租人家的车库小阁间住。kahn在硅谷干了一段时间，并以mit(market in time，恰好与 麻省理工学院的缩写相同)为名开了一家公司。1983年，kahn和anders hejlsberg(丹麦 人，turbo pascal编译器的主要作者)合作开发了turbo pascal，并赊帐在《新闻周刊》 上登了一份彩页广告。turbo pascal在pc开发工具中是一个里程碑式的产品，它第一次 把编译时间由分缩短到秒，并且其$49的价格在当时也是创纪录的(当时的一份编译器动 辄数千美元，便宜的也要几百美元，还不好用)。turbo pascal在不到两年的时间里销 售了超过130万套(考虑到当时的pc数量，这是一个非常惊人的数字)，borland从此创立。 kahn在解释为什么以borland命名时说“我们要起一个与众不同的名字，其他公司都是 叫这个micro，那个soft什么的”。不过据认为这个名称与德国或北欧的某些地名有关 (kahn的父亲是德国人，而且borland的很多开发人员是北欧人)。 (3) anders hejlsberg为什么去了m$ 1996年，anders hejlsberg离开borland去了m$。在此之前，m$曾多次企图挖走anders， 但都没有成功。据信anders去m$(主要)不是钱的问题，虽然m$的开价也相当有吸引力： 130万美元年薪外加股票期权和分红，总计超过300万美元。主要原因是anders和delphi 开发组的其他成员在修改编译器的问题上发生了争执；还有，据borland内部人讲， anders认为自己不再是“不可缺少的人”。 虽然anders hejlsberg去了m$，我仍然尊敬他是一个天才，turbo pascal的主要作者， delphi的奠基者。 (ps：anders从1999年初就不在j++组了，而去做com+的开发。m$的人讲的) (4) m$产品的秘密 ＜1＞ msc最初是从at＆t买的授权； ＜2＞ vb的1，2，3版实际上不是m$开发的，而是cooper software开发的。john cooper 在m$时未受重用，离开后m$倒要花钱请他开发产品，真有点黑色幽默的味道； ＜3＞ ms sql server最初是买sybase的产品，6.5以前的ms sql server和sybase根本就 是一回事； ＜4＞ windows 95的主要技术负责人(名字我不记得了，不过在dejanews(www.deja.com) 上可能还能找到有关文章)是1990年从borland跳到m$的，不过他在1998年已经离开m$， 开了自己的公司； ＜5＞ windows nt的开发组整个是从dec挖来的，是以前做dec vms的那些人。所以在 win32平台上有很多vms的痕迹，比如说coff目标文件格式。 (5) .net到底是什么，bill gates也不知道 请看对bill gates的采访： 记者：现在，市场仍然对.net感到困惑。... .net的实质到底是什么？ 盖茨：.net是我们对下一代internet的设想。... 举个简单的例子，.net不仅允许你查 看自己喜爱的棒球队的时间安排，并且还能够对这个时间安排进一步加以利用。 (？？？究竟怎样“进一步加以利用”？为什么不说？难道现在的软件不能“进一步加 以利用”？) 6. 注： 本文系完全由作者本人所写，文中提到的所有技术数据均由本人验证或标明出处，转载 时请保持完整。 best regards herman wolfenswicz 对该文的评论 SuperFir (2000-12-11 18:34:38) 不错！我是个菜鸟！可我还准备学习vc6呢。 打击我！ lixiaolei (2000-12-6 13:31:34) 【www.delphi-jedi.org/】我为什么进步去？ yunn (2000-12-1 22:15:29) 同意笔者的意见 我也是三种工具都用很长的时间了，对vc++的感觉就是没有DELPHI好 哎，说起来，工具就是工具，就看你合适哪个了 GuXl (2000-12-1 15:50:17) Vc ＆ Delphi 都只不过是 工具 当然工具也要挑好用的用， 化大量时间去 训练人适应工具好像不大合宜吧 dogbear2000 (2000-12-1 11:41:08) 我非常喜欢你的文章，如果转载，需不需要付费？ r3000 (2000-12-1 10:38:24) 我以一个程序老兵的身份，象你致敬，说的非常好，不过， 有这样一个事实，delphi确实比VC强，VCL也确实强于MFC， 但大多数商业软件仍旧是使用VC开发的，并且有很多根本就是 用API开发的，所以一个所谓先进的技术，比如C++，比如面向对象， 并不代表开发出的东西是先进的，可能只是时髦而已。 所以我说，还是别比了，根本就是两回事， Delphi可能是摇滚乐，VB可能是流行乐， VC可能是严肃音乐，不能因为个人好恶否定任何一种。 也经常听初学者问：那种开发工具更好？ 我的回答是：不在工具而在人，人不行好琴也只出噪音！
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。