微软软件开发技术二十年回顾1985.docx

微软软件开发技术二十年回顾1985.docx

《微软软件开发技术二十年回顾1985.docx》由会员分享，可在线阅读，更多相关《微软软件开发技术二十年回顾1985.docx（14页珍藏版）》请在冰豆网上搜索。

微软软件开发技术二十年回顾1985

微软软件开发技术二十年回顾1985-2006

近20年来，随着技术和应用的变化、发展，微软的开发技术也历经变迁。

随着微软新一代开发平台vista的发布，微软会把开发者引向何方?

　　自Windows1.0问世到2006年11月份，微软Windows操作系统已经走过了它辉煌的二十一年。

沧海桑田一瞬间，让我们再次追随Windows的踪迹，了解微软核心技术发展史，评析她当时所处的位置并展望其今后的发展趋势。

一、操作系统篇

Win16时代（1985～1995）

　　1985年11月，微软公司正式发布了第一代窗口式多任务系统──Windows1.0，代表了MS-DOS时代将逐渐终结，Windows王朝正式拉开了序幕。

该操作系统的推出标志着PC机开始进入了图形用户界面（GUI）时代。

1987年12月9日，Windows2.0发布，但这个版本依然没有获得用户的广泛认同。

　　1990年5月22日，微软推出Windows3.0，由于在界面/人性化/内存管理多方面的巨大改进，终于获得用户的认同。

1992年4月，Windows3.1发布，在最初发布的两个月内，销售量就超过了一百万份；至此，微软公司的资本积累/研究开发进入良性循环。

随后，首次发布了Windows3.2中文版本。

不论是图形操作系统的稳定性还是友好性，Windows3.X都有了巨大的改进。

Windows3.X在界面人性化和内存管理上有了较大的改进：

具备了模拟32位操作系统的功能，图片显示效果大有长进，对当时最先进的386处理器有良好的支持。

另外，这个系统提供的对虚拟设备驱动（VxD）的支持，极大改善了系统的可扩展性。

　　1992年10月，WindowsforWorkgroups3.1发布，标识微软公司吹响了进军企业服务器市场的号角。

1993年，WindowsNT3.1发布，它是第一款真正面向服务器市场的产品。

值得注意的是，在这个版本中，微软把主要的API改为32位的版本。

 Win32时代（1995～2005）

　　1995年8月24日，微软推出具有里程碑意义的Windows95。

这是微软开发的第一个独立的32位操作系统，并实现真正意义上的图形用户界面。

从此，个人电脑进入了普及化阶段。

　　另外，Windows95是单用户多任务操作系统，它能够在同一个时间片中处理多个任务，充分利用了CPU的资源空间，并提高了应用程序的响应能力。

同时，Windows95还集成了网络功能和即插即用功能。

　　1996年8月，WindowsNT4.0发布，增加了许多管理方面的特性，稳定性进一步提高。

同年11月，针对各种嵌入式系统和产品设计的WindowsCE1.0发布。

这标志着微软的战线从桌面系统杀到了服务器市场，又转攻到嵌入式行业；至此，微软帝国的雏形已基本形成。

1997年11月，WindowsCE2.0发布。

　　1998年6月25日，Windows98发布；与Internet的紧密集成是Windows98最重要的特性。

1999年6月10日，Windows98SE发布，以内置方式提供了InternetExplorer5、WindowsNetmeeting3、InternetConnectionSharing、对DVD-ROM和对USB的支持。

　　Windows2000（WindowsNT5.0）Professional于2000年年初发布，它是第一个基于NT技术的纯32位的Windows操作系统，实现了真正意义上的多用户。

从此，Windows操作系统进入商业用户市场。

Windows2000包含新的NTFS文件系统、EFS文件加密、增强硬件支持等新特性。

　　2001年10月25日，Windows家族中极具开创性的版本WindowsXP面世。

WindowsXP具有全新的图形用户界面，整合了更多更实用的功能：

防火墙，即时通讯，媒体播放器，增强的即插即用特性。

WindowsXP具有全面为中国用户开发的中文技术及特性，能够全面满足中国用户在数字时代的需求。

　　2003年4月，WindowsServer2003发布。

这个版本对活动目录、组策略操作和管理、磁盘管理等面向服务器的功能作了较大改进，对.NET技术的完善支持进一步扩展了服务器的应用范围。

　　2004年9月微软发布WindowsXPSP2。

 WindowsVista（2006.11～）

　　今年11月，微软新一代的操作系统Vista即将正式发布，它将会极大地改变原有的Windows编程机制。

　　Vista生成器最终将跟以前的Win32API进行分离，取而代之的是可管理的WinFX，而WinFX将成为微软继DOS、Win16、Win32之后推出的第四代API。

据外刊报道，以前利用Win32API开发的软件，在微软承诺的维护期之后将不能运行。

　　Win32API历经Windows95到XP，受到众多应用软件开发商的追捧。

过去，无论是最常用的字处理、电子邮件、即时通讯软件，还是专业的杀毒、ERP软件等，大都利用微软提供的API进行开发。

微软提供了近7.8万个WindowsAPI以及大量的辅助开发工具，这种友好的服务极大地鼓励了无数程序员在微软平台上创造各种应用软件。

但另一方面，微软又通过API“控制”了软件的开发，帮助自己成就了霸主地位。

如今，在Win32API逐渐淡出人们的视野后，新一代的API还能如微软设想的那样延续Win32时代的辉煌吗？

　　微软已经看到了这些威胁。

所以，Vista的发行中配带了全新的WinFX。

同时，微软的WinFX已经把繁杂的Win32API减少到8千个左右，在.NET框架下采用可管理代码编程模式，进一步减轻程序员的负担。

另外，WinFX还加入全新的图形用户界面子系统Avalon、文件子系统WinFS和网络服务通讯子系统Indigo，使得开发环境更加友好。

时势所趋，正如Win32取代DOS和Win16一样，Win32API也终将被WinFX所替代，而成为新操作系统中的“遗留物”。

　　据估计，在一段时间内，程序员还可以继续使用Win32API开发应用程序，但利用WinFX开发的程序并不向下兼容，只能在Vista平台上运行。

另一方面，Vista操作系统带来的变化和WinFX开发者框架迟早将会刺激开发者转向.NET框架。

因此，作为Windows开发人员，应当尽早掌握.NET框架可管理编码的技能以便应对在2008年全面使用WinFX时可能出现的种种问题。

二、API篇

　　随着Windows操作系统开始占据主导地位，开发Windows平台下的应用程序成为人们的需要。

当然，这也为传统的DOS程序员提供了一种新的编程方法—一种不受设备限制并由事件驱动的编程方法。

另一方面，WindowsGUI的开发迫使传统的DOS程序员的编程方法发生了变化。

当时，大多数DOS软件以过程方式编写，即一个函数调用另一个函数，主程序始终处于控制之下，而事件驱动的编程模式使得程序放弃它们的全部控制权，等待外部事件发生并对外部事件作出响应，以便将它们的函数全部提供给最终用户。

结果是，今天的Win32（当然包括早期的Win16）GUI程序的结构仍然与1987年时的结构相同。

图1展示了WindowsGUI应用程序的基本结构。

 　  其中，每一个程序都包含一个进入点、主窗口创建、一个消息循环和主窗口撤消。

此外，都有一个函数与主窗口过程相关联，称为窗口过程，它包含用于处理系统事件和应用事件（如键盘输入、鼠标移动和点击、定时器报警、菜单选择和按钮点击）的代码。

　　在Windows程序设计初期，Windows程序员所能使用的编程工具唯有API（应用程序编程接口）函数，这些函数是Windows提供给应用程序与操作系统的接口，它们犹如“积木块”一样，可以搭建出各种界面丰富功能灵活的应用程序。

所以，可以认为API函数是构筑整个Windows框架的基石，在它的下面是Windows的操作系统核心，而它的上面则是各种功能的Windows应用程序。

当时，因为缺乏良好的Windows编程平台，程序员想编写具有Windows风格的软件，必须借助API，API也因此而被赋予至高无上的地位。

相应地，程序员还必须熟记一大堆常用的API函数，而且还得对Windows操作系统有深入的了解。

　　随着软件技术的不断发展，在Windows平台上很快出现了很多优秀的可视化编程环境（诸如VB、VC++、DELPHI等），程序员可以采用“所见即所得”的编程方式来开发具有精美用户界面和强大功能的应用程序。

但实际上，要真正开发出更灵活、更实用、更具效率的应用程序，必然要涉及到直接的API函数调用；对于比较复杂和特殊的功能来说，使用类库和控件往往难以实现，这时就需要采用API函数来实现。

【提示】关于钩子技术

　　Windows操作系统是建立在事件驱动机制之上的，系统各部分之间的沟通也都是通过消息的相互传递而实现的。

但在通常情况下，应用程序只能处理来自进程内部的消息或是从其他进程发过来的消息，如果需要对在进程外传递的消息进行拦截处理就必须采取一种被称为HOOK（钩子）的技术。

钩子是Windows操作系统中非常重要的一种系统接口，用它可以轻松截获并处理在其他应用程序之间传递的消息，并由此可以完成一些普通应用程序难以实现的特殊功能。

钩子的本质是一段用以处理系统消息的程序，通过系统调用，将其挂入到系统。

值得注意的是，钩子技术成为许多种Windows软件的核心技术，例如屏幕抓词、垃圾邮件过滤、软件界面高级定制等。

三、MFC篇

　　WindowsAPI是面向过程的接口，因此对于当时的编程技术来说，它是完美无缺的。

但是，随着人们逐渐使用C++进行Windows程序的开发，迫切需要建立与WindowsAPI的面向对象包装的接口。

1992年，微软将WindowsAPI开发成为它的应用程序框架（AFX），后来该产品又演变成为目前的微软基础类库（MFC）产品。

下图2展示了MFC的顶级类层次结构。

　　MFC为使用C++开发WindowsGUI应用程序提供了一个十分全面的基础框架，它对以前的API进行了面向对象的科学包装，大大简化和加快了程序的开发。

　　Win95推出后出现在VisualC++4中的新版本的MFC4.0使这个框架达到辉煌时期，在4.2版本时达到鼎盛。

　　MFC框架中引入了一种适应当时开发需求的典型的文档-视图机制，从而大大简化了程序开发。

当然，要掌握这些框架结构绝非一日之功，其中还涉及到部分COM及大量的宏技术。

也正由于这些方面，导致了业界对MFC的褒贬不一。

但正如其它微软技术一样，这只能进一步促进微软继续改进这种技术。

几十年的技术积累已经奠定了MFC的生存基础，即使Windows的Vista发布，MFC也不可能退出Windows的舞台。

事实上，Vista之后的VisualStudio.NET仍将MFC作为一个重要的组成部分，在VisualStudio.NET2005中，MFC在C++中的位置依然如故。

MFC的未来，应该不必担心，只要你深入考察.NET类库，你会发现，MFC的许多思想机制正悄然进入.NET。

　　新版的VisualC++.NET中MFC已经支持.NET开发了，而且MFC与ATL的协作更趋于和谐。

如今你可以在VisualC++.NET中综合应用MFC、ATL与.NET库三者来开发应用程序，从而进一步增强C++开发的威力。

【补注】ATL框架与WTL框架

　　ATL即“ActiveX模板库”。

它不能单独工作，是设计与VisualC++V4.2，V5.0，V6.0一起工作的。

　　MFC和ATL都可以用来开发ActiveX控件。

事实上，两者都支持各种开发向导和强有力的帮助类和模板，从而使控件的开发尽量简单。

而且，这两种框架各有千秋。

简言之，如果你相当熟悉MFC的各种机制而且是在创建庞大而成熟的图形应用程序本地控件或服务器控件，那么使用MFC书写控件时会有很大的优越性。

　　然而，用MFC建立的控件在执行时要求相应的MFCDLL支持，相应地导致体积庞大。

如果在控件的规模成问题时，则可以考虑使用另一种方法-ATL活动模板库。

　　在建立轻量级控件（几乎或根本没有用户界面要求的COM或DCOM服务器）时，ATL方法是MFC方法的替代方法。

ATL在建立COM组件时使用了模板机制，这个框架对许多标准的COM接口提供了大量的模板。

事实上，ATL根本不需要任何类型的运行时刻服务—由于以C++模板为基础，所以ATL对于外部库根本没有链接依赖性。

因此，基于ATL的组件要比等价的基于MFC的控件占用的资源少。

　　WTL框架，作为ATL的扩展，也是由ATL小组开发的，包含在微软于2000年1月发布的开发平台SDK包中，虽然微软没有正式支持。

WTL通过提供一个用于编写Win32应用程序和控件的轻量级的框架、一些特殊的视图、GDI对象和实用的类来扩展ATL窗口类。

WTL的目标是成为最好和最简单的实现基于Win32和ATL的应用程序、服务器和控件的方法。

四、COM、OLE、ActiveX及COM+篇

　　微软的许多技术，如OLE、ActiveX、以及DirectX等都是基于COM技术而建立起来的。

微软本身也大量地使用COM组件来定制他们的应用程序及操作系统。

那么，什么是COM呢？

 　　所谓COM即“组件对象模型”，是一种说明如何建立可动态互变组件的规范，此规范提供了为保证能够互操作，客户和组件应遵循的一些二进制和网络标准。

通过这种标准将可以在任意两个组件之间进行通信而不用考虑其所处的操作环境是否相同、使用的开发语言是否一致以及是否运行于同一台计算机。

开发COM的目的是为了使应用程序更易于定制、更为灵活。

　　其实，COM不是以一个单独的开发过程的一部分出现的。

相反，它最初是以对象及嵌入系统的形式产生于Windows3.0。

我们知道，OLE1允许一个应用程序（如WORD或EXCEL）可以不必打开第二个应用程序就能显示其它应用程序的数据。

但OLE1还存在两个局限：

　•首先是嵌入的数据不能被应用程序所编辑；

•其次，没有标准化的系统用于存放嵌入的信息。

　　于是，出现了OLE2，OLE2是与WINDOWS3.1一起推出的，它是第一个真正的COM技术，而OLE1还不具备COM的各项特性—它使用的是另一种技术体系。

OLE2中产生了一种新的唯一的数据格式，称为复合文件。

这种文件中能够包括所有OLE支持的应用程序的相关信息，并在任一工作的应用程序中支持编辑、更新、打印等功能。

　　但OLE2仍然存在一些局限性，最为明显的是任何时候要对一个嵌入的数据进行编辑都得重新打开一个窗口。

对这一点的改进，生成了OLE的一个新版本，称为OLE自动化。

该技术除了允许在调用数据的应用程序内部进行编辑（称为内部编辑），还在OLE2的基础上加入了其它两项与COM技术相关的改进：

一是提供了非C++开发程序（如VB程序）接入COM功能的能力；二是支持存在于复合文件以外的基于COM技术的部件的创建。

Windows3.11全面支持自动化技术。

　　虽然，这最后一次的技术改进给COM带来了最持久的冲击，但是COM的OLE实现并没有实现BillGates先生的部件化软件的梦想。

随之而来的另一技术革新却通过从未想过的机制—VBX控件使之变成了现实。

VBX是VisualBasic开发环境的一些内带工具，最早由C++开发，后来却都是用VB自己开发的。

VBX是一类DLL应用程序，具有特殊的支持以便可以在VB系统中使用。

在一年左右的时间内，VBX控件的市场迅速发展成为一个几百万美元的产业，并带动了VB产品的销售。

VBX具有两项以前的自动化服务器所不具备的重要性质：

用户接口和它与客户（容器）的通信能力。

　　VBX的这种出乎意料的成功让微软决定让COM工作组在自动化基础上增加等效于VBX的性能。

这一开发过程的结果就是OCX控件（是一种特殊的自动化DLL服务器），它采用COM技术支持VBX控件的所有功能，而且它从此升级为32位的控件。

可惜，在OCX尚未来得及普及以前，因特网和Java的出现使它们被重新改造成了ActiveX控件。

　　当时，没有谁会预料到Java和Internet会在WWW领域以氢弹的威力在计算机领域爆炸。

微软长期以来一直认为他们在PC机软件领域的垄断是无可挑战的，但是Java和网页浏览器伴随着Internet，以一种全新的方式进入到个人微机的软件领域，且该领域由Sun和Netscape控制而不是微软。

作为迎击，COM变成了ActiveX，复合文件变成了ActiveX文件，OCX控件变成了ActiveX控件等等。

基于COM的ActiveX组件均根据Internet的特点增加相应的新特征，如保密安全性能、代码短、数据支持异步下载。

同时，ActiveX组件还具有如下特点：

•ActiveX在自动化服务器上增加了用户接口；

　　•通用属性和属性页机制使ActiveX控件的行为标准化；

　　•连接点机制支持从ActiveX控件向容器发送事件；

　　•ActiveX的持续性解决了越时的状态存储问题。

　　总之，OLE1、OLE2、OLE自动化、VBX控件、OCX控件、ActiveX以及COM+都是COM概念在Windows操作系统的各种实现方式。

如今，COM已成为微软产品系列的核心组成技术：

　　•InternetExplorer4网络浏览器支持所有的ActiveX控件，实际上它正是采用了一个ActiveX组件用于它的显示接口;

　　•Windows98这种新版的Windows操作系统将IE与操作系统捆绑在一起，它基于COM技术并支持活动桌面，使桌面部件具有网络应用的功能;

　　•Internet信息服务器（IIS）是微软加入网络服务器大战的重量级武器，IIS包括很多的功能强大的基于COM技术的系列内容，如ActiveServerPage，ISAPI扩展和ISAPI过滤器；

　　•微软事务服务器（MTS）是一种面向数据库的系统，MTS采用COM技术以支持多种数据库系统和售货机的混合事务处理，并仿造非数据库的执行方式，将事务的处理变成单步的行为，其结果可以为“成功”、“失败”和“返回”而不会因为处理失败而丢失数据;

　　•OLEDB推回到COM的OLE2技术上，它采用与ODBC数据库相同的技术，支持非数据库应用程序与面向数据库的技术（如MTS）共同工作。

　　从另一方面看，最初，Windows是利用DLL在二进制级实现代码共享的。

这也是Windows程序运行的关键——重用kernel32.dll，user32.dll等。

但DLL是针对C接口而写的，它们只能被C或理解C调用规范的语言使用。

由编程语言来负责实现共享代码，而不是由DLL本身。

这样的话，DLL的使用受到限制。

尽管在后来，MFC又引入了另外一种MFC扩展DLL二进制共享机制，但它的使用仍受限制——只能在MFC程序中使用。

　　COM通过定义二进制标准解决了这些问题，即COM明确指出二进制模块（DLL和EXE）必须被编译成与指定的结构匹配。

这个标准也确切地规定了在内存中如何组织COM对象。

COM定义的二进制标准还必须独立于任何编程语言（如C++中的命名修饰）。

事实上，COM正是充分利用了Win32DLL的灵活性才得以真正在Windows平台上实现的。

COM的发布形式是以win32动态链接库（DLL）或者可执行文件（EXE）的形式发布的可执行代码组成。

　　注意，COM本身也要实现一个称为COM库的API，由该库提供诸如客户对组件的查询，以及组件的注册/反注册等一系列服务。

一般来说，COM库由操作系统加以实现，程序员不必关心其实现细节。

【注】DirectX技术

　　要在Windows平台上进行游戏开发必须了解两个重量级游戏API：

DirectX和OpenGL。

其中，DirectX是微软开发的专门用于优化游戏制作的API。

DirectX由很多组件组成：

DirectDraw、DirectSound、DirectMusic、DirectPlay、Direct3D、DirectInput、DirectSetup。

它是允许你直接控制计算机硬件设备的软件，它比WindowsGDI要快好几倍，可用于不同的语言和多种平台，支持从绘制象素到高级3D图像，从播放简单声音到数字音乐，从键盘控制到反震手柄……几乎为你的游戏开发提供了所需的一切。

注意，DirectX的基础正是COM技术。

什么是COM+?

　　必须明确，COM+并不是COM的简单升级，但它的底层结构仍以COM为基础，COM+综合了COM、DCOM和MTS这些技术要素，把COM组件软件提升到应用层而不再是底层的软件结构，它通过操作系统的各种支持，使组件对象模型建立在应用层上，把所有组件的底层细节留给操作系统；因此，COM+与操作系统的结合更加紧密。

下图3展示了COM+与MTS、COM/DCOM的关系。

　　另一方面，COM+不再局限于COM的组件技术，它更加注重于分布式网络应用的设计和实现。

COM+继承了COM几乎全部的优势，同时又避免了COM实现中的一些不足，把COM、DCOM和MTS的编程模型有机地结合起来，继承了它们的绝大多数特性，在原有的特性上增加了新的功能：

　•真正的异步通讯。

　•事件服务。

　•可伸缩性。

　•可管理和可配置性。

　•易于开发。

　　COM+标志着微软的组件技术达到了一个新的高度，它不再局限于一台机器上的桌面系统，而是把目标指向了更为广阔的企业内部网，甚至国际互连网。

COM+与多层结构模型（WindowsDNA结构，详见下一节）以及Windows操作系统为企业应用或Web应用提供了一套完整的解决方案。

【问题】.NET时代，COM是否会消失？

　　不会。

其实，.NET只不过是COM的别名而已。

对于一个经验丰富的C++程序员而言，.NET就是COM的进化，而微软内部.NET可以说是“COM3.0”。

其实，CLR就是一个不折不扣的COM对象。

但是，请注意，.NET使用一种不同的方法来编写组件，这样.NET组件与原先的COM组件存在明显的不同。

.NET组件不需要使用注册表和类型库，因为所有关于组件的信息都以元数据的形式包含在程序集（Assembly）中。

但是，借助于一个称为COMInterop的工具，COM对象和.NET对象可以很好地协作：

通过提供软件包类，.NET对象可以访问COM对象；通过提供所有的注册表项和COM对象构建机制，COM对象可以访问.NET对象。

五、WindowsDNA篇

　　微软的Windows分布式因特网应用体系（简称WindowsDNA）是微软创建新一代高适应性商业解决方案的框架，它使公司能够充分地挖掘数字神经系统的优点。

WindowsDNA是在.NET平台出现之前在微软平台上进行技术开发的大环境，要利用微软的组件技术OLE、COM、DCOM、MTS、COM+进行开发，就不能不了解这个Windows环境下的软件体系结构。

WindowsDNA是第一个将互联网、客户/服务器和用于计算的PC模型结合并集成在一起的为新一代分布式计算方案而设计的应用软件体系结构。

下图4展示了微软创建的WindowsDNA的系统架构。

       由图中可见，WindowsDNA使用了一系列的服务来完成它的架构。

使用WindowsDNA模型，用户可建造一个能在任