Windows Kernel Principle and Implementation: Windows Subsystem

When a user logs on (even if it is a terminal service) to Windows, the operating system creates a session for the user. Each subsystem session has its own session space, resources belonging to a session are allocated from the session space.

Generally, the graphic interface application we run runs on the default desktop. Interactive window stations have independent clipboard, keyboard, mouse, and display. Only one of the three desktops is activated at any time, and the input and output devices are owned by the active desktop. A Windows subsystem session has a Raw Input Thread that reads the original Input event from the Input device, generates a message, and sends it to the correct Thread message queue. DirectX (including DirectDraw and Direct3D) allows applications to directly manipulate the display hardware without the GDI graphics engine. A process defines an execution environment, including its own private address space, a handle table, and a secure environment. A thread is a control flow, has its own call stack, which records its execution history. Each thread represents a command execution sequence and is also a scheduling unit. Windows is a multi-process operating system environment, but it schedules the allocation of processor resources by thread.

In the Windows Kernel Structure, the core mechanism of processes and threads is implemented in the microkernel, while the management mechanism is implemented in the execution body. This is in line with the principle of "separation of mechanisms and policies. Thread Scheduling is completed by the microkernel, while the creation of threads and processes and the setting of various management attributes are completed by the execution body. In addition to accepting System calling services from applications, the Windows Kernel also has some threads for various purposes. These threads run in a special environment called the System process. The thread of a System process is called a system thread. A group of System worker threads represent the operating system or other application processes to complete some special work. The device driver or executor can create a thread in the caller process or in the System process. Alternatively, you can call the execution body function ExQueueWorkItem or the I/O manager function IoQueueWorkItem to request the system's auxiliary threads to obtain their services. These two functions place a work item in a queue, and the system auxiliary thread extracts the work item from the queue and executes a specified routine in the work item. Therefore, the routines in the work project are executed in the System process environment. The system auxiliary thread is actually a thread pool. During Windows system initialization, a certain number of auxiliary threads are created. As the load of the auxiliary threads changes, the execution body also dynamically creates some auxiliary threads. Several important System processes: System Idle processes (Idle), PID is 0, each processor or check should be a thread-System process, PID is 4, contains the Kernel Mode System thread. The System auxiliary thread and the thread created by the execution body and driver through PsCreateSystemThread are all in the System process. Session manager (smss.exe) is the first user-mode process created in Windows. In the Windows Startup Process, the environment changes are created, and the sub-system processes csrss.exeand winlogon.exe are started. · Progress (winlogon.exe ). Processes logon and logout of interactive users. · Windows sub-system (csrss.exe ). · Login security token subsystem (lsass.exe ). Responsible for the implementation of the system security policy shell(assumer.exe ). Windows Kernel shell(graphic interface shell, for example, the menu bar of a menu, the resource manager window, etc. .. Service Control Manager (services.exe ). Manage System Services