《深入解析Windows操作系统》 第4版 §2.2 操作系统模型

 

在大多数多用户操作系统中，应用程序与操作系统本身是隔离的——操作系统内核代码运行在处理器的特权模式下（在本书中称为内核模式，kernel mode），可以访问系统数据和硬件；应用程序代码运行在处理器的非特权模式下（称为用户模式，user mode），只有很有限的一组接口可以使用，对系统数据的访问受到限制，并且无法直接访问硬件。当用户模式程序调用一个系统服务时，处理器捕获到该调用，然后将调用线程切换到内核模式。当该系统服务完成时，操作系统将线程环境切换回用户模式，并允许调用者继续执行。

 

与大多数UNIX系统类似，Windows是一个庞大而完整的操作系统；操作系统的大部分代码与设备驱动程序代码共享同样的受保护的内核模式内存空间。这意味着，操作系统的任一组件或者设备驱动程序都有可能破坏其他系统组件所使用的数据。

 

Windows是一个微内核系统吗

 

尽管有些人如此声称，但是按照微内核（microkernel）的典型定义，Windows并不是一个微内核系统。在微内核的定义中，操作系统的主要组件（比如内存管理器、进程管理器和I/O管理器）运行在各自独立的进程中，它们有自己私有的地址空间，在这一组组件之上是微内核提供的一组原语服务。例如， CMU（Carnegie Mellon University，卡耐基·梅隆大学）的Mach操作系统是一个现代的微内核体系结构的例子，它实现了一个最小的内核，包括线程调度、消息传递、虚拟内存和设备驱动程序。任何其他的组件，包括各种API、文件系统和网络等，都运行在用户模式下。然而，Mach微内核操作系统的商业版本实现，往往至少将所有的文件系统、网络和内存管理代码放在内核模式中运行。原因很简单：纯粹的微内核设计在商业上是不切实际的，因为它的效率太低。

 

那么，Windows中有那么多代码运行在内核模式下，是否就意味着它比一个真正的微内核操作系统一定更加容易崩溃呢？并非如此。请考虑下面的情景。假设在操作系统的文件系统代码中有一个错误，该错误会导致文件系统时不时地崩溃。在一个传统的操作系统中，内核模式代码（比如内存管理器或者文件系统）中的错误很可能会使整个操作系统崩溃。在一个纯粹的微内核操作系统中，这样的组件运行在用户模式下，所以，在理论上说，这样的错误只是意味着该组件的进程将会退出。但是，从实际的角度来看，系统将会崩溃，因为要从这样一个关键进程的失败中恢复过来往往是不可能的。

 

当然，操作系统的所有组件都是受保护的，不会被错误的应用程序破坏，因为应用程序不能直接访问操作系统中特权部分的代码和数据（尽管它们可以快捷地调用其他的内核服务）。Windows无论是作为一个应用服务器，还是一个工作站平台，从操作系统核心服务（比如虚拟内存管理、文件I/O、网络，以及文件和打印共享）的角度来看，它都很快地赢得了健壮性和稳定性两方面的良好声誉，之所以如此，操作系统组件的这种保护性正是原因之一。

 

Windows的内核模式组件也体现了基本的面向对象设计原则。例如，它们通常并不会直接进入另一个组件的数据结构来访问该组件所维护的信息。相反，它们利用正式的接口来传递参数，以及访问或修改相应的数据结构。

 

虽然 Windows内部普遍地使用了对象来表达共享的系统资源，但是，从严格意义上讲，Windows并不是一个面向对象的系统。为了移植性的考虑， Windows操作系统的大多数代码是用C语言编写的，因为C语言的开发工具更为广泛可用。C语言并不直接支持面向对象的概念，比如数据类型的动态绑定、多态函数或者类继承等。因此，Windows中C语言版本的对象实现只是借用了（但并不依赖于）特定面向对象语言的特性。