Windows is one of the most popular operating systems in the world, running on millions of devices such as PCs, laptops, tablets, smartphones, servers, and more. But how does Windows work behind the scenes? What are the main components that make up its architecture, and how do they interact with each other? In this article, we will explore some of the core elements of Windows architecture, and learn how they provide various services and functions to applications and users.

Environment Subsystems and Subsystem DLLs

One of the features that makes Windows versatile and compatible with different types of applications is its support for multiple environment subsystems. An environment subsystem is a component that exposes a subset of the basic Windows executive system services to application programs. For example, Windows supports a POSIX subsystem that allows applications written for UNIX-like operating systems to run on Windows.

Each environment subsystem consists of two parts: a user-mode part that runs as a separate process (such as Posix.exe), and a kernel-mode part that runs as a dynamic-link library (DLL) loaded by the system process (such as Psxss.dll). The user-mode part communicates with applications through an application programming interface (API), while the kernel-mode part communicates with the executive system services through system calls.

Among all the environment subsystems supported by Windows, the most important one is the Windows subsystem (also known as Win32 or Win32k), which is required for Windows to run. The Windows subsystem controls the keyboard, mouse, and display, and provides graphical user interface (GUI) elements such as windows, menus, buttons, icons, etc. The user-mode part of the Windows subsystem is Csrss.exe (Client/Server Run-Time Subsystem), which handles console windows and GUI shutdown. The kernel-mode part of the Windows subsystem is Win32k.sys (Kernel-Mode Driver Framework), which handles window management, graphics device interface (GDI), user input, fonts, etc.

Memory Management

Another key component of Windows architecture is its memory management system. Memory management is responsible for allocating and freeing memory for processes, threads, drivers, and other system components. Memory management also implements virtual memory, which allows each process to have its own address space that is independent of physical memory.

Virtual memory enables processes to access more memory than what is physically available on the system. It also provides protection and isolation between processes by preventing them from accessing or modifying each other’s memory. Virtual memory is implemented by dividing the address space of each process into pages (usually 4 KB in size), which are mapped to frames (also 4 KB in size) in physical memory or disk.

The memory manager uses various data structures and algorithms to manage virtual memory. For example, it uses page tables to store the mapping information between pages and frames. It also uses page faults to handle situations when a process accesses a page that is not present in physical memory. In such cases, the memory manager either allocates a new frame for the page or swaps out another page from physical memory to disk.

One of the concepts that is important to understand in virtual memory management is reserved memory versus committed memory. Reserved memory is a portion of the address space that is set aside for future use, but does not consume any physical memory or disk space. Committed memory is a portion of the address space that is backed by physical memory or disk space, and can be accessed by the process. A process can reserve memory by using the VirtualAlloc function, and commit memory by specifying the MEM_COMMIT flag.

Another concept that is relevant to virtual memory management is shared memory. Shared memory is a mechanism that allows multiple processes to access the same portion of memory, either for communication or for efficiency. Shared memory can be implemented in different ways, such as memory-mapped files, shared sections, or shared data segments. Shared memory can improve the performance of the system by reducing the amount of memory duplication and disk I/O.

I/O Manager

The third key component of Windows architecture that we will discuss in this article is the I/O manager. The I/O manager is the component that handles all input/output requests from user-mode applications and kernel-mode drivers. The I/O manager provides a uniform and abstract interface for accessing various types of devices, such as disks, keyboards, mice, printers, network adapters, etc.

The I/O manager consists of several subcomponents, such as the I/O system services, the plug and play (PnP) manager, the power manager, and the device driver loader. However, the most important subcomponent of the I/O manager is the I/O system itself, which consists of three main elements: device objects, driver objects, and I/O request packets (IRPs).

A device object is a data structure that represents a logical or physical device in the system. A device object contains information about the device, such as its name, type, characteristics, flags, and device extension. A device object also has a pointer to a driver object, which represents the driver that controls the device.

A driver object is a data structure that represents a kernel-mode driver in the system. A driver object contains information about the driver, such as its name, base address, size, entry points, and driver extension. A driver object also has a pointer to a device object list, which contains all the device objects that are controlled by the driver.

An IRP is a data structure that represents an I/O request in the system. An IRP contains information about the request, such as its type, parameters, status, flags, and stack locations. An IRP also has a pointer to a device object, which indicates the target device of the request.

The I/O system has a layered structure, where each layer consists of one or more device objects and driver objects. Each layer performs some specific function or service for the I/O request, such as filtering, transforming, buffering, or routing. The layers are connected by pointers in the device objects and IRPs. The topmost layer is usually the user-mode application that initiates the I/O request. The bottommost layer is usually the hardware device that completes the I/O request. The intermediate layers are usually kernel-mode drivers that process the I/O request.

The I/O system works by passing IRPs from one layer to another through a series of function calls. Each layer can either complete the IRP (by setting its status and returning it to the previous layer), forward the IRP (by passing it to the next layer), or pend the IRP (by holding it until some event occurs). The I/O system also supports asynchronous and synchronous operations, cancellation and timeout mechanisms, error handling and recovery procedures, and security and access checks.

Conclusion

In this article, we have examined some of the main components of Windows architecture: environment subsystems and subsystem DLLs, memory management, and I/O manager. We have learned how they provide various services and functions to applications and users. We have also explored some of the internal structures and mechanisms that make up these components.