主题:[转帖][转]编程工具回忆
有许多朋友对我说他们对编程语言发展的历史很感兴趣,可惜的是这方面的资料少之之少。我本人也很喜欢看这方面的东西,李维的两篇作品《我的回忆和一些有趣的故事》以及《C++圣战》是我看到过的两篇非常好的文章。我想在这里以Basic、Pascal和C这三大编程语言在DOS/Windows平台上的发展为主题,把我所知道的和自己经历过的一些事情记录下来,同时尽量避免和李维的文章在内容上发生撞车的情形。我自己并没有很丰富的资料,也缺乏足够的阅历,不过片言只语亦可聊供一观。因为是靠着记忆写下的,并不敢保证所有内容都非常准确,如果您有发现任何谬误的地方,非常欢迎您的指正。
曾经有一度Basic是DOS操作系统上最风光的编程语言,而那时候各种各样的Basic编译器也可以说得上是百花齐放,包括IBM BASICA, Microsoft GW-Basic以及后来的QuickBasic,True Basic,连Borland也推出了Turbo系列的Turbo Basic,好不热闹。虽然我们现在常说Basic有这样那样的缺陷,然而在当时Basic却是非常强力的系统开发语言,比如可以用INTERRUPT语句调用DOS/BIOS中断(中断调用在DOS程序中的地位就好比是Windows下的API函数一样),也可以和汇编模块接口,所以即便是开发底层系统问题也不大。Microsoft在MS-DOS操作系统中还附带了一个QBasic(又是M$一贯的捆绑销售手段),可以看作是Microsoft QuickBasic的简化版本,目的是方便用户完成一些简单的任务,从中也可以大致看到Basic语言当年在DOS开发中的地位。
各个厂商的Basic编译器共同造就了Basic语言的繁荣景象,不过也带来了一些问题。其中最大的问题就是Basic语言缺乏一个统一的规范。当时的软件工程思想还停留在极为原始的时代,而各个厂商为了提高自己产品的竞争力,总是尽力向自己的Basic产品中加入各种各样的扩展,这些扩展没有任何标准,不可避免的造成了非常混乱的局面,也导致了移植性等诸多让人头疼的问题。这些问题到后来愈演愈烈,以至于Basic语言的发明人G。Kemeny和T。Kurty也觉得无法再坐视不理,终于有一天他们联名发表了一封措辞激烈的公开信,抨击他们所谓的“Street Basic”,认为这些“Street Basic”的所作所为是在污染Basic语言的纯洁性,并且是在把Basic程序员向坏的道路上引导。在和所抨击的对象中,首当其冲的就是IBM BASICA和Microsoft GW-Basic。两位大师所推崇的是自己所编写的True Basic,他们认为True Basic才是结构化良好、风格优美的Basic语言的代表。此信发表后引起了极大的反响,也促使许多程序员开始重新审视和反思Basic语言。遗憾的是,Basic并没有按照两位大师所设想的那样发展下去,在激烈的市场竞争中许多Basic编译器包括一度被看好的True Basic都相继倒下,再到后来,Borland推出的Turbo Pascal和Turbo C成功占领了大半开发工具市场,Basic语言也逐渐退居二线,从此宣告了Basic黄金时代的终结。
现在Visual Basic基本上是Basic语言在Windows平台上唯一的代言人了,有趣的是Visual Basic自从出世起就存在着极大的争议,激进的语言纯化论者认为Visual Basic是个怪胎,而实用主义者则觉得无所谓;并且Visual Basic的效率问题也一直是为人所诟病的焦点,其实Visual Basic自从5.0版本以后在效率上已经有了极大的提高,再非昔日吴下阿蒙。然而,有关Visual Basic“低效、迟缓”的说法仍然广泛流传,而且一直是反对者攻击Visual Basic的主要罪状,这倒是一个颇为有趣的现象。
有关Visual Basic是否“简单”的问题倒是可以多说两句。Microsoft原本推出Visual Basic的时候,为了强调它的简便易用而隐藏了很多细节,对于整日在SDK里面摸爬滚打的程序员来说,Visual Basic的出现着实让人眼前一亮,于是许多人欢呼:原来编程也可以这么简单。在这个时候,Visual Basic简直成了Windows程序员的苦海明灯。可是,随着Windows的不断发展,新技术和新功能层出不穷,而Visual Basic面对这些新问题的时候却显得有些捉襟见肘,“VB只不过是玩具语言”的讥评也在这时候出现了。Microsoft只好不断的向Visual Basic添加新关键字来扩展它的功能,可是这种做法多少有些削足适履的嫌疑,也引起了不少语言专家的批评。Visual Basic现在也变得非常复杂了,这在一定程度上可以说已经违背了Microsoft当初设计Visual Basic的初衷。
我本人对于“XX语言简单易学”这种说法抱着很大的怀疑态度。现实问题本来就是纷繁复杂的,所以任何致力于解决现实问题的程序语言也不可能非常简单。所谓“简单易学”者,要么是宣传口号,要么这种语言本身的功能就有所限制。(如果说某一特定领域的专有语言简单易学,那倒不是没有可能,比如Javascript这一类的脚本语言比起一般的程序设计语言来说就要简单的多。不过,要是将相关的其他网络编程元素一齐考虑进去,则即使是脚本语言也不是那么简单的。)
提到DOS平台上开发工具的历史就不能不提起Borland,正是这个公司推出的Turbo Pascal和Turbo C这两款神兵利器成功奠定了C和Pascal这两大编程语言在DOS/Windows平台上不可动摇的根基,也开创了Borland历史上最为意气风发的一段时期。Turbo Pascal和Turbo C也是世界上使用人数最多的编译器,以至于在很长一段时期内它们几乎成了Pascal和C的代名词。在Turbo Pascal和Turbo C中引进的集成开发环境(IDE)概念,至今仍然让我们受益良多。早期的Borland是一个高手云集的地方,在那里集中了大批技术精英,包括Microsoft在内的其他任何编译器厂商都没有像Borland那样的技术实力,所以Borland的名字在当时就是品质的保证。不过,经历了后来发展的曲折和动荡,许多最优秀的人才渐渐从Borland流失,他们中间一部分到了像Numega这样技术性很强的公司继续谋求发展,还有一部分则被Microsoft所挖走,可惜的是除了Anders Hejlsberg等少数顶尖人物之外,他们中绝大部分人都渐渐湮没无闻,想想也令人扼腕叹息。
在这个时期另外一个值得一提的名字是Watcom C++,要说起Watcom C++的兴起还不得不先说一点题外的话。我们知道Intel x86系列机器的基本地址定位是采用segment:offset这样的表达方法,不过这种方法其实是有许多弊端的,最典型的就是臭名卓著的“64k”限制,也就是说:任何代码段、数据段或者堆栈段的大小不得超过64k;任何动态分配的内存大小也不得超过64k。如果要跨段调用数据或者代码的话,又会引一连串难缠的问题。同时,这种内存寻址方式也限制了总共能够存取的内存大小不能超过1M,而实际上在DOS操作系统中,低端1M内存空间的高位(384k)要为设备驱动程序和ROM BIOS保留,所以真正留给程序的内存不足640K,要在这么有限的空间里编写程序简直就是带着镣铐跳舞。为了让程序员能够存取1M以上的内存,当时的多个厂商(包括IBM、Microsoft、Lotus等等)联合制定了一个扩充内存管理规范,这个规范的原理是将1M以上的内存划分成多个页面,程序员需要的时候可以换入指定的页面,不需要的时候再换出。(是不是很象Windows下面虚拟内存的概念?)不过这个规范实在是过于原始,原因之一是换入换出的操作步骤太过繁琐,另外,要程序员自己管理所有页面的分配和置换...呃,怎么说好呢...简直就不是人干的活。相应的,DOS下面的内存寻址也是麻烦的不得了,比如说光是指针就有near/far/huge模式的区别,而程序的内存模式也分成tiny/small/medium/large/huge/compact等等许多级别,如果稍微不注意这些地方的话,那DOS程序员要面对的就很可能是一场噩梦。(我就曾经有一段时间,被扩充内存、扩展内存、上位内存、高位内存、UMA、HMA、EMS、XMS这些看似相近,实际上大相径庭的名词弄得昏头转向不辨东西。)
在当时,不论是Borland还是Microsoft对这个问题都没有提供很好的解决方案,而Watcom C++的出现无疑是久旱逢干雨,被折磨得痛苦不堪的DOS程序员终于看到了一线曙光。Watcom C++的办法是让程序在所谓的“保护模式”下运行(其实Windows操作系统也是这么做的),在这种模式下无论存取多少内存都没有问题,并且方法也非常的简单。有一位老程序员在第一次用Watcom C++成功分配了整整1M内存的时候,这样形容他此刻的心情:“我感动得想哭!”这句话深深印在了我的脑海中,也让我联想起另外一位著名程序员的话:程序员的生活就是在痛苦的地狱和快乐的巅峰之间反复震荡,只有在这种生活中才能体会到人生的真义。闲云谭影日悠悠,物换星移几度秋。我们今天的程序员是否仍然能够体会到这种心情呢?
正是因为有了这么吸引人的功能,所以即使是在Borland虎视于前,Microsoft狼顾于后的C++开发工具市场上,Watcom C++仍然取得了辉煌的成功。特别是对于开发DOS下面的游戏来说,Watcom C++在相当长的时期内几乎是不二的选择。可惜的是Watcom缺乏一位有眼光的领导者,没有能够巩固和发扬Watcom C++的优势,在Windows兴盛以后逐渐失去了往日的光彩,最后在激烈的市场竞争中黯然出局,让许多曾经是Watcom忠实Fans的程序员空为之魂断神伤。
曾经有一度Basic是DOS操作系统上最风光的编程语言,而那时候各种各样的Basic编译器也可以说得上是百花齐放,包括IBM BASICA, Microsoft GW-Basic以及后来的QuickBasic,True Basic,连Borland也推出了Turbo系列的Turbo Basic,好不热闹。虽然我们现在常说Basic有这样那样的缺陷,然而在当时Basic却是非常强力的系统开发语言,比如可以用INTERRUPT语句调用DOS/BIOS中断(中断调用在DOS程序中的地位就好比是Windows下的API函数一样),也可以和汇编模块接口,所以即便是开发底层系统问题也不大。Microsoft在MS-DOS操作系统中还附带了一个QBasic(又是M$一贯的捆绑销售手段),可以看作是Microsoft QuickBasic的简化版本,目的是方便用户完成一些简单的任务,从中也可以大致看到Basic语言当年在DOS开发中的地位。
各个厂商的Basic编译器共同造就了Basic语言的繁荣景象,不过也带来了一些问题。其中最大的问题就是Basic语言缺乏一个统一的规范。当时的软件工程思想还停留在极为原始的时代,而各个厂商为了提高自己产品的竞争力,总是尽力向自己的Basic产品中加入各种各样的扩展,这些扩展没有任何标准,不可避免的造成了非常混乱的局面,也导致了移植性等诸多让人头疼的问题。这些问题到后来愈演愈烈,以至于Basic语言的发明人G。Kemeny和T。Kurty也觉得无法再坐视不理,终于有一天他们联名发表了一封措辞激烈的公开信,抨击他们所谓的“Street Basic”,认为这些“Street Basic”的所作所为是在污染Basic语言的纯洁性,并且是在把Basic程序员向坏的道路上引导。在和所抨击的对象中,首当其冲的就是IBM BASICA和Microsoft GW-Basic。两位大师所推崇的是自己所编写的True Basic,他们认为True Basic才是结构化良好、风格优美的Basic语言的代表。此信发表后引起了极大的反响,也促使许多程序员开始重新审视和反思Basic语言。遗憾的是,Basic并没有按照两位大师所设想的那样发展下去,在激烈的市场竞争中许多Basic编译器包括一度被看好的True Basic都相继倒下,再到后来,Borland推出的Turbo Pascal和Turbo C成功占领了大半开发工具市场,Basic语言也逐渐退居二线,从此宣告了Basic黄金时代的终结。
现在Visual Basic基本上是Basic语言在Windows平台上唯一的代言人了,有趣的是Visual Basic自从出世起就存在着极大的争议,激进的语言纯化论者认为Visual Basic是个怪胎,而实用主义者则觉得无所谓;并且Visual Basic的效率问题也一直是为人所诟病的焦点,其实Visual Basic自从5.0版本以后在效率上已经有了极大的提高,再非昔日吴下阿蒙。然而,有关Visual Basic“低效、迟缓”的说法仍然广泛流传,而且一直是反对者攻击Visual Basic的主要罪状,这倒是一个颇为有趣的现象。
有关Visual Basic是否“简单”的问题倒是可以多说两句。Microsoft原本推出Visual Basic的时候,为了强调它的简便易用而隐藏了很多细节,对于整日在SDK里面摸爬滚打的程序员来说,Visual Basic的出现着实让人眼前一亮,于是许多人欢呼:原来编程也可以这么简单。在这个时候,Visual Basic简直成了Windows程序员的苦海明灯。可是,随着Windows的不断发展,新技术和新功能层出不穷,而Visual Basic面对这些新问题的时候却显得有些捉襟见肘,“VB只不过是玩具语言”的讥评也在这时候出现了。Microsoft只好不断的向Visual Basic添加新关键字来扩展它的功能,可是这种做法多少有些削足适履的嫌疑,也引起了不少语言专家的批评。Visual Basic现在也变得非常复杂了,这在一定程度上可以说已经违背了Microsoft当初设计Visual Basic的初衷。
我本人对于“XX语言简单易学”这种说法抱着很大的怀疑态度。现实问题本来就是纷繁复杂的,所以任何致力于解决现实问题的程序语言也不可能非常简单。所谓“简单易学”者,要么是宣传口号,要么这种语言本身的功能就有所限制。(如果说某一特定领域的专有语言简单易学,那倒不是没有可能,比如Javascript这一类的脚本语言比起一般的程序设计语言来说就要简单的多。不过,要是将相关的其他网络编程元素一齐考虑进去,则即使是脚本语言也不是那么简单的。)
提到DOS平台上开发工具的历史就不能不提起Borland,正是这个公司推出的Turbo Pascal和Turbo C这两款神兵利器成功奠定了C和Pascal这两大编程语言在DOS/Windows平台上不可动摇的根基,也开创了Borland历史上最为意气风发的一段时期。Turbo Pascal和Turbo C也是世界上使用人数最多的编译器,以至于在很长一段时期内它们几乎成了Pascal和C的代名词。在Turbo Pascal和Turbo C中引进的集成开发环境(IDE)概念,至今仍然让我们受益良多。早期的Borland是一个高手云集的地方,在那里集中了大批技术精英,包括Microsoft在内的其他任何编译器厂商都没有像Borland那样的技术实力,所以Borland的名字在当时就是品质的保证。不过,经历了后来发展的曲折和动荡,许多最优秀的人才渐渐从Borland流失,他们中间一部分到了像Numega这样技术性很强的公司继续谋求发展,还有一部分则被Microsoft所挖走,可惜的是除了Anders Hejlsberg等少数顶尖人物之外,他们中绝大部分人都渐渐湮没无闻,想想也令人扼腕叹息。
在这个时期另外一个值得一提的名字是Watcom C++,要说起Watcom C++的兴起还不得不先说一点题外的话。我们知道Intel x86系列机器的基本地址定位是采用segment:offset这样的表达方法,不过这种方法其实是有许多弊端的,最典型的就是臭名卓著的“64k”限制,也就是说:任何代码段、数据段或者堆栈段的大小不得超过64k;任何动态分配的内存大小也不得超过64k。如果要跨段调用数据或者代码的话,又会引一连串难缠的问题。同时,这种内存寻址方式也限制了总共能够存取的内存大小不能超过1M,而实际上在DOS操作系统中,低端1M内存空间的高位(384k)要为设备驱动程序和ROM BIOS保留,所以真正留给程序的内存不足640K,要在这么有限的空间里编写程序简直就是带着镣铐跳舞。为了让程序员能够存取1M以上的内存,当时的多个厂商(包括IBM、Microsoft、Lotus等等)联合制定了一个扩充内存管理规范,这个规范的原理是将1M以上的内存划分成多个页面,程序员需要的时候可以换入指定的页面,不需要的时候再换出。(是不是很象Windows下面虚拟内存的概念?)不过这个规范实在是过于原始,原因之一是换入换出的操作步骤太过繁琐,另外,要程序员自己管理所有页面的分配和置换...呃,怎么说好呢...简直就不是人干的活。相应的,DOS下面的内存寻址也是麻烦的不得了,比如说光是指针就有near/far/huge模式的区别,而程序的内存模式也分成tiny/small/medium/large/huge/compact等等许多级别,如果稍微不注意这些地方的话,那DOS程序员要面对的就很可能是一场噩梦。(我就曾经有一段时间,被扩充内存、扩展内存、上位内存、高位内存、UMA、HMA、EMS、XMS这些看似相近,实际上大相径庭的名词弄得昏头转向不辨东西。)
在当时,不论是Borland还是Microsoft对这个问题都没有提供很好的解决方案,而Watcom C++的出现无疑是久旱逢干雨,被折磨得痛苦不堪的DOS程序员终于看到了一线曙光。Watcom C++的办法是让程序在所谓的“保护模式”下运行(其实Windows操作系统也是这么做的),在这种模式下无论存取多少内存都没有问题,并且方法也非常的简单。有一位老程序员在第一次用Watcom C++成功分配了整整1M内存的时候,这样形容他此刻的心情:“我感动得想哭!”这句话深深印在了我的脑海中,也让我联想起另外一位著名程序员的话:程序员的生活就是在痛苦的地狱和快乐的巅峰之间反复震荡,只有在这种生活中才能体会到人生的真义。闲云谭影日悠悠,物换星移几度秋。我们今天的程序员是否仍然能够体会到这种心情呢?
正是因为有了这么吸引人的功能,所以即使是在Borland虎视于前,Microsoft狼顾于后的C++开发工具市场上,Watcom C++仍然取得了辉煌的成功。特别是对于开发DOS下面的游戏来说,Watcom C++在相当长的时期内几乎是不二的选择。可惜的是Watcom缺乏一位有眼光的领导者,没有能够巩固和发扬Watcom C++的优势,在Windows兴盛以后逐渐失去了往日的光彩,最后在激烈的市场竞争中黯然出局,让许多曾经是Watcom忠实Fans的程序员空为之魂断神伤。