第贰拾壹章 太监们 （上）
对于Unix的前景，范含是很清楚的，只不过，光想想确实挺美，真干起来就不一样了，开始的时候，简直不知道从何下手。 如果光是谈论“开发新型cao作系统的重要意义”，或者介绍一下自己“对于新型cao作系统的初步构想”，这个范含不怵。现在的范含有把握侃晕业界所有的“电子工程师”们和“数学家”们。 人力物力也不是问题。自己就是实权人物，可以调动FOR的全体员工以及通过奥尔森调动DEC相关产品线上的大部分人；最近的FEEE在Kervin机上面也是获利颇丰，手里攥着大把的现金。 可是眼下就是这么一个尴尬的局面：钱有的是，不知道怎么花，人也足够，不知道怎么用。刚刚动员起来的这个“OS组”没有任何计划任务，都在眼巴巴的等着范含的“最高指示”。 第一步到底应该先干什么，心里没谱。乍一看好像哪个都挺重要，再一看好像哪个都有前提条件。Unix/Linux不是微内核结构，几个主要模块彼此互相依赖，扭做一团。对于自己这样的旁观者而言，仅仅通过BROM里面那些带注释的源代码就判断出哪里是起点，确实有点难。 范含最早写的Linux程序是个显示器驱动，在那之前都是用用Shell，写点儿命令行程序。直到第一回敲入“startx”，打算进入图形界面的时候，觉得分辨率和刷新率太低，不爽。X的配置怎么都达到不了Windows下面的效果。看来根本原因是由于系统识别不出自己的那个杂牌显示器，当时Linux下面的驱动程序还远远不如Windows丰富。没办法，自己动手，丰衣足食。先找了个最接近的驱动当模板，然后慢慢改。 如果是正规的显示器，都应该有保护电路的。一旦监测到不对劲，就会在黑屏正中显示一行字：“参数超出范围”。但是范含当年很穷，为了少饿几顿就买了个便宜货，这一块肯定是被厂商省掉了。于是，一次修改之后，连个招呼都没打，“嗞”的一声就青烟缭绕了。 从此之后，对于驱动程序以及其它硬件相关的部分，范含一向敬而远之，更别提内核了。所以直到现在也没有多少“系统开发经验”，写过的东西都是“应用程序”。 现在的情况好一些，和硬件交互的代码完全可以交给底下人来做，自己只要考虑所谓“高端体系”即可。问题是，现成的代码肯定用不上，凭空写又找不到着手点。 Linus最初写Linux的时候就不是“凭空”开发，参考了当时大学里面流行的“Minix”代码，一个为了教学目的开发出来的微内核体系。而这个Minix，又是参考了Unix的设计方案，去掉那些所谓“臃肿”的部分。至于“Unix”，现在的Bell实验室的那个Ken还没写出来呢。 典型的“鸡生蛋，蛋生鸡”的问题。 不要说现在，就是在二十一世纪，随便找个cao作系统大拿，直截了当的问他：“给一个新的体系写cao作系统，你打算先写什么？”多半会张口结舌。不张口结舌的人多半也会反问，“移植现成的Linux代码不好么？” 移植是一码事，凭空写是另一码事。动手之初就能把所有错综复杂的关系弄清楚，这是很难得的本事。对于“Architect”的工资比“Coder”高很多这一事实，只有小白才会不服。 现在的范含还差的远。 所以现在的范含头大如斗。 ------- 头疼之余，赶紧去图书馆充电，找几本cao作系统理论方面的书看看。自己对于计算机发展的早期了解得太少了，平时吹牛还可以，一到动真格的时候就不灵了。 转了一圈，没找到。 意料之中。 本来，自打IBMSystem360研制成功，计算机才算是有了“真正的cao作系统”；自打Unix开始，“真正的cao作系统理论”才算出现。现在当然不会有什么人写这个方面的书。 但是……不甘心，范含一直就在UCLA校图书馆里面转来转去。对于这类专业书籍，如果洛杉矶市图书馆里面有，那么校图书馆当然也会有，而且肯定数量更多质量更高；如果连大学的图书馆都没有的话，市图书馆恐怕更不会有……所以范含根本就没去。 以前陪着老头子来过无数次了，早就混了个脸儿熟，碰上管理员都是打个招呼，然后直接进去查卡片。其实普通的校外人士一般不让这么随便的，这还和市图书馆不一样。 今天有点不一样，楼道里面溜达的管理员有点少，想找个人问问还得走挺远。 “人都干嘛去了？”范含逮着一个mm管理员就问。 “整理卡片，录入资料。”那mm回答，“我们的查询系统要改用计算机了。” “啊？”范含大吃一惊，“带我过去看看？” 这事儿自己怎么不知道？ UCLA的校图书馆和自己一点关系没有，他们愿意干什么就干什么，没有非得通知自己的义务。不过从另一个角度讲，这样一个系统的研制成功，在当前的技术条件下，应该算是软件行业一个了不起的突破。况且UCLA已经决定部署了，馆方应该是对其极为满意才是。 图书馆的查询系统，是很典型的“管理信息系统”，在自己的那个时代，无数教材和技术书籍都拿这个当例子，应该已经被无数人使用无数语言和开发工具实现过无数遍了。 按理说，自己不应该一点消息没有。 脸儿熟就是好办事，mm二话没说，领着范含进了办公室。 IBMSystem360？！ 虽然没见着主机，不过远远一看终端的形状就能认出来。现在的范含对业界各个公司的机器还是很熟悉的，这要是搁以后，肯定已经达到了应聘“中关村电子农贸市场”柜台人员的基本要求。 我日你先人的板板！范含暗骂，这是住四年宿舍学会的少数几句方言之一，都是自己不耻下问，跟四川的同学们请教而来的。 怎么又是它？IBM还真是阴魂不散！ 这时候范含已经有了预感，恐怕今后自己的整个一部创业史，就是一部和IBM的斗争史。面对强权，不屈不挠，屡败屡战，最终杀出一条血路，开创了属于自己的一片新天地。 “他们身处逆境乱世，自然磨炼成为英雄”。 这种杀手级应用，会把某种硬件体系的用户牢牢拴住，同时还会吸引其他体系的用户宁可付出转换硬件的代价也要立刻部署。这绝对不是范含希望看到的局面。 况且，像图书馆管理系统这样的软件，其需求都是固定的，没有什么改进的余地。这个系统的成功，至少可以证明，IBM的数据库应用已经相当成熟。一旦有了一个成功的范例，就可以在很大程度上影响其他公司的采购决策。作为后来者，想要后来居上，功能和稳定性必须得强大的多，做到这一点殊为不易。 走近点一看，好像和自己想象得不太一样。 在自己的印象里，应该和原来上大学的时候图书馆里面的系统差不多：UCDOS下面的蓝底白字的界面，可以按书名、作者、出版社什么的分类查询。 但这个好像不是。 屏幕上显示的就是一张“卡片”，每段文本的位置都和真正的卡片上一模一样。只不过，有的文本下面有一条下划线。 “这个……”范含伸手去点，这是网虫的毛病，一看见下划线就犯。 “不是用手点的啦！”那mm提醒，然后用方向键把光标移动到那行字上面。 光标只能在带下划线的文本之间移动，移动到哪里，哪里的文本就反色，变成白底黑字。 这不是网页么？ 这么一想，范含有点印象了，原来曾经见过一个文本界面的浏览器“Lynx”，差不多就是这个样子。 在互联网的早期，这种界面是理所当然，只是随着后来技术的进步，网页上面有了图像、表格之类的复杂构件，渐渐的被图形界面浏览器取代了。不过以前看过一本书，里面有一节，专门讲如何设计对Lynx友好的网页。理由很简单，在目前这类文本界面浏览器还有存在的必要，比如和一个文本朗读引擎配合起来，使得盲人也可以上网冲浪。 当时范含一时好奇，就下载了一个玩玩。结果发现，一些所谓“门户网站”的主页，看上去简直乱得一塌糊涂。只有Google之类的站点很好看，当然，这也是由于那些页面过于简单的缘故。倒是一些公益站点、非营利机构、社团的主页，用IE看也很漂亮，用Lynx看则同样的美观。 除非自己也瞎了，否则就意识不到世界上还有盲人；除非盲人也是客户，否则就不考虑他们的需求。合法、合理，就是不合情。 “你们这个系统用的数据库是什么？”范含问。 “我不懂啦！”mm笑着回答，“技术问题我一窍不通。” “没有数据库。”旁边有一位“阿姨”回答，“每张卡片就是一个文件。” 范含扭头，看到旁边一台终端前面，那位阿姨正在输入什么。 本来以为就是HTML那样的一堆尖括号，走过去一看，不是。正常文本之间有一堆奇怪的符号和各种控制字符。也对，这时候HTML还没出现呢。 每本书都有唯一的书号，所以可以存成一个文件，以后再也不用修改，范含想。存储作者和出版社的文件可能会时常更新，添加内容。这么一来，这套系统就像是一个网站的布局那样。 维护这些文件和维护数据库，哪个更烦？对于这些管理员来说，维护文件应该和原来维护卡片有点像，恐怕更容易接受一点。这样一来，还可以省下购买数据库系统的大笔经费。在当前数据库系统还十分昂贵的情况下，这么干也还说得过去。 “这个系统是从IBM那里买的？”范含又问，这个问题才重要。 “不是，”那位阿姨回答，“这本来是布朗大学的一个项目，我们学校有人和他们合作。” 仔细一打听，UCLA电子工程专业的一帮人挑头引进了这套系统。 以前自己怎么把他们忽略了？范含很后悔。 由于MS项目的原因，一直以来，自己在UCLA都是只和数学系打交道，和这些真正能造计算机的人反而没有来往。当然的，他们干点什么也没必要非得通知自己一声。 失策，真是失策。 ------- 回家路上，范含拼命搜索BROM，关键字是“布朗大学”。 世界上第一个实用的超文本系统是美国布朗大学在1967年为研究及教学开发的“超文本编辑系统”。之后，布朗大学于1968年又开发了第二个超文本系统“文件检索编辑系统PRESS”。这两个早期的系统已经具备了基本的超文本特性：链接、跳转等等，不过用户界面都是文字式的。 所谓超文本，就是电子文档的一种，其中的文字包含有可以链接到其他字段或者文档的超文本链接，允许从当前阅读位置直接切换到超文本链接所指向的文字。“超文本”这个词在英语词典上并不存在，是美国人泰得纳尔逊于1965年杜撰的。 由于几乎每篇论文后面都会引用一大堆其他论文，如果按照顺序一篇一篇的找，确实没有直接跳转过去方便。这类系统从诞生之日起，就有它存在的必要。布朗大学的一干人等正是正视了这个需求，才开发了这个系统。 看来历史在这里有个小小的转折，UCLA里面这些被范含冷落的未来的电子工程师们，面对数学系的同学和FOR合作边写论文边打工，名利双收的局面，终于不堪平庸，奋发图强，努力证实自己的价值。 嗯！证实的好！范含想，让我知道了这个消息，也算没白来一趟。 既然这个系统不是自己想象中的那个数据库应用，说明情况还不算太坏。并且这个系统并不是IBM开发的，说明IBM的思想还没那么前卫。不过，这个系统已经成功运行在IBMSystem360上这件事本身，说明迟早有一天IBM会开始开发类似系统。 自己一定要抓紧。 只要一提到“超文本”，范含立刻就会联想到“超文本链接语言”。这种语言几乎是钦定的描述“超文本”的工具。最明显的特征就是那个“下划线”。 以前总觉得采用添加下划线来表示超文本的方式天经地义，今天亲眼目睹了这样一个早期系统，终于感觉到前辈们决定采用这种方式的无可奈何与理所当然。 那些“后世图形界面浏览器”里面的文字，都是和其他图形界面程序一样，是画出来的。反正画什么也是画，所以随便改字体也无所谓。但是对于字符终端而言，每个字符都采用事先烧入ROM里面的等宽点阵字体，直接拍在屏幕上。在这种情况下，就算是同一种字体族，仅仅采用粗体或斜体，实际上都需要更改点阵，肯定会涉及到字符位置的重新计算。相比之下，字体不变而改换颜色反而更容易一些。但是目前最通用的是单色终端，并且这种系统的设计从一开始就决定了不能依赖颜色。于是，下划线几乎是唯一可能的解决方案。每打出一个字符，在下面多一条线，还是可以轻松办到的。 这些事实都在提醒范含，尽快设计HTML，规范化超文本的表现形式，利人利己。 不过……HTML由于历史的原因，设计的太随意了些。这种随意曾经让范含吃尽了苦头。 以前范含搜集资料的时候，遇到了一个“国学网”，里面都是各种国学古籍。曾经兴高采烈的从网页上面复制文字，存成文本。但是打开一看，每行后面都多了一个字。基本上就是“知”、“古”、“斋”、“主”四个字轮换使用。仔细分析网页源代码，发现这个多余的字的确是原来就有，只不过颜色设置和背景色相同，在浏览器中看不出来而已。 对于这样做的动机，范含是可以理解的。毕竟辛辛苦苦做成网页，不希望其他竞争站点原封不动拿走就用。但是对于这种手段，范含是不支持的。毕竟这些古籍的著作权属于死人，版权不属于任何活人。要么您就别贴出来，要么您就贴图，像现在这么干，只会给一些查找资料的人制造困难。 况且这类手段别说难不住“竞争站点”，甚至难不住范含这厮。范含把所有网页下载完毕之后，专门用Perl写了个脚本，读入网页，输出文本，顺便除掉中间的这些垃圾。 写脚本的时候就意识到了HTML的不规范所带来的麻烦。 首先，标签关键字不区分大小写。处理这个就很费劲。 其次，许多标签可以闭合，也可以不闭合。比如表示段落的“”，可以单独出现，也可以和结束标签“”成对出现。处理这个也很费劲。 再次，标签属性值的引号可用可不用。比如“color=”red””，也可以写成“color=red”。处理这个最费劲。 还有其他许多地方需要范含费劲，虱子多了不咬，债多了不愁，至于那些地方到底是哪些地方，现在的范含大人大量……已经忘了。 这还是自己专门针对一套模板做出来的网页写分析程序，已经痛不欲生。对于专门写浏览器，必须分析所有可能的HTML格式的那些家伙们，郁闷到何等地步应该是可以想象的。 所以到了后来，xhtml标准出现，范含几乎是举双手双脚赞成，巴不得全天下的页面都是如此规范。 所谓“xhtml”，其实就是用xml语法规范化的html，每个xhtml文件都是一个标准的xml文件。处理这样的文件当然会很轻松。 范含最欣赏xml的地方，就是它很“规范”。上面提到的那些html的缺陷，xml一概没有。 比如大小写问题，xml是区分的。这个就有它的必然原因……在Unicode里面处理大小写，实在是太他妈的的烦了！ 不说阿拉伯文没有大小写。不说东亚的象形文字、也不说泰文、梵文、希腊文、俄文字母。就是采用拉丁字母的语言，除了英语、意大利语这类不采用重音符号的文字之外，都会很烦。 比如德文，大写字母29个，小写字母30个。多出来的那个小写字母，形状类似希腊文的Beta，实际上是“ss”的合写。这个字母不会出现在字头，也就没有大写形式，一旦需要大写……比如文章标题全部字母大写的情况……就必须用“SS”两个字母代替。 总之，对于xml这种主要是让程序来阅读的文件，语法规则越简单越规范越好。其实html不也是让浏览器用的么？理论上最终用户没有必要非得阅读网页的源代码呀！那为什么当初要设计成这样？！ 范含早就在幻想，如果时光能倒流，自己一定会仔细设计html规范，以便造福无数“后世程序员”。现在真的回来了，自然是打算兑现诺言。 不如一上来就直接推出xml吧，然后派生出一个html的子集，这样以后干什么都好说。 可是……这个xml也不是凭空出现的，而是另一个更大更复杂的SGML的子集。 这个SGML，是历史上的IBM从1969年开始制定的。 又是IBM？！ 我日你先人的板板！！ -------