在windows操作系统的发展历程中，Windows7是一个具有特殊意义的版本。它是目前最为复杂的单机操作系统，无论从代码规模、代码复杂度，到系统适应场景的复杂程度，都超过了以前所有的版本。从某种意义上，Windows7代表了软件工程的一个顶峰－－人类可以构造出如此复杂且能稳定工作的软件系统！

一、Windows操作系统的版本

表1.1Windows操作系统的历次发布

产品名称	内部版本号	发布日期
Windows NT 3.1	3.1	1993年7月
Windows NT 3.5	3.5	1994年9月
Windows NT 3.51	3.51	1995年5月
Windows NT 4.0	4.0	1996年7月
Windows 2000	5.0	1999年12月
Windows XP	5.1	2001年8月
Windows Server 2003	5.2	2003年3月
Windows Vista	6.0(编译版本6000)	2007年1月
Windows Server 2008	6.1(编译版本6001)	2008年3月
Windows 7	6.1(编译版本7600)	2009年10月
Windows Server 2008 R2	6.1(编译版本7600)	2009年10月

注："Windows 7"这一产品名称中的"7"并非指内部版本号，而是Windows家族的世代编号。实际上，为了使应用兼容性问题尽可能小，Windows 7的版本号其实是6.1，如表1.1所示。这使得那些检查大版本号的应用程序在Windows 7上可以像在Windows Vista上那样继续执行。事实上，Windows 7和Server 2008 R2有同样的版本号和编译版本，因为它们是从同样的Windows代码基编译而来。

二、基础概念和术语

（一）Windows API

Windows应用编程接口(API)是针对Windows操作系统家族的用户模式系统编程接口。在64位版本Windows推广以前，32位版本Windows操作系统的编程接口被称为Win32 API,以区别原来的16位版本Windows的编程接口，即16位Windows API。Windows API包括数千个可调用的函数，它们可以被分成以下一些大类：

l 基本服务

l 组件服务

l 用户界面服务

l 图形和多媒体服务

l 消息和协作

l 网络

l Web服务

---

关于.NET

Micrsoft .NET框架是由一个被称为框架类库(FCL，Framework Class Library)的类库和一个提供了托管代码执行环境的公共语言运行库(CLR，Common Language Runtime)组成的，后者提供的托管代码执行环境包含以下一些特性：即时编译、类型检验、垃圾回收和代码访问安全性等。由于CLR具有这些特性，因此它所提供的开发环境能够提高开发人员的生产效率，减少常见的编程错误。

CLR的具体实现形式是一个典型的COM服务器，它的代码位于一个标准的用户模式Windows DLL中。实际上，.NET框架中所有组件的实现形式都是标准的用户模式Windows DLL,它们建立在非托管的Windows API函数之上(.NET框架中没有一个组件运行在内核模式下)。

Win32 API的历史

有意思的是，Win32并不是Windows NT最初预定的编程接口。因为Windows NT项目在启动之初，目标是替代OS/2第2版，所以，它的主要编程接口是32位OS/2 Presentation Manager API。然而，项目进行了一年以后，Micrsoft Windows 3.0进入市场，并且呈现出很好的发展势头。于是，Micrsoft转变了方向，使Windows NT成为未来Windows产品家族的替代品，而不是用来替代OS/2。也正是这个时候，才真正有必要制定Windows API－－在此之前，在Windows3.0中，只有16位接口的API。

尽管当时在Windows API中将会引入很多在Windows 3.1上还无法使用的新函数，但是，Micrsoft还是决定让新的API与16位Windows API在函数名称、语义和数据类型用法上尽可能地兼容，以便减轻将已有的16位Windows应用程序移植到Windows NT上的负担。这也正是许多函数名称和接口看起来并不一致的原因：为了确保当时新的Windows API与老的16位Windows API保持兼容，这是必需的。

（二）服务、函数和例程

在Windows的用户文档和程序设计文档中，有几个术语在不同的上下文环境中有着不同的含义，例如，服务可以指操作系统中可被调用的例程、设备驱动程序或者服务器进程。下面的列表描述了一些特定术语的含义：

Windows API函数 指Windows API中已被文档化的、可被调用的子例程。

原生的系统服务(或者系统调用) 指操作系统中未文档化的、可在用户模式下调用的底层服务。

内核支持函数(或例程) 指位于Windows操作系统内部且只能在内核模式下调用的子例程。

Windows服务 指由Windows服务控制管理器启动的进程。

DLL(动态链接库) 指一组可调用的子例程，合起来被链接成一个二进制文件，使用这些子例程的应用程序可以动态地加载此二进制文件。Windows的用户模式组件和应用程序大量使用了DLL。DLL比静态库的优势在于，应用程序可以共享DLL，Windows保证在内存中只有一份DLL代码，供所有引用该DLL的应用程序共享。注意，非可执行的.NET程序集也被编译成DLL，但是，它们没有导出任何子例程，而是由CLR解析出编译的元数据，以便访问对应的数据类型和成员。

（三）进程、线程和作业

尽管表面上看起来程序和进程非常类似，但体质上它们却是截然不同的。程序是一个静态的指令序列，而进程是一个容器，其中包含了执行程序的特定实例时所用到的各种资源。从最高层次的抽象来看，Windows进程是由以下元素构成的：

l私有的虚拟地址空间，这是指该进程可以使用的一组虚拟内存地址。

l可执行的程序，它定义了初始的代码和数据，并且被映射到该进程的虚拟地址空间中。

l已打开句柄的列表，这些句柄指向各种系统资源，比如信号量、通信端口和文件，该进程内所有的线程都可以访问这些系统资源。

l被称为访问令牌的安全环境，它标识了与该进程关联的用户、安全组、特权、UAC(User Account Control，用户账户控制)虚拟化状态、会话，以及有限的用户账户状态。

l被称为进程ID的唯一标识符(在内部，进程ID还是标识符客户ID的一部分)。

l至少一个执行线程(尽管“空”进程也是有可能的，但没有用处)。

每个进程也指向它的父进程或者创建者进程。如果父进程不再存在，子进程中的这一信息并不会被更新。因此，一个进程有可能指向一个已不复存在的父进程。这并不是一个问题，因为任何一个进程都不必依赖于父进程信息的有效性。

线程是一个进程内部的实体，也是Windows执行此进程时的调度实体。如果没有线程，进程的程序将不可能运行。线程包括以下一些最基本的部件：

l一组代表处理器状态的CPU寄存器中的内容。

l两个栈－－一个用于线程在内核模式下执行时，另一个用于在用户模式下执行时。

l一个被称为线程局部存储的私有存储区域(TLS，thread-local storage)，各个子系统、运行库和DLL都会用到该存储区域。

l一个被称为线程ID的唯一标识符(它也是内部结构客户ID(client ID)的一部分－－进程ID和线程ID是从同一个名字空间中产生的，所以它们永远不会重叠）。

l有时候线程也有这它们自己的安全环境，或者令牌，多线程服务器应用程序要模仿其客户的安全环境时，常常会使用线程自己的安全环境。

易失的寄存器、栈和私有存储区域合起来被称为线程的环境。因为这些信息随着Windows所在机器架构的不同而有所不同，所以，此结构必须是与底层架构相关的。

注：对于在64位Windows版本上运行的32位应用程序，其线程将同时包含32位和64位环境，Wow64位会在必要的时候利用此环境，将应用程序从32位切换到64位模式下。这些线程将有两个用户栈和两个CONTEXT块，常规的Windows API函数将返回64位环境。

（四）纤程与用户模式调度线程

因为将CPU的执行从一个线程切换到另一个线程，将不可避免地涉及内核调试器，所以，这可能是一个开销昂贵的操作，如果两个线程经常频繁地来回切换则尤其如此。Windows实现了两种机制来降低这一开销：纤程(fiber)和用户模式调度(UMS，user-mode scheduling)。

纤程使得一个应用程序可以调试它自己的“线程”的执行过程，而不必依赖于Windows内置的基于优先级的调度机制。纤程也常被称为“轻量”线程；从调度的角度来看，它们对于内核是不可见的，因为它们是在用户模式下在Kernel32.dll中实现的。为了使用纤程，首先要调用Windows的ConvertThreadToFiber函数，又可以创建额外的纤程。然而，与线程不同的是，纤程不会自动执行，它必须由SwitchToFiber函数手工选中，然后才能执行。新的纤程会一直运行，直到退出，或者调用SwitchToFiber再次选择运行另一个纤程。

UMS线程仅在64位Windows上可用，它基本上提供了与纤程同样的好处，没有更多的坏处。UMS线程有它们自己的内核线程状态，因此对于内核是可见的，这使得多个UMS线程都可以发出阻塞的系统调用、对资源进行共享或竞争，并且有每个线程特有的状态。然而，只要两个或多个UMS线程需要在用户模式下执行工作，它们可以周期性地切换执行环境而无须涉及内核调度器：环境切换在用户模式下完成。从内核的角度来看，同样的内核线程仍然在运行，一切都没有发生改变。当UMS线程执行需要进入内核的操作时，它切换到它的专属内核模式线程。

虽然线程有自己的执行环境，但是，同一个进程内部的所有线程都可以完全地读或者写该进程的虚拟地址空间。然而，一个进程中的线程不可能无意地引用另一个进程的地址空间，除非两种情况：第二个进程将它的一部分私有地址空间变成共享内存区；或者，第一个进程有权打开第二个进程，从而可以使用诸如ReadProcessMemory和Write ProcessMemory等跨进程的内存函数。

除了私有地址空间和一个或多个线程以外，每个进程还有一个安全环境和一个已打开句柄的列表，这些句柄指向诸如文件、共享内存区，或者像互斥体、事件或信号量等某个同步对象。

每个进程都有一个安全环境，存储在一个称为访问令牌的对象中。进程的访问令牌包含了该进程的安全标识和凭证。在默认情况下，线程没有自己的访问令牌，但是它们也可以获得一个访问令牌，因此单独的线程可以模仿另一个进程的安全环境－－包括在远程Windows系统上运行的进程－－而不会影响当前进程中的其他线程。

虚拟地址描述符(VAD，virtual address descriptor)是指一些数据结构，内存管理器利用这些数据结构来记录进程正在使用的虚拟地址。

Windows在进程模型上提供了一个扩展，称为作业。作业对象的主要功能是，使一组进程被当作一个整体来管理和维护。通过作业对象，可以对特定的属性进行控制，也可以对一个进程，或者所有与作业相关联的进程进行限制。作业对象也为所有与该作业相关联的进程记录下基本的审计信息，其中也包括曾经与该作业关联但是已经终止了的进程的审计信息。在某种程度上，作业对象弥补了Windows平台上缺乏结构化的进程树的不足，而且，它的功能在许多方面比UNIX风格的进程树更加强大。

（五）虚拟内存

Windows实现了一个基于平面(线性)地址空间的虚拟内存系统，使每个进程感觉自己独立拥有一个很大的私有地址空间。虚拟内存提供了一个内存逻辑视图，它可能并不对应于内存的物理布局。在运行的时候，内存管理器借助于硬件的支持，将虚拟地址转译或者映射成真正存放数据的物理地址。操作系统通过控制这一保护和映射机制，可以确保一个进程不会闯入到另一个进程中，也不会改写操作系统的数据。

因为大多数系统所拥有的物理内存，比当前正在运行的进程所用到的虚拟内存总量要少得多，所以，内存管理器会将内存中的有些内容转移或者翻到磁盘上。将数据翻到磁盘上以后，就可以释放出这部分物理内存，因此，这些物理内存可以被别的进程所用，或者用于操作系统自身。当线程访问一个已被翻到磁盘上的虚拟地址时，虚拟内存管理器会将磁盘上的信息装回内存中。应用程序无须任何改变就可以利用这种分页功能，因为在硬件的支持下，内存管理器无须任何关于进程或线程的知识，也无须进程或线程的协助，就可以实现分页。

虚拟地址空间的大小随着大小随硬件平台而有所不同。在32位X86系统中，总的虚拟地址空间有一个理论上的最大值4GB。在默认情况下，Windows将这部分地址空间的一半(4GB虚拟地址空间中较低的一半，x00000000~x7FFFFFFFF)则用作它自己的被保护的操作系统内存。低一半地址空间的映射关系会发生变化，以便总是反映出当前正在执行的进程的虚拟地址空间，而高一半地址空间的映射关系总是由操作系统的虚拟内存构成。Windows支持一些引导选项，可以使那些运行带有特殊标记的程序(在可执行映像文件的头部设置了大地址空间感知标志)的进程能够使用多达3GB的私有地址空间(给操作系统留下1GB)。这一选项使得像数据库服务器这样的应用程序可以将一个数据库的更多内容保留在进程的地址空间中，从而减少映射该数据库的子集视图的需求。

虽然3GB比2GB更好，但是，对于映射非常大的数据库(许多个GB)而言，虚拟地址空间仍然不足。针对在32位系统上的这种需求，Windows提供了一种被称为地址窗口扩展(AWE,Address Windowsing Extension)的机制，使得32位应用程序可以申请多达64GB物理内存，然后将内存视图或者窗口映射到它的2GB虚拟地址空间中。虽然AWE将管理“虚拟内存－物理内存”映射关系的负担放到了程序员的身上，但是，它确实解决了问题，使得进程能够直接访问更多的物理内存，超过了它的32位进程地址空间一次能够映射的数量。

64位Windows为进程提供了更大的地址空间：在IA-64系统上为7152GB,x64系统上为8192GB。64位地址空间的大小超过了170亿GB，但当前的64位硬件限制了地址空间比该值要小，而在当前的64位Windows中，由于Windows实现的限制，此地址空间又被降低到8192GB(8TB)。

（六）内核模式和用户模式

为了避免用户应用程序访问和/或修改关键的操作系统数据，Windows使用了两种处理器模式(即使运行Windows的底层处理器支持多于两种模式)：用户模式和内核模式。用户程序代码运行在用户模式下，而操作系统代码(比如系统服务和设备驱动程序)运行在内核模式下。内核模式是指这样一种处理器执行模式：它允许访问所有的系统内存和所有的CPU指令。通过让操作系统软件比应用软有更高的特权级，处理器为操作系统设计者提供了一层必要的保护，可以确保行为不正常的应用程序不会破坏系统的整体稳定性。

注：x86和x64处理器架构定义了四种特权级，或者称为四个环(ring)，来保护系统代码和数据不会被低级别的代码恶意地或无意地改写。Windows使用特权0(或称0环)作为内核模式，特权级3(或称3环)作为用户模式。Windows之所以只用两级，是因为它过去支持的一些硬件架构只实现了两个特权级。

虽然每个Windows进程都有自己私有的内存空间，但是内核模式的操作系统和设备驱动程序代码共享同一个虚拟地址空间。虚拟内存中的每一个页面都被标记了处理器必须在什么访问模式下才可以读和/或写该页面。系统空间的页面只有在内核模式下才可以访问，而用户地址空间中的所有页面都可以在用户模式下访问。只读页面在任何模式下都是不可写的。此外，在支持不可执行内存保护的处理器上，Windows将包含数据的页面标记为不可执行，从而防止数据区域被无意或恶意地当作代码来执行。

对于在内核模式下运行的组件，32位Windows对它们所使用的私有系统内存并不提供读写保护。换句话说，一旦进入了该内核模式，操作系统和设备驱动程序的代码可以完全访问系统空间的内存，也可以绕过Windows的安全机制直接访问对象。因为有大量的Windows操作系统代码运行在内核模式下，所以，很关键的一点是，对在内核模式下运行的组件必须要谨慎地设计和测试，以确保它们不会破坏系统的安全性，也不会造成系统的不稳定。

由于缺少保护，因此，在加载第三方设备驱动程序的时候需要加倍的小心，因为一旦进入内核模式，这些软件就可以完全访问所有的操作系统数据。这一弱点也正是Windows要引入驱动程序签名机制的原因之一。引入驱动程序签名机制以后，当未签名的即插即用驱动程序企图加入系统中时，Windows会警告用户，并且阻止其加入系统。还有一种被称做驱动程序检验器(Driver Verifier)的机制，可以帮助设备驱动程序的编写者找到驱动程序中可引发安全性或可靠性问题的缺陷(比如缓冲区溢出或者内存泄漏)。

在64位版本的Windows中，内核模式代码签名(KMCS，Kernel Mode Code Signing)策略规定，64位设备驱动程序(不仅仅即插即用驱动程序)必须要经过某个主码认证权威机构发放的密钥来签名。用户不能明确地强制安装未经签名的驱动程序，即使管理员用户也不行，但有一个一次性的例外，这一限制可以在系统引导时手工禁止，即，在引导时按下F8键，选择高级引导选项“禁用驱动程序强制签名(Disable Driver Signature Enforcement)”。这会导致在桌面壁纸上出现一个水印，同时特定的数字版权保护(DRM)特性被关闭。

用户应用程序在进行系统服务调用时，会从用户模式切换到内核模式下。从用户模式转换到内核模式，可以通过专门的处理器指令来完成，该指令会将处理器切换到内核模式下，并进入内核中的系统服务分发代码，进一步调用Ntoskrnl.exe或win32k.sys中适当的内部函数。在将控制返回给用户线程以前，处理器的模式被切换回用户模式。通过这种方法，操作系统将自身和它的数据保护起来，使它们不会被用户进程看到或者修改。从用户模式到内核模式的转换(或者从内核模式回到用户模式的转换)本身并不会影响线程的调度－－模式转换并不是环境切换。

因此，很自然地，对于一个用户线程来说，它一部分时间在用户模式下运行，另一部分时间在内核模式下运行。实际上，因为图形和窗口系统的大部分也运行在内核模式下，所以，图形密集的应用程序花在内核模式下的时间比在用户模式下的时间还要多。

与模式有关的性能计数器

对象：计数器	功能
Processor:%Privileged Time	在指定的间隔内，单个CPU(或者所有的CPU)运行在内核模式下的时间所占的百分比
Processor:%User Time	在指定的间隔内，单个CPU(或者所有的CPU)运行在用户模式下的时间所占的百分比
Processor:%Privileged Time	在指定的间隔内，一个进程中的线程运行在内核模式下的时间所占的百分比
Processor:%User Time	在指定的间隔内，一个进程中的线程运行在用户模式下的时间所占的百分比
Processor:%Privileged Time	在指定的间隔内，一个线程运行在内核模式下的时间所占的百分比
Processor:%User Time	在指定的间隔内，一个线程运行在用户模式下的时间所占的百分比

  （六）终端服务及多个会话

终端服务指的是在单个系统中，Windows对于多个可交互用户会话的支持。利用Windows的终端服务，一个远程用户可以在另一台机器上建立一个会话，并且登录进去，在该服务器上运行应用程序。服务器把图形用户界面传送到客户机，客户机把用户的输入传回服务器。

第一个会话被认为是服务会话，或者零号会话，它包含了宿纳系统服务的进程。在机器的物理控制台上的第一个登录会话为一号会话，而其他的会话可以通过远程桌面连接程序(MStsc.exe)来建立，或者能过使用快速用户切换来建立。

Windows客户机版本允许单个远程用户连接到机器上，但如果有人已经在控制台上登录了，则工作站会被锁住(也就是说，一个人可以用本地方式或远程方式使用Windows客户机系统，但不能同时以这两种方式来使用该系统)。

Windows服务器系统支持两个并发的远程连接(这是为了方便远程管理)，以及两个以上的远程会话(只需要经过适当的授权许可，并且系统被配置为终端服务器)。

所有和Windows客户机版本都支持通过一种被称为快速用户切换的特性，在本地创建多个会话。当用户选择断开其会话，而不是注销其登录时，当前会话仍然保留在系统中，而系统返回到主登录屏幕。如果一个新的用户登录进来，则新建一个会话。

（七）对象和句柄

在Windows操作系统中，内核对象是指某个静态定义的对象类型的单个运行时实例。对象类型由系统定义的数据类型、在该数据类型的实例上进行操作的一组函数，以及一组对象属性构成。如果你编写Windows应用程序，那么，你可能会遇到进程、线程、文件和事件对象，这只是对象的一些例子而已。这些对象都是以Windows创建和管理的低层对象为基础的。在Windows中，任何进程都是进程对象类型的实例，文件是文件对象类型的实例。

对象属性是对象中的数据域，每个对象属性定义了对象的一部分状态。对象方法，即操纵对象的手段，通常用于读取或者改变对象的属性。

对象和普通数据结构之间最根本的区别是，对象的内部结构是不透明的。你必须调用一些对象服务才可以获得对象内部的数据，或者把数据放到对象内部。你不能直接读取或者改变一个对象内部的数据。这一区别将对象的底层实现与那些仅仅使用该对象的代码隔离开来，此技术使得对象的实现可以随着时间而很容易地改变。

借助于一个被称为对象管理器的内核组件，Windows中的对象提供了一种便捷的途径来实现下列四个重要的操作系统任务：

n为系统资源提供可供人读的名称。

n在进程之间共享资源和数据。

n保护资源，避免未授权的访问。

n引用跟踪，这使得系统能够知道一个对象何时不再有用，从而可以被自动释放。

（八）安全性

Windows的核心安全功能包括：针对所有可共享系统对象的自主保护和强制完整性保护，安全审计，登录时候的用户认证，以及禁止用户通过访问未初始化资源的做法来访问其他用户已释放的资源。

Windows有三种对对象的访问控制形式。第一种控制形式称为自主访问控制。其做法是，由对象的所有者授权或者拒绝其他人访问这些对象。当用户登录到系统中时，他们会得到一组安全凭证，或者一个安全环境。当他们试图访问对象时，系统会将他们的安全环境与他们要访问的对象上的访问控制列表进行比较，以确定他们是否可以执行所请求的操作。

当自主访问控制不能满足需要时，应该使用特权访问控制。这种方法可以确保：即使对象的所有者当前无法联系到，也有人可以访问被保护的对象。在这种情况下，在Windows中，管理员能够接管这些文件的所有权，从而可以根据需要管理它们的权限。

最后，当需要额外的一层安全控制以实现在同一个用户账户内部的对象访问保护时，需要使用强制完整性控制。它既被用于将Internet Explorer的保护模式与用户的配置隔离开，也被用于保护那些由提升了特权的管理员账户所创建的对象，避免被未提升特权的管理员账户所访问。

安全性遍及Windows API接口的各个方面。Windows子系统实现了基于对象的安全性，其方式与操作系统的做法相同；Windows子系统在共享的Windows对象上设置Windows安全描述符，防止它们遭受非法访问。

（九）注册表

注册表是系统数据库，它包含了引导和配置系统所必需的信息、全系统范围内控制Windows操作的软件设置、安全数据库，以及针对每个用户的配置设置。同时，注册表也是一个反映内存中易失数据的窗口。

    （十）Unicode

Unicode是一个国际字符集标准，它为世界上绝大多数已知的字符集定义了唯一的16位值。Windows的大多数内部文本是以16位宽度的Unicode字符来存储和处理的。因为许多应用程序只处理8位ANSI字符串，所以，接受字符串参数的Windows函数都有两个入口点：一个Unicode版本和一个ANSI版本。如果调用Windows函数的窄字符版本，则会有些微的性能影响，因为输入的字符串参数在被系统处理以前，要先转成Unicode，而输出的参数在被返回给应用程序以前，也要从Unicoe转成ANSI字符串。

无论哪个语言版本的Windows，它们都包含同样的函数。Windows不再使用多种不同的语言版本，而是使用一份全球统一的二进制代码，这样，同一份安装可以支持多种语言。应用程序也可以利用这一套Windows函数，做到同一份全球统一的应用程序二进制代码可以支持多种语言。