William Cui's Blogsphere

作者是个当过老师的程序员，名字叫《十年MFC经历认识的Microsoft技术》。大概看了看，感觉前两节还是有一些信息量的，后面的内容就东一榔头西一棒了，再往后推介自己的开源软件了，就更不成话了。 作者说“看到微软资料很多，感觉这个公司很有厚度”，其实开源社区的代码、文档也是浩如烟海的。在信息时代的IT行业，信息多一些实在不足为奇，要点是如何快速找到并掌握自己需要的信息。普通程序员不关心应该如何评价微软，不过这些稗官野史看看也无妨。

一、初识MFC

我最初知道MFC大概是在1993年，那个时候Visual C++还没面世，当时Microsoft的C++编译器还很弱，官方的名字是Microsoft C/C++ 7.0，MFC的版本是1.0，几乎没有引起什么反响，那个时期最好的C++开发环境是Borland C++ 3.1，其实，大概是1992年11月份，一个偶然的机会，我领略到Borland公司的厉害，记不得在什么地方，我看到一个绝妙的集成开发环境，即 Turbo C++ 3.0 for Windows，这是我记忆中第一个真正的Windows环境下的C++集成开发环境，那种激动的感觉至今仍记忆犹新，不客气的说，当时至少在C++方面，Microsoft与Borland不是一个水平的，Borland明显的要高于Microsoft ，Borland的产品在技术上给我留下深刻的印象。那个时候Microsoft最好的开发平台是Visual Basic 3.0，而Borland的Delphi正处于开发阶段（Delphi 的代码名称是：“VB Killer”）……，想起这些十几年前的往事，我不禁感慨万千。

十几年来，我用过许多开发环境，关于Visual Basic，我用过最早的DOS版本，Windows版的Visual Basic我基本上全都用过，至今我还记得每个版本的VB安装盘磁盘的盘数。同样，我用过各个版本的Delphi，特别是Delphi 2.0，给我留下极好的印象。Delphi提供真正编译的可视化开发环境，那个时候（1994年左右），Delphi就可以开发带有GUI的动态链接库，你可以想象，在Microsoft Access 2.0的应用程序中可以加载一个Delphi Form并进行程序交互，那种感觉真是棒极了。

Borland C++是我心中无法抹掉的遗憾，从Turbo C到C++ Builder，我深刻的体验到Borland的辉煌和无奈，Delphi从VB Killer走到为VB护航（你可以想象Delphi一步到位的ActiveX 控件开发技术有多牛，早期的VB有多土，早期的VB不能开发动态链接库，因此无法开发ActiveX 控件，想起来真令人嘘唏不已），Borland C++的命运也是不济。Borland C++ 3.1的辉煌永远不再了，十几年的开发工作中，我在C++上投入了大量的精力，Borland C++曾经给我带来无数的激动，然而这个经典的名字却在与Microsoft的竞争中渐渐的流逝了……。

MFC4.0的出现，使得人们感觉Microsoft在C++方面赶上来了，这一版的MFC是Win95推出后出现在Visual C++ 4中（Microsoft没有VC 3，VC4以前的版本是2.2、2.1、2.0、1.51、1.5、1.0）。也许是对Borland C++的潜意识的失望，我不知不觉的接受了MFC，VC 4.2推出时，我通过正常渠道购买了这个编译器的企业版。

二、关于Microsoft

关于Microsoft，有无数的人要对这个名字叙说感觉，这个令人讨厌的名字！不知道是喜欢还是憎恶，你是程序员，你的心思可能就要因 Microsoft的存在而动，即使你用Linux，你可能也是因为Microsoft技术因素。多少年来，这个名字每天都出现在你、我、他的面前，因为你不得不面对Windows的存在，可是你憎恨这个名字吗？你讨厌这个名字吗？我不知道是否已经对这个名字麻木了。1998年我个人订了 Microsoft MSDN Universal 版，我开始比较全面接触这个公司的开发技术，你可以想象，1998年当你面对上百张技术光盘的时候，你就知道什么叫做“厚度”，当我们有时说出“赶上”或 “达到”Microsoft某些产品的水平的时候，可能我们缺乏对这个公司“厚度”的真实了解。进入MSDN，我感觉Microsoft简直不是一个“公司”，而是（或者正在形成）一个“社会”。当时著名的技术网站http://www.codeguru.com全部的技术资料是可下载的（那个时候 http://www.codeguru.com提供整个网站内容下载服务，大约3M左右），大名鼎鼎的www.codeproject.com还不存在。一开始，我始终潜意识在技术上对比Microsoft与Borland，应当说技术上Borland不比Microsoft弱，即使现在也有人持有这个看法，可是为什么Borland走到今天这个地步？而Microsoft却如日中天？若干年前，这两个公司竞争何等激烈，而现在却是另一番“合作”的景象？可能很多人想过，如果Borland不存在，对Microsoft不是更有力吗？其实Microsoft可能精通中国历史，读过《三国》、十分了解战国时期的中国，其实Borland形式上的存在，对Microsoft是十分有利的，至少形式上还有竞争对手，而事实上Borland已经受控于 Microsoft（Microsoft是Borland的大股东）。你可以看到一些微妙的现象：Borland为Microsoft提供了大量的人才，其中包括Delphi总设计师以及Borland C++编译器的核心成员；同时也为Microsoft .NET提供强有力的护航服务（看看C# Builder、Delphi .NET）。1998年Microsoft 的COM技术基本已经成熟，这个技术使人感到震撼，当时Microsoft的对手们提出“OpenDoc”用于对抗“COM”，你看看“OpenDoc” 阵营的几个成员：IBM、Apple、Borland、Novell，你会感到这个阵营十分豪华、强大。但结果却差强人意，“OpenDoc”无疾而终，而“COM”依然生机勃勃。

有人说“COM”没落了，那么就太不了解Microsoft了。在与“OpenDoc”的竞争中，“COM”是个彻底的胜利者，在与“Java”的竞争中，“COM”成功的进化了，在这个过程中Microsoft体现了强大的吸收能力、以及无法想象的韧劲。.NET只不过是COM的“别名”而已。对于一个经验丰富的C++程序员而言，.NET就是COM的进化，而Microsoft内部.NET就是“COM 3.0”（OLE2就是COM 2.0），而“CLR”就是一个不择不扣的COM对象。曾经有人问我，既然牛顿时代就奠定了基础（想想著名的牛顿-莱布尼茨公式），几百年后的今天，数学还研究“微积分”吗？回答当然是依然在研究！“微积分”早期是针对函数的，现代“微积分”是针对“流形（Manifold）、纤维丛（Fiber Bundle）”的，概念深奥了，可是基本思想不变，只是“微积分”的思想得到合理的延拓与进化，你了解Microsoft吗？Microsoft Research有一批超一流的数学家在为Microsoft工作，其中一些是斐尔兹奖的得主，Microsoft正在实现如同“微积分”进化到“微分流形”一样将“COM”进化到“.NET”。从科学概念角度上分析COM与Java，可能COM更全面、精确，从实现的成熟度上Java可能更成熟，可是你看到，Microsoft正在不紧不慢的追赶。Microsoft令人联想起战国时期的强秦。

战国时期的秦国，采取“远交近攻”“抚弱掠强”等措施傲视六国，今天的Microsoft也是这样，VB1.0时，Microsoft推出“VBX”控件技术，众多的小公司得以生存，Microsoft自己不开发“VBX”组件，同样“VBX”进化为“OCX”时，Microsoft并不十分强大，可是这种试探得到众多小公司的响应。1997年Microsoft Office 97、1998年Microsoft推出Visual Studio 6.0，给众多中、小公司提供了生存、发展的机会，例如Microsoft Office 97中集成了Visual Basic for Application 5.0，这项技术使得几百家软件开发商与Microsoft签署了VBA技术许可协议，即使AutoDesk这样的公司都与Microsoft签署了这个协议，这个协议使得每个集成VBA的产品的给个用户许可为Microsoft付40$的许可费，如果你了解VSIP（Visual Studio Integration Protocol）协议，以及有多少公司签订了VSIP协议，你就真正感觉到Microsoft的可怕；Microsoft Office 97、Visual Studio 6.0的用户界面十分漂亮，为什么Microsoft自己的开发工具不提供类似的软件组件？你看到众多第三方的Microsoft盟友纷纷推出自己的界面库以模仿Microsoft，他们不会反对Microsoft，因为他们已经形成了使得Microsoft以及这些公司得以生存的生态圈。

Microsoft的技术储备有多少，Microsoft之外的人很难说清楚，Microsoft中国公司也未必了解多少，1999年WTL类库刚刚出现的时候，人们就希望WTL能得到官方的支持，或授权给一个Microsoft之外的一个公司（你能想象出Borland C++ 5.0内置的ActiveX开发机制是基于Microsoft ATL类库吗？），直到今天，WTL依然如故，我们完全相信，如果Microsoft强力推广WTL，WTL完全可以流行，可是Microsoft不缺类似的技术，类似的类库还有BCL(Base Control Library，一个用于开发轻量级ActiveX控件的类库)，Microsoft还有一个基于ATL的类库，这个类库用于开发ActiveX Designer，ActiveX Designer是绝大多数程序员不了解得一类对象，如果你熟悉Office开发，你知道Office VBA 中有一类对象，即Form2，此外VB6.0 中的报表设计器（以及著名的Active Reporter），都属于此类对象，用这个类库，你可以为VB6.0以及集成VBA的系统提供定制化的可视化设计机制等等，如今ActiveX Designer已经演化为集成于Visual Studio .NET中的设计器。

有一篇回复给我印象比较深：

“不管你在不在WINDOWS下工作，必须跳出MS的世界才能真正理解操作系统和编程。作为程序员，你不能自我定位为普通的计算机用户，只能在 IDE工作的程序员不是真正的程序员。
你必须用过make/ant/scons/autoconf/automake才可能明了软件形成的过程。
你必须用过grep/sed/find/sh 才能了解正交设计有多么重要。
你必须同时精通多种语言（C++/JAVA/PYTHON/...）才可能融会贯通,才能了解面向对象究竟是怎么一回事。
你必须同时了解多种分布式组件技术COM+/CORBA/RMI/XML-RPC/SOAP等多种，才能正确评价.NET、JAVA或是其它。
你必须同时了解多种图形界面组件：MOTIF/QT/GTK/WXWINDOWS/WIN32/SWING/SWT才可能正确评价谁是谁非。
你必须了解 XUL/XAML才能体会未来的应用界面的开发会和基于代码生成的VC/VB/DELPHI有多么大的不同。
总而言之，兼听则明，只陷在 MS 的世界里很难理解这世界上不断涌现的新技术为何而来、从何而来，这些新技术对你来说就只能是新的技能而不是知识。”

这篇回复乍一看很有道理，其实再想一想，那么多“必须”也未必如此。如果对Windows的很多基础技术还一知半解，那就远远谈不上跳出了。一个人时间有限，学什么东西可以根据需要和兴趣自由安排。知识是学不完的。

不过程序员多学一些东西总是好的，例如在CPAN上从C语言的预处理器、WBXML的解析器到生成WAV文件的模块，几乎没有找不到的源代码。但如果你不会perl，就无法利用这些资源。在Windows上用C/C++时，我经常会从Delphi的VCL类库抄一些代码，有时因为MFC没有提供我需要的接口，有时因为我想不起来用哪个Windows API。但如果不会Delphi，就无法享用这个便利。

其实话又说回来，我觉得程序员的学习还是应该以兴趣、求知为主，其它的只是随之而来的东西。不为无益之事，安能悦有涯之生，学习编程语言不见得比听“七十二变”高明，只是更功利一些。

明天是本学年的最后一门考试。

这学期真的比较繁忙，课程量非常大，还有一份不怎么轻松的TA工作，压得喘不过气来啊。

总算都将结束了，还是觉得不管结局怎么样，什么事情自己尝试过争取过，尽力了就可以了。

等待着我的又将是一个繁忙的暑假，虽然实习啊还有今后打算还没怎么真正地安排好，呵呵。

这周比较忙。

周一去复兴做了网站系统的日常维护，对于MySQL的升级和事务处理问题弄得很伤脑筋啊。+--

接下来几天都在赶Graphics的project了，不过做得还蛮有成就感的，觉得这个会对自己的Flash和UI功力带来一定的提高。8|

然后macromedia被Adobe收购的噩耗传来了，我以至郁闷到现在，唉>o<怎么说我也是macromedia的元老级忠实粉丝了，这么好的公司和产品线居然说收购就被收购了，事先风声也没有放一点出来，真是冲击比较大阿。不过不管怎么说，希望macromedia的产品的发展尽量少受到些并购的负面影响，再给我们这些fans们创制出一些奇迹吧！期待、祝愿！:D

周三下午的实验室项目讨论很有新进展，初步可能会采用我提出的三层架构和设计方案了，我个人觉得这个方案肯定要比原先的方案要好，特别是在维护和缺陷控制的成本上可以大大的减少。暗自庆幸啊。:#

周三晚上的体系结构课居然再一次灵光凸现，让我无意间回答出了一个其他同学都强烈反对但是很正确的流水线异常处理方法，呵呵，我以前看到system architecture这类的课就头晕的，没想到居然也会有一些小表现啊。嘿嘿。

周五下午前沿讲座请到了微软全球技术支持中心的技术员来给我们开讲座，没想到开讲者居然和我是同一个高中的，心里很是激动啊，于是乎抓住机会问了好多问题，感觉彼此间的距离近了不少，对微软的感觉也更偏向了positive的一面了。嘿嘿。8|

周五晚上收到学院的一个设计任务，主要是为复旦百年校庆的研究生合唱团设计T-shirt，我以前没玩过这个，感觉满新奇的，而且也很有意义，也算是为百年校庆做点贡献吧。等设计了一些方案后贴出来晒一晒。:)

目前已经把系统原型定义和UI设计完成了；
对JavaMail/James/Web Services/EJB的研究时间正同步进行……
估计这两天能够确定下来系统架构设计，业务层用Web Services和SessionEJB实现，数据持久层用CMP实现，系统逻辑控制层用Struts实现（听说Spring是更好的选择，但我一直没时间去研究，暂且用Struts吧，比较保险）……
以下是目前各角色的系统UI原型：


系统主登录页面



系统管理员UI



教师用户UI



学生用户UI

前几天受实验室老师盛情相邀，帮忙替他们实验室设计了套网站：
由于时间很紧，加上手上还有好几个项目要赶，只能随意设计一下了，没经过跌代思考……>.<

最近事情实在好多，忙得不亦乐乎。:e012:

复旦大学软件学院电子商务研究中心网站网址：
http://www.software.fudan.edu.cn/ioeb

今天下午一听完xyx的软工课，就匆匆赶到复兴高中去做网站最后的部署工作了。
整个过程还是比较顺利的，除了期间数据库发生些莫名的拒绝服务操作外，其他基本都没有什么麻烦。
有兴趣的朋友可以通过http://www.fuxing.sh.cn来访问。8|
这次开发采用的是JSP MVC Model 2: Struts+Hibernate的框架，用顺了感觉还是很清晰的，特别是一些验证框架、会话信息判别和转向框架等等。整个过程从最初的需求获取、分析设计到后期的编码测试和部署基本是个人独立完成的，当然期间也少不了室友chenzg的帮忙，他研究了不少第三方的开源项目，为这个项目的开发带来了方便和亮点！谢谢他了！^^|

我大概是晚上八点不到一点回到机房的，在和javas还有chenzg讨论了一些感兴趣的东东后，便组织开了本学期AdWeb课程项目的第一次例会，大家一致决定采用第一套开发方案，即——谈话预约和跟踪系统(名字蛮土的，暂定吧，以后想个炫的^^)，目前将项目前期各部分的分工安排如下：

我: UI建模、Web Services、EJB
servlet: ERDB设计、EJB
chenzg: JavaMail、James(辛苦了，又要研究OS了，嘿嘿)
jeann: Servlet Authentication、J2EE Development Framework(抓紧时间熟悉一下吧，Hoho)

    很久很久以前，在寂静的海底躺着两粒砂。他们相距两尺。一粒砂爱上了另外一粒。他凝视着两尺开外的意中砂，平安幸福地过了好多年。水下风平浪静，砂粒觉得自己很幸福，因为他知道有自己爱的砂可以让自己凝视，不用管水面上的台榭焦土，沧海桑田。    

　　沙滩上现出恐龙的脚印。潮水涌来，脚印消失了，没有留下任何痕迹。这与海底的砂粒无关，但是在这一时刻他忽然冒出了一个念头：要到自己所爱的砂粒面前对她说爱她。于是砂粒开始了漫长的旅途，他一点一点地滚动，不放过任何一点动力，不管是细如发丝的暗流还是鱼们搅起的微弱旋涡。每当有这种力量是他总是觉得很感谢上苍。    

　　沙滩上的脚印换成了剑齿虎的，潮水仍然无声地抹去了这个生物留下的印记。砂粒距离他所爱的另一粒砂只有三寸了。再往后，沙滩上出现了人类的脚印，当潮水再一次将这些脚印抹掉的时候，砂粒终于来到了意中砂的面前。他痴痴地看着自己所爱的砂，想想自己在两亿年间所走过的漫长的两尺，瞬间感到天上地下所有的幸福全部都堆砌到了自己一个身上。
 
    两粒砂互相看着，不说什么。很久。砂粒终于决定要开口了。    

　　正在这时一股水流涌来，巨大的吸力使砂粒漂起来，被吸进了一个洞里。他最后一眼看了看自己漫长的旅程，看了看自己爱着的砂粒，不知道该说什么。这时洞口合上了，顿时一片黑暗。他知道自己被一个蚌捕获了。    

　　在以后的岁月里蚌偶尔会张开壳，砂粒还能看看外面的世界，这时他就看到那另一粒砂也在不远的地方凝视着自己。砂粒知道，世界是美好的。因为在光阴无法侵袭的海底，有另一粒砂在等待着自己。    

　　某个时刻砂粒忽然觉得蚌有一点摇动，不久蚌壳张开了，映入眼帘的是海面，阳光，船和人类，人类用欣喜若狂的眼神望着他，他环视一下自身，知道自己已经变成了珍珠。这粒珍珠圆润硕大，在人类而言是无价之宝，可是对珍珠的制造者，死去的蚌来说只是一个带了些痛苦的意外。很快珍珠就被镶嵌到了王冠上。已经变成珍珠的砂粒觉得很悲哀，但是并不绝望，因为他知道，另一粒砂在海底，痴痴地然而永远地等待着他。    

　　砂粒在王冠的顶端看着百官朝拜，看着国王老去，看着帝国衰落下去，随后国王终于死去了。    

　　王冠被用来陪葬。当王冠被放到棺材里的时候他听着墓穴门被关上，心里想着的是在海底等待自己的另一粒砂。他并不惊慌，因为他有的是时间。他为了两尺距离整整旅行了两亿年。    

　　黑暗的墓穴并不寂寞，时常有老鼠之类的来和他做伴。他独自呆着，不知道光阴的流逝。后来墓穴被打开了，两个盗墓者偷走了王冠，还有王冠上的珍珠。很不幸，他们在一条河边为了这粒最大的珍珠开始相互斗殴，双双死亡，珍珠掉到了河边。珍珠中的砂粒燃起了一辈子从未有过的希望，他知道世界上的很多河水最终都要流到海里。等雨季来临，他就可以随着河水流下，到海里去寻找她。也许要经过无穷岁月才能达到最初的地方，可是有什么关系呢？他知道另一粒砂一定会在海底做永远的等待，望穿秋水。    

　　很快雨季来了，可是来临的不是暴涨的河水而是泥石流。珍珠和珍珠之中的砂粒一同被埋到了浅浅的地下。砂粒非常失望，可是他知道自己还有机会，因为陆地也是运动的，而且比自己快得多。    

　　又是一个漫长。珍珠层已经被剥离得没有了，砂粒又露出了自己的本色，他觉得很干净，自己可以一尘不染地去见另一粒砂了。    

　　上面传来沉重的隆隆声，这是一个金矿，砂粒和其他石头、泥土等一起被扔到了一个酷热的罐子里。直到这时他才发觉自己原来是一粒金砂。很快，他和其他金子被融合到了一起，炼成一块金砖，运到了什么地方的金库收藏起来。砂粒在悲伤中度过了很多年，想到海底的另一粒砂就觉得心如刀搅，但是他安慰自己说：还会有机会的。不可预知的未来也许会再次把他回复成一粒砂，并且把他带回大海，那样他就可以做长久的搜寻，为了茫茫大海之中的另一粒砂，为了在海底等待他的那一粒砂。    

　　有一天金砖和金砖之中的砂粒被一起取出，他不知道自己将会怎么样，金砖被做成了一张唱片，记录下了地球上的各种语言和声音，包括大海的波涛。直到唱片被安装在发射架上的火箭里时砂粒才觉得有些惊慌，他问身边的黄金：我们这是要去哪里？    

　　要飞向宇宙，向其他可能存在的智慧生命传达地球人类的信息。其他黄金骄傲地回答：不是每个黄金分子都有这样的机会的。正在这时火箭发射了。砂粒看着越来越远的地球，在宇宙中地球美丽而脆弱。他忽然间明白自己永远也不可能回到大海，回到没有任何诺言就在海底无尽等待自己的那一粒砂面前了。他有极为值得骄傲的历史，他曾经是世界上最美丽的珍珠，最纯的黄金，现在他是一粒飞上了茫茫宇宙的砂粒，是一个星球向宇宙所做的标记。可是比起这一切来他宁愿在海底做一粒砂，哪怕在自己所爱的砂粒身边呆上一个小时，就灰飞烟灭。仅仅是为了两粒砂之间可怜简单的爱情。    

　　宇宙空间之中传出一粒砂的哭声，    
　　飘荡着良久不绝。    
　　编一个梦　    
　　再为它编一个翅膀　    
　　让它飞　进你的心房    

　　那是一片温馨地方    
　　那里有我的期盼和向往　    
　　那里是我心灵的港湾　秋天的童话 ...     

上周终于把复兴网站项目收尾了，已经拿去演示过了，正在内部测试，估计本月下旬可以投入使用了。下图是网站首页截图：



本来要做三个模块：新闻发布管理、招生考试报名登记查分、校友通讯管理；后来由于时间紧迫，校友模块没来得及完成……

另外，接手的一篇论文翻译任务终于很艰难的完成了，我大约译成了接近一万词的英语吧，里面很多新的表达都不大确定的，问了好一些专业人士才搞定的，唉

最后，就是顺利完成院报的新老交替了。算下来，我经手过的报纸出版也有10期了，真也是有不少体会的，期间与人沟通、交际协调的能力也有了一定的提高。我已经初步安排好了04级的ddmm来接我的班，希望他们能做得比我要好！但前提是要学业千万不能落下的。。。+U吧~~

还有好一些原本假期里要完成的事情要拖到开学后了：
论文翻译、Lab设计、复兴项目……^^|
要尽快结束它们！ 。。。。。。

　　Shneiderman’s “Eight Golden Rules of Interface Design”这篇文章是我在Furl上无意间找到的，很有参考价值，所以花了一些时间翻译成中文。
　　这些准则是由Ben Shneiderman的Designing the User Interface这本书中节录出来的。这些准则是Shneiderman藉由经验与观察互动系统后，将一些合适的经验法则再精炼、延伸后才整理出来的。
　　一个容易的使用的应用程序，妥善的使用者接口设计是少不了的。Shneiderman的八个经典使用者接口设计准则是设计一个互动作品的最佳指南。

1.取得一致性
类似的情况应该有让使用者有一致性的操作。在提示、选单与说明文件中，应该采用同样的名词。并且保持命令的一贯性。

2.让重度使用者使用快捷方式
当使用频率增加时，使用者会希望减少互动的次数、让每次的互动能够一次做更多的动作。缩写、功能键、隐藏功能与综观全局的功能，对专家来说非常有用。

3.提供有意义的回馈
当使用者做出一些动作时，系统应该提供回馈。越频繁的动作，其回馈的强度可以低一些。越重要或不寻常的动作，其回馈强度应该要显著一些。

4.设计对话产生结束
一连串的动作应该被组织成开始、中间、结束三部份。当动作结束的时候，要提供回馈让使用者知道动作已经完成。在做下个一连串的动作之前，先告知使用者整个流程，能够减轻使用者的压力、提高满意度。

5.提供简单的错误处理
最好不要让系统有严重错误的可能性。如果还是造成错误，系统应该能够侦测出出来，并提供一个简单、使用者可以理解的错误处理方式。

6.允许回到上一步
这个功能可以减低使用者的焦虑，因为使用者只到做错了可以重来。这个功能鼓励使用者探索不熟西的选项。回到上一步的功能，可以包含一个、或是一连串的动作。

7.满足使用者控制的需求
有经验的使用者强烈的感觉到他们在控制系统，做出动作之后，系统提供回馈。系统设计上要让使用者作为动作的处发者，而不是响应者。

8.减少短期记忆需求
人类的短期记忆有限，因此显示上要保持简单、能同时显示多页数据以减少窗口切换频率，减少记忆指令和动作顺序的时间。