In-depth analysis of Windows operating system Reading Notes (2)

Design goals set by the Windows NT design team at the beginning of the project:

• Scalability. After the market demand changes, we can freely increase and change.
• Portability. It must be able to run on a variety of hardware architectures. After a new hardware architecture emerges, it should be easy to migrate.
• Reliability and robustness. The system should be able to protect itself and not work due to internal errors or external tampering. Applications should be unable to harm the operating system or other applications.
• Compatibility. Compatible with the OS before Ms, including DOS and winsows98; compatible with other OS, including OS/2 and nerware.
• Performance. Keep other targets as fast as possible.

Windows NT is not a microkernel system. In the microkernel system, the main components run in their independent processes. They have their own private address controls. On this group of components, they are a set of primitive services provided by the microkernel. The pure microkernel design is impractical for business purposes. It is very inefficient to switch between the kernel mode and the user mode without interruption.

Windows is a symmetric multi-processing (SMP, sysmmetric multiprocessing) operating system that does not have a primary processor, and all the processors share a unique memory space.

The overall structure of Windows NT is divided into user mode and kernel mode. The user mode mainly includes some processes and subsystem DLL. The kernel mode includes the Windows execution body, Windows kernel, device driver, hardware abstraction layer, and window graphics system.

Processes in user mode are divided into the following four types:

• The system supports processes. For example, login or Process Manager, these processes are not Windows Services, they are not started by the Service Manager.
• Service process. Windows Service, which runs independently of user logon.
• User application.
• Environment Subsystem server process. Supports the operating system environment. The environment here refers to the personalized part that the operating system presents to users or programmers.

In Windows, a user application does not directly call the original Windows operating system service, but initiates a call through one or more subsystem Dynamic Link Libraries (DLLs.

Subsystem DLL role: converts a documented function into some appropriate internal Windows system service calls.

The kernel mode components include the following parts:

• Windows executive ). Includes basic operating system services, such as memory management, process and thread management, security, I/O, network and cross-process communication.
• Windows kernel ). It consists of a group of low-level operating system functions, such as thread scheduling, interruption, and exception distribution. It also provides a set of routines and basic objects. The rest of the execution uses these routines and objects to implement higher-level functions.
• Device drivers ). It includes both hardware device drivers and file systems and network drivers. However, a hardware device calls the user's I/O function to a specific hardware device I/O Request.
• Hardware Abstraction Layer (HAL ). A layer of special code that isolates the kernel, device drivers, and the rest of Windows execution bodies from platform-related hardware differences.
• Window and Graphical System ). Implements graphical user interface (GUI) functions, such as window processing and user interface controls.

Windows supports portability in the following two aspects:

• Adopt hierarchical design. The High-level part of the system does not need to consider the differences between architectures or the differences between hardware platforms.
• The vast majority of Windows code is written in C language, a few are written in C ++, and a few are compiled in assembly.

Windows initially had three environment subsystems: OS/2, POSIX, and windows. Among the three subsystems, the Windows subsystem is very special. If Windows does not support running, the other two subsystems are configured to start on demand, while the Windows subsystem must always be running.

The Environment Subsystem startup information backpack is stored in the registry key HKLM \ System \ CurrentControlSet \ Control \ Session Manager \ subsystems.

Environment Subsystem role: exposes a subset of Basic Windows system services to applications. Each subsystem provides access to different parts of the Windows native service, which means that applications built on a certain subsystem can do things, is another application built on different subsystems. Function calls cannot be mixed between different subsystems.

When an application calls a function in the subsystem DLL, there are three types:

• This function is fully implemented in the subsystem DLL and runs in user mode.
• This function requires one or more windows execution bodies to be called.
• This function requires that you complete some work in the Environment Subsystem process. In this case, the function sends a client/server request to the Environment Subsystem in the form of a message, so that the environment subsystem can execute an operation, then the subsystem DLL waits for a response and returns it to the caller after receiving the response.

The Windows subsystem consists of the following components:

• Environment Subsystem (csrss.exe ). Including: 1. console window; 2. creates or deletes processes and threads. 3. support part of the 16-bit Virtual DOS machine process; 4. other functions, such as gettempfile and definedosdevice.
• Kernel Mode Device Driver (win32k. sys ). Including: 1. Window Manager; 2. Graphic device interface.
• Subsystem DLL. They translate documented windows api.exe into ntoskrnl.exe and win32k. sys appropriate and mostly undocumented kernel-mode system service calls.
• Graphics Device Driver. A graphic display driver related to hardware. Printer Drivers and video micro-port drivers.

The application calls the Standard Users function to create a user interface control on the display. The window manager sends these requests to GDI, and GDI passes them to the Graphics Device Driver, within the device driver, these requests are formatted to suit specific display devices. The display driver is paired with the video micro-port driver to support video display.

The GDI function is located in the middle of an application and a graphical device. Responsible for Interpreting Application graphics output requests and sending these requests to the graphics display driver.

In Windows NT4, the windows and graphic code originally running in the Windows subsystem process environment are moved to a set of callable system services and run directly in kernel mode. The reason for this is that to improve the overall system performance, placing the Windows Graphics subsystem in a separate server process will inevitably lead to multiple thread and process environment switches, this consumes a considerable amount of CPU cycle and memory resources.

Ntdll. dll: A special system support library, mainly used for subsystem DLL. It contains two types of functions: 1. system Service Distribution stubs, which call the Windows executor system service; 2. internal functions are supported for subsystems, subsystem DLL, and other native image files.

The system service distribution stub provides interfaces for Windows execution system services. In user mode, you can use these interface functions to call the system services of Windows execution bodies. For each of these functions, NTDLL contains an entry point with the same name. The code in the function contains the mode switching commands related to the processor architecture, the command can be converted to the kernel mode to call the system service distributor. The dispatcher then calls the system service in the kernel mode after the key is specified.

Windows execution is the upper layer of ntoskrnl.exe, which includes the following types of functions:

• You can call the export functions in user mode. These functions are called system services and exported through NTDLL. Most of these services can be accessed through windows APIs, or you can access it through the API of another environment subsystem.
• The device drive function that can be called through the deviceipcontrol function.
• Export functions that can only be called in kernel mode, and these functions have been documented in Windows DDK or Windows ifs kit.
• This function is called in kernel mode, but is not documented in Windows DDK or Windows ifs kit.
• A function defined as a global symbol but not exported.
• It is not defined as a global symbol, but a function in a module.

The Windows execution body contains the following main components:

• Configuration Manager. Implements and manages the system registry.
• Process and thread manager. Create or plant processes and threads.
• Security Reference monitor. Enforce security policies on local computers.
• I/O manager. Implement device-independent I/O operations and assign these operations to appropriate device drivers for further processing.
• Plug-and-play (PNP) manager. Allocate appropriate hardware resources, such as IRQ, DMA channel, and memory location, based on the resource requirements of each device.
• Power Manager. Coordinates power events and generates power management I/O notifications to device drivers.
• WDM Windows Management Standard routine. Allows device drivers to publish information about performance and configuration and receive commands from the WMI Service in user mode.
• Cache manager. By allowing the recently used disk data to reside in the memory for quick access, the performance of I/O operations based on files and love you is improved.
• Memory Manager. Implements virtual memory.
• Logical prefetch. Accelerate the startup process of the system and process.

The Windows execution body contains four main supported functions:

• Object Manager
• LPC: Information is transmitted between Client Processes and server processes on the same machine. LPC is a more flexible optimized version of RPC.
• A group of public Runtime library functions that involve the scope of pipe meal.
• Execution body support routines.

The core is composed of a group of functions in ntoskrnl.exe and the low-level support for the hardware architecture. This set of functions in ntoskrnl.exe provides some of the most basic mechanisms, such as thread scheduling and synchronization services. The underlying hardware support varies with the structure of each processor. Kernel code is mainly written in C language. For tasks that require special processor commands and registers and are not easy to access in C code, the form of assembly code is retained.

The kernel provides a set of well-defined and predictable low-level primitives and Mechanisms for the operating system, so that the high-level components in the execution body can do what they need to do. The kernel implements the basic mechanism of the operating system and avoids various policy decisions, thus separating itself from the rest of the execution body. It leaves almost all policy decisions to the execution body. The only exception is thread scheduling and distribution, which is implemented by the kernel itself.

The kernel implements a set of simpler objects and becomes the kernel objects. They help the kernel control the central processing process and support the creation of the execution body objects. The vast majority of objects in the execution layer wrap one or more kernel objects and combine their kernel attributes.

Another important task of the kernel is to abstract the executor and the device driver from the various hardware architectures supported by windows, or isolate the differences between these variants, even for these hardware-related features, we try to maximize the public code when designing the kernel. These interfaces and the architecture duali interface can be called on any machine, and the interface semantics is always the same whether the first code is different with the architecture or not.

Hal is a load-able, kernel-mode module that provides underlying interfaces for the hardware platform where windows is currently running. It hides hardware-related details.

Device Drivers are loadable Kernel Mode modules that establish links between the I/O manager and the corresponding hardware.

The driver runs in kernel mode and is located in one of the following three execution environments:

• In the environment of the user thread that initiates the I/O function.
• In the kernel-mode system thread environment.
• As the result of an interruption.

In Windows, the device driver does not directly maintain the hardware, but calls functions in Hal to interact with the hardware.

Device drivers can be divided into the following types:

• Hardware driver.
• File System driver.
• File System Filter Driver.
• Network redirection and server.
• Protocol Driver.
• The kernel stream filter driver.

To add user-written kernel mode code to the system, installing the driver is the only method, therefore, some programmers regard writing device drivers as a gradient method to access the internal functions and data structures of the operating system.

Currently, the new driver model is WDM (Windows Driver Model). From the perspective of WDM, drivers can be divided into the following three types:

• Bus driver. It provides services for bus controllers, adapters, bridges, or any device with sub-devices. A bus driver is a required driver, which is usually provided by Microsoft.
• Functional drivers. It is the main device driver and provides operable interfaces for corresponding devices. It is also required for functional drivers. It knows a specific device best, and it is often the only driver that can access the registers related to the device.
• Filter Driver. It is used to add new features to a device, or modify the I/O requests or responses from other devices. The filter driver is optional and can have any number.

In a WDM driver environment, a device is not controlled by a single driver in all its aspects: A bus driver is responsible for reporting devices on its bus to the PnP Manager, A functional driver is used to manipulate the device.

In most cases, low-level Filter Drivers change the behavior of device hardware, and the upper-layer filter drivers provide some value-added features for a device.

The following system processes appear in every Windows System:

• Idle process (idle ).
• Session Manager (smss.exe ).
• Windows subsystem (csrss.exe ).
• (Winlogon.exe ).
• The Service Control Manager (services.exe and the subservice process created by the notebook (for example, the General Service master process svchost.exe of the system ).
• Certificate Server (lsass.exe ).

The system process is the parent of a special thread. This special thread can only run in kernel mode, which is called the Kernel Mode System thread. In drivers, or in any other device driver loaded in.

The kernel creates a system thread called the balance set manager, which is awakened once, and may send various events related to scheduling and memory management.

Session Manager is the first user mode process created in the system. The Kernel Mode System thread responsible for completing the execution body and kernel initialization creates the actual SMSs process in the final stage.

The process of entering the Windows system: the reason why the worker does not have the parent process in the process tree.

Winlogon is not only active when a user logs on or logs out, but also when it captures SAS (CTRL + ALT + DEL) on the keyboard.

In Windows, "service" can refer to either a server process or a device driver.

The Service Control Manager is a special system process. The affected file is \ windows \ system32 \ services.exe. It is responsible for starting and stopping service processes and interacting with these service processes, the so-called service program actually only calls the Windows Image of some special windows functions.

The Service generally has three names: the running process name you see in the System, the internal name in the registry, and the display name given in the services management tool.