9. Windows Architecture

Page 139

II. THE WINDOWS OPERATING SYSTEM (KERNEL32.DLL PROGRAMMING)

Page 141

9. Windows Architecture

		In this chapter, we give an overview of the architecture of the Windows NT operating system. We have chosen to emphasize Windows NT because Microsoft has said that this is the future of Windows. The Windows 9x line will end with Windows 98, so all of us will be running a successor to Windows NT (the first of which is called Windows 2000) sooner or later. At the end of the chapter, we briefly discuss the differences between Windows 9x and Windows NT.

		This chapter is meant only to give you a general feeling for the Windows architecture. We will try not to go into more detail than is necessary for this purpose.

		Note that we will not discuss the 16-bit Windows operating system. This operating system is by all accounts obsolete, and it no longer seems necessary to compare the two operating systems (except perhaps in passing, in a few rare instances). Thus, the term Windows will always refer to one of the 32-bit Windows operating systems.

	Processes and Threads

		A Windows application is a collection of executable programs and support files. For instance, Microsoft Word is a well-known Windows application. A process is a running instance of a Windows application. Note that most applications allow the user to run multiple copies of the application at the same time. Each running instance is a separate process, with its own memory space.

		To be more specific, a process is a running instance of an application, together with a set of resources that are allocated to the running application.

		A thread is an object within a process that is allocated processor time by the operating system in order to execute code. In short, threads, not processes, execute

Page 142

		program code. Every process must have at least one thread. The purpose of threads, of course, is to allow a process to maintain more than one line of execution, that is, to do more than one thing at a time. In a multiprocessor environment (a computer with more than one CPU), Windows NT (but not Windows 9x) can assign different threads to different processors, providing true multiprocessing. In a single-processor environment, the CPU must provide time slices to each thread that is currently running on the system. We will discuss time slices in detail in Chapter 12, Threads.

	Windows Architecture

		Figure 9-1 shows an overview of the Windows NT architecture. Let us review some of the items shown in this figure.

		Kernel and User Mode

		A Pentium microprocessor has four privilege levels, also known as rings, that control such things as memory access and access to certain sensitive CPU instructions (such as those related to security). Every thread executes at one of these privilege levels. Ring 0 is the most privileged level, with complete access to all memory and CPU instructions. Ring 3 is the least privileged level.

		In order to maintain compatibility with non-Intel systems, the Windows operating systems support only two levels of privilege Ring 0 and Ring 3. When a thread is running in Ring 0, it is said to be in kernel mode. When a thread is running in Ring 3, it is said to be in user mode. Low-level operating system code executes in kernel mode, whereas, in general, user application code runs in user mode.

		Note that an application thread will switch from user mode to kernel mode when making certain API function calls that require a higher privilege level, such as those that involve accessing files or performing graphics-related functions. In fact, some user threads can spend more time in kernel mode than in user mode!

		However, when the kernel mode code is completed, the user thread is automatically switched back to user mode. This prevents the programmer from being able to write instructions that run in kernel mode the programmer can call only system functions that run in kernel mode.

		If you are running Windows NT, you can see for yourself when a thread is running in user mode and when it is running in kernel mode. To do this, start the Performance Monitor from the Administrative Tools item on the Start Menu. Select Add To Chart from the Edit menu. Then add % User Time and % Privileged Time from the Counters list. Next, do some graphics-intensive things, such as opening

Page 143

		Figure 9-1. Simplified Windows NT architecture

		Windows Paint. Figure 9-2 shows the results on my system at a particular moment. The white line is kernel mode percent time.

		It is interesting to note that device drivers run in kernel mode. This has two implications. First, an errant device driver, unlike an errant application, can bring down the entire system because it has access to all system code and memory. Second, it is possible for an application programmer to ''access" protected resources by writing a fake device driver, although writing device drivers is not an easy task.

Page 144

		Figure 9-2. User versus kernel mode

		Services

		Unfortunately, the term service is used in a variety of ways in the Windows environment. Here are some of its meanings that are relevant to our discussion.

		API service An API function or subroutine that performs an operating system "service," such as creating a file or drawing some graphics (a line or circle). For example, the CreateProcess API function is used to create a new Windows process.

		System service An undocumented function that is callable from user mode. These are often called by Win32 API functions to provide low-level services. For instance, the CreateProcess API function calls the NtCreateProcess system service to actually create the process.

		Internal service A function or subroutine that is callable only from kernel mode. These reside in the lower-level portions of Windows: the Windows NT executive, kernel, or Hardware Abstraction Layer (HAL).

Page 145

		System Processes

		System processes are special processes that support the operating system. Every Windows system has the following system processes (and more) running at all times. Note that all of these processes run in user mode except the system process.

		The idle process, which contains a single thread that monitors the CPU's idle time.

		The system process (unfortunate choice of name), which is a special process that runs only in kernel mode. Its threads are called system threads.

		The Session Manager (SMSS.EXE).

		The Win32 subsystem (CSRSS.EXE).

		The WinLogon process (WINLOGON.EXE).

		You can verify that these system processes are indeed running by viewing the Processes tab of the Windows NT Task Manager. Also, Figure 9-3 shows the rpiEnumProcsNT application that we will create in Chapter 11, Processes. (We will also create a Windows 9x version.) You can see the idle, system, smss, csrss, and WinLogon services in the Processes listbox.

		Let us look briefly at some of these system processes:

		The Session Manager process

		The Session Manager (SMSS.EXE) is one of the first processes to be created when the operating system boots. It performs important initialization functions, such as creating system environment variables, defining MS-DOS devices names such as LPT1 and COM1, loading the kernel mode portion of the Win32 subsystem (discussed later in this section), and starting the logon process WinLogon.

		The WinLogon process

		This system service handles user logons and logoffs and processes the special Windows key combination Ctrl-Alt-Delete. WinLogon is responsible for starting the Windows shell (which is usually Windows Explorer).

		The system process

		This process contains system threads, which are kernel mode threads. Windows and various device drivers create system process threads for various reasons. For example, the memory manager creates system threads for performing virtual memory tasks, the cache manager uses system threads for managing cache memory, and the floppy disk driver uses a system thread to monitor the floppy drives.

Page 146

		Figure 9-3. rpiEnumProcsNT

		The Win32 Subsystem

		The Win32 subsystem is the main subject of this book. It is one type of Windows environment subsystem. Other Windows environment subsystems (not pictured in Figure 9-1) include POSIX and OS/2. POSIX stands (more or less) for "portable operating system based on UNIX," which provides limited support for the UNIX operating system.

		The purpose of an environment subsystem is to act as an interface between user applications and relevant portions of the Windows executive. Each subsystem exposes different functionality from the Windows executive. Every executable file is bound to one of the subsystems.

		In fact, if you look at an executable file (EXE) with Windows' built-in QuickView viewer, you will find a line such as:

		Subsystem:    Image runs in the Windows GUI subsystem.

Page 147

		This says that the executable is bound to the Windows GUI subsystem, which is another way of saying that it is bound to Win32. If you use QuickView on a command-based executable (such as ftp.exe, found in the Windows system directory), you will see the line:

		Subsystem:   Image runs in the Windows character subsystem.

		This is console-based Win32 application.

		As we have seen, the Win32 subsystem houses the Win32 API, in the form of DLLs, such as KERNEL32.DLL, GDI32.DLL, and USER32.DLL.

		It is interesting to note that under Windows NT 4.0, Microsoft moved part of the Win32 subsystem from user mode to kernel mode. In particular, the kernel mode device driver WIN32K.SYS controls the display of windows (with a lowercase w), screen output, keyboard and mouse input, and message passing. It also contains the Graphical Device Interface library (GDI.DLL), used for drawing graphical images and text.

		Calling a Win32 API function

		When an application calls a Win32 API function in the Win32 subsystem, one of several things may happen:

		If the subsystem DLL (such as USER32.DLL) that exports the API function contains all code necessary to execute the function, it will do so and return the results.

		The API function may require that additional code within the Win32 subsystem (but outside of the DLL that exports the function) be called in support of the function.

		The function may need the services of an undocumented system service. For instance, to create a new process, the CreateProcess API function calls the undocumented system service NtCreateProcess to actually create the process. This is done through the NTDLL.DLL function library, which helps make the transition from user to kernel mode.

		The Windows Executive

		Windows executive services make up the low-level kernel mode portion of Windows NT and are contained in the file NTOSKRNL.EXE.

		Executive services are sometimes divided into two groups: the executive (upper layer) and the kernel (lower layer). The kernel is the lowest layer of the operating system, performing the most fundamental services, such as:

		Thread scheduling

		Exception handling

Page 148

		Interrupt handling

		Synchronization of processors in a multiprocessor system

		Creating kernel objects

		Here are some of the major portions of the executive:

		Process and Thread Manager This component creates and terminates both processes and threads, using the services of the low-level kernel.

		The Virtual Memory Manager This component implements virtual memory, which we will discuss in some detail in Chapter 13, Windows Memory Architecture.

		The Input/Output Manager This component implements device-independent input/output and communicates with device drivers.

		The Cache Manager This component manages disk caching.

		The Object Manager This component creates and manages Windows executive objects. Windows uses objects to represent its various resources, such as processes and threads.

		Runtime Libraries These components contain runtime library functions, such as string manipulation functions and arithmetic functions.

		The Hardware Abstraction Layer (HAL)

		The hardware abstraction layer (or HAL) is a kernel mode library (HAL.DLL) that provides a low-level interface with the hardware. Windows components and third-party device drivers communicate with the hardware through the HAL. Accordingly, there are many versions of HAL to accommodate different hardware platforms. The appropriate HAL is chosen when Windows is installed.

	Differences Between Windows 9x and Windows NT

		Let us outline briefly some of the major differences between the Windows 9x and Windows NT operating systems.

		Windows NT supports symmetric multiprocessing (SMP), that is, Windows NT can use more than one processor at a time. The term symmetric refers to the fact that Windows NT treats each processor equally and assigns operating

Page 149

		system threads (or user application code) to all processors at different times (as opposed to dedicating one processor for the operating system).

		Windows NT runs on platforms other than Intel-based systems. For instance, Windows NT will run on a PowerPC-based system.

		Windows NT is a true 32-bit operating system, whereas Windows 9x contains a considerable amount of 16-bit code that has been ported from Windows 3.1. As a result, under Windows 9x, portions of operating system memory are accessible from user mode, making Windows 9x far less stable than Windows NT.

		Windows NT implements significant file system security, which is missing from Windows 9x.

		Under both operating systems, applications may share memory. However, under Windows NT, only those applications that specifically request a shared memory resource can see this memory, whereas under Windows 9x, all shared memory is visible by all running programs.