Kernel Mode and User Mode

The most significant aspect of this change is that graphics services, which used to run in user mode like applications, now run in kernel mode like most of the operating system. The idea behind kernel mode and its alternative, user mode, is to separate applications from the operating system. Applications run in user mode; operating systems run in kernel mode.

Kernel mode is a highly privileged mode of operation where the code has direct access to all memory, including the address spaces of all user-mode processes and applications, and to hardware. Processes running in kernel mode have access to advanced CPU features for I/O and memory management. However, operating system memory is strictly protected and this protection is enforced by the processor. Applications cannot directly access hardware or the memory of any kernel-mode service. Kernel mode is also known as supervisor mode, protected mode, and Ring 0.

Note

In earlier documentation, the terms kernel and microkernel were used interchangeably. In this document, kernel refers to a highly privileged mode of processing. The Microkernel is a component of the core operating system that provides basic operating system functions, like thread dispatching, interrupt handling, and multiprocessor synchronization.

Applications run in user mode. They have access only to their own address space and must use established interfaces to obtain other system services. This protects the operating system and improves its performance.

Environment subsystems, like those supporting Win32, POSIX, and OS/2, and integral subsystems, like Security, run in user mode but have protected address spaces. Each subsystem is a separate process and the operating system protects its memory from other subsystems and applications.

Communication between Processes

The logical boundary that separates user-mode and kernel-mode processes is designed to make the system robust by preventing direct access to hardware and protecting the core operating system from bugs and unauthorized access by user-mode processes. A failing application will not interfere with the operating system or its support of other applications.

To cross this boundary, user-mode processes must use well-documented application program interfaces (APIs) to switch their threads from user mode to kernel mode. Such a conversion is called a kernel-mode transition. Kernel-mode threads can use Executive services but must be switched back to user mode to return control to the application.

Accessing an environment subsystem involves several kernel/user mode transitions and consumes substantial memory and processor time. This is an example of a graphics call in previous versions of Windows NT. It demonstrates that interprocess communication can be quite complex, even when optimized:

• The application uses an API to make a graphics call to a user-mode dynamic link library. The component that implements the call makes a kernel-mode trap call to the Executive to switch its thread and copy its call parameters from its user mode stack to its kernel mode stack. Then, the processor's stack register is switched to point to kernel mode. Now the thread can run in the Executive.

• Applications communicate with protected subsystems by using local procedure calls (LPC), an application-independent method of communication between components on the same computer. After the thread is switched to kernel mode, the Microkernel schedules the LPC for delivery.

• Using Fast LPC, an optimized communication method, the Microkernel recognizes that the call from the application involves a thread in the environment subsystem. It considers the calling application thread and the receiving subsystem thread to be paired. The receiving thread can now use the unexpired time from the sending thread.

• The graphics call parameters are passed to the receiving subsystem thread. The receiving thread switches back to user mode to fulfill the graphics request.

• The subsystem completes its task and then returns control to the waiting calling thread in the application by the same method.

• The calling thread (from the DLL) is switched back to user mode before returning control to the application.

Microsoft operating-system engineers also used the concept of a shared memory window to speed up communication. Data is placed in a temporary shared memory window administered by the Process Manager in the Executive. This lets the application see into the subsystem's memory and share data without using LPCs. However, because the application thread must still run in the Executive, kernel/user mode transitions and thread switches are still required.