按键盘上方向键 ← 或 → 可快速上下翻页，按键盘上的 Enter 键可回到本书目录页，按键盘上方向键 ↑ 可回到本页顶部！
————未阅读完？加入书签已便下次继续阅读！
不过最后还是长久妥协了，他自己也知道图形界面只是手段并不是目的，为了日后不受那无穷无尽bug的影响，还是让乔伊主持工作。
研究院目前设计的图形工作站的配置异常的强大，在尽力减少成本的情况下做到了可以支持双k32处理器动态共享存储，在ec机基础上还设计了一条独立的图形总线，独立设计制造的2维图形加速卡，最低2兆的内存，高速磁盘。
在那个时代这些硬件可算是梦幻般的配置了，研究院的几百号人空前的团结主要原因也基于此——打造这个世界上最顶级最小巧最好用的计算机。
徐志行一向都是非常的警惕研究院的人员心理动向，如同一个母兽一般守护着自己的领地，让他百思不得其解的是研究院的人员虽然五花八门，怀着各种各样的心思组合到了一起，却没有出现任何军心不稳的现象，甚至没有一个人被其它公司挖走，哪怕给的待遇更高。
这个问题直到最后才有了一个模糊的答案，那就是这些家伙都是一帮技术狂人，光配置图形工作站就让他们的心理得到了极大的满足，最具代表性的言论莫过于自称第一黑客的菲斯奈尔的话了：“ibm算什么，自从五年前他们就不发布大型机了，技术可想而知，再说了我可不想穿着那一身蓝色的狗皮工作，不符合我的美学。至于苹果，我看不惯乔布斯的嚣张样子，仅此而已。只有ec平台才是我的选择，当然了它还不够强，不过这并不重要，我会让它在我的手上成为第一的。”
秉承着这个意念，这些家伙分工合作，飞速的完成着他们的梦想。
双处理器并行工作并不是难事，反而是k系列的传统，这项技术几乎成了招牌。至于独立的图形总线是长久建议的，虽说增加了成本，但是对于性能至上的诠释无与伦比。
2兆内存就比较麻烦，鉴于这个时代的工艺条件，内存芯片不得不焊装在一块大板子上，然后才能插在系统主板上，因为需要的芯片太多了，用数字来表示就是需要0。25平方米的电路板双面焊接才能容纳下这么多的内存模块。
至于硬盘，这些家伙毫不犹豫的就选择了scsi接口，理由就是快。
有时候长久甚至怀疑这些家伙并不是在设计工作站，而是在制造小型机，要知道就连现在主流的vax小型机也不过才配了1兆内存，有些性能还不如单处理器的ec机。
真是有了完备的硬件支持，乔伊才得以在操作系统上实现了各种技术，包括内存分页、映射，支持各种各样的商业性软件。
以上的工作进展的很快，因为都是一些成熟的技术，相当于搭积木。真正有难度的则是图形加速卡的设计制造，另外还有相应的图形软件编写，毕竟机器性能再高，没有应用软件也不过是一堆废铁。
~~~~~~~~~
预定下周点击、鲜花、推荐、订阅，呵呵
一百八十三
这部分的技术都由沃洛克领导，或者应该讲约翰博士，他喜欢人们这么叫。作为一名资深的parc成员，他了解计算机图形学的每一个细节，甚至在他上大学的时候就曾经独立的写出了一个消隐算法。
字符型的操作系统是不讲究什么二维三维的，比如dos、godson，它们只需要显示文本就可以了，具体的操作全由处理器完成，内存中移动的都是一行行的命令与文字。
到了图形界面时代，这就是个灾难，窗口的出现让cpu苦不堪言。经典的mac就是这样，所有图形的绘制工作都是由我们伟大而神圣的68完成的，任劳任怨，让我们对它表示一下敬意。一般的处理流程是这样的：
所有图形的显示都是一行一行的，因此cpu先是在内存中寻找窗口的地址，然后将每一行的数据拷贝到目的地显示，重复这一工作知道一个窗口显示完成。
因此当一个窗口图形很大的时候，cpu的工作量则是成正比的增长，而我们每完成一个移动的操作都会让cpu重复这一过程，可以想见若是cpu不强劲那效果会是如何。
还有一个问题那就是内存，窗口所有的数据都是先在内存中然后被画到显示器上，这得占用不少的资源，这就是为什么512k内存的pc机不能支持windows系统，而mac则慢如蜗牛的原因。
沃洛克带领的开发小组则借鉴了游戏机的加速原理，利用专门的显示芯片来加速处理这部分图形数据，配合本已强大的k32处理器，立即让工作站如虎添翼。
至于mit研究的窗口系统，这其中还有个故事。
话说经苏教授的穿针引线，长久投资了一笔钱，将图形操作界面的开发任务交给了mit研究室，谁知道左等不来右等还是没影，每次询问的结果都是一个回答：版本不高，不宜发布。
一次两次长久还能容忍，但是都到了85年这玩意还磨磨蹭蹭就有点不对劲了，mit研究室不出成果要钱还要的特别狠，这就让长久很不爽，于是特地去做了一次考评，结果却让他差点气歪了鼻子。
原来在mit的实验室中，这套被命名为x…window的图形界面已经具备了基本的形态，说的不客气点，就算拿出去卖都可以算是一个成功的产品，可是mit研究室却死死扣着不发。
他们的理由很简单，x…window计划的主要目的就是要在所有运行unix的机器上完美实现，现在这个版本依旧没有达到这个标准，因此不宜发行。
长久了解了来龙去脉之后才恍然大悟，感情mit研究室做的是这个工作，人家并不是专为vs工作的，同时还为dec服务，而且还优先于vs。
我说咋这么便宜那，感情着这家伙到处拉赞助啊，长久暗想。mit的人解释道，这个项目难处在于要制定一个图形界面的标准，兼容所有的unix机器及其变种，因此才要花大力气测试，时间就是这么消耗的。
听了mit的解释，长久抹了一把汗，乖乖，好伟大的理想，可是咱不是那种胸怀世界的人，你们自己玩去吧。
于是一怒之下，长久要求收回投资，mit的人自然不肯，漫天要价就地还钱，这才加了点钱购买了这套半成品的所有技术。
后来长久才知道x…window并不是mit原创，他们是从斯坦福得到了一个实验性的视窗系统叫w，加以改进到足够的区别之后才改名x的。
有了这个发现长久顺藤摸瓜，由沃洛克博士出面找到了这套w视窗系统的研究人员，许以重利挖来继续开发图形界面。
长久完全抛弃了mit那套过于理想化的做法，居然想兼容所有unix变种，这简直荒唐，商业化的unix系统五花八门，各家公司为了自己的利益总想着和别人不兼容，如何能统一？
因此长久让沃洛克的图形开发小组全面的修改x视窗系统，坚决的要打击这种洒水式的兼容方式，一切要以现在研发的工作站、ec平台及386为优化对象。
得到了x视窗系统的所有资料之后，长久也专门下了一番功夫，不得不承认这是专门为了小型机和工作站设计的。
同mac系统和windows那样的高集成度的图形系统不同，mit的人将这套x视窗系统分为了三个部分，服务端、客户端和通信函数库。
其中服务端就相当于总控硬件的显示程序，它接收服务端的绘图指令操作硬件完成绘图任务，将得到的数据传输给客户端。客户端不需要接触硬件指令，只需要请求、显示即可。
因此理论上只要硬件足够强大，可以运行许多服务端、客户端而互不干扰，颇有点服务器的意思。
而最让人惊讶的是x视窗系统仅提供基础的系统调用，长久第一感觉则是应该将之封闭起来提供一个图形api函数库，这样可以做成一个开发工具包，让那些程序员们不需要一步步的使用那些基础调用，简化编程工作量缩短开发时间。
在长久的示意下，沃洛克小组开发了一组图形套件，提供了菜单、按钮、对话框等图形接口的标准构件，还提供基本的视窗管理器，所有使用这套基本构件的程序员都可以非常轻松的创建一个视窗程序。
为了配合图形系统，长久发动了大批的程序员对现有程序进行移植和图形化包装，包括正在开发中的vs…office85系列套件。
长久厌烦了1。0、2。0式的版本命名方法，以年份命名简单直观，非常的平易近人，已经提出立即让所有人全票通过，因此就这么顺理成章的用来了公司的主力产品office系列上。
vs…of