In-depth understanding of Windows operating system mechanism (2)

I am Liyuan Breeze. As a veteran in the IT industry for 25 years, today we will re-examine Windows, a system we are familiar with and can no longer be familiar with.

We use the Windows operating system every day, but what we deal with directly every day is not the kernel of the Windows operating system, but the human-computer interaction interface of the Windows operating system. This interface is actually just a component of the Windows operating system. , the interface we use when using the Linux system is just a program on the Linux system. So, we are not exposed to the kernel of these systems. Over time, we will gradually mistake the intuitive things displayed in the interface for the Windows operating system itself, which is actually wrong.

Let's re-examine the Windows operating system and look at the typical features and main functions of the Windows operating system itself. From the functions of the Windows operating system, we can know that the services provided by the Windows operating system are as follows: an environment for executing programs is provided, and the services provided include program execution, I/O operations, file operations, resource allocation and protection, and error detection and exclusion etc.

The Windows operating system borrows the concept of multiprogramming. The so-called multiprogramming technology refers to storing two or more jobs in memory at the same time. These jobs are running at the same time, and they are under the control of the management program. Run interspersed. These jobs share processors, peripherals, and other resources.

The interrupt handler of the Windows operating system can only be an operating system program, not an application program. Interrupt processing is an action in the system that will have a significant impact on the system, so only kernel mode programs are allowed to execute. The application program usually refers to the user program, which runs in the user state and cannot perform these operations.

The system calls of the Windows operating system can be divided into 6 categories according to their functions, including process management, file operation, device management, main memory management, process communication and information maintenance.

If a Windows program is trying to read the 100th logical block of a certain disk, use a system call provided by the Windows operating system. The interfaces required in this article belong to the calls related to file operations.

Under multi-programming, processes run at the same time on a macro level, but on a micro level, a single processor can only handle one process at a time, so processes cannot be executed in parallel. Processors, channels, and devices can be executed in parallel, such as printing (device), computing (processor), and data transmission (channel controls data exchange between memory and external memory) at the same time. Here we should pay attention to the difference between concurrency and parallelism. Parallelism means that two or more events occur at the same time, while concurrency means that two or more events occur within the same time interval. Although only one process can be processed at a time, multiple processes can execute concurrently.

In fact, among the concepts of system calls, interrupts, library functions, and primitives in the Windows operating system, only system calls are the interfaces provided by the operating system. A system call is a subroutine that can complete a specific function. When the application program requires the operating system to provide a certain service, it calls the system call with the corresponding function.

Library functions are functions corresponding to system calls provided in high-level languages ​​(some library functions have nothing to do with system calls). The purpose is to hide the details of instructions and make system calls more convenient and abstract. But it should be noted that library functions belong to user programs rather than system calls, and are the upper layer of system calls; interrupts and primitives are the basic functions of the bottom layer of the computer system, and belong to the lower layer of system calls.

The system provides encapsulated system calls for application programs to use. The application program does not need to consider the content of the bottom layer of the system, but only considers the operation of the upper layer; interrupt is the internal mechanism of the system for event response, which is transparent to the application program and will not Provided to the application program for direct use; similarly, the library functions and primitives are all facing the bottom layer of the operating system and will not be directly provided to the application program.  

Both page fault processing and clock interrupt are interrupts, which will affect the system, so they can only be executed in the core state. Process scheduling is part of the system and can only be executed in the core state. The command interpreter belongs to the command interface, which is the interface provided by the operating system to the user, so it can be executed in the user mode.

The CPU state is divided into core state and user state. The core state is also called privileged state, system state or management state. Usually, the operating system runs in the management mode, and the CPU can execute the complete set of the instruction system in the management mode. The user state is also called the normal state or the target state. When the machine is in the user state, the program can only execute non-privileged instructions, and the user program can only run in the user state. The CPU divides instructions into privileged instructions and non-privileged instructions. For those dangerous instructions, only the operating system and its related modules are allowed to use them, and ordinary applications cannot use them.
  

The common privileged instructions of the Windows operating system are as follows:

(1) Instructions related to the use of I/O devices, such as instructions to start I/O devices, test the working status of I/O devices, and control the actions of I/O devices.

(2) Instructions related to accessing the program state, such as instructions on the program status word (PSW), etc.

(3) Access special register instructions, such as access interrupt registers, clock registers and other instructions.

(4) Other privileged instructions.

In this article, the page fault handler and the clock interrupt handler all need to modify the interrupt register, and the process scheduler needs to modify the program status word.

Among the system calls, external interrupts, process switching, and page faults of the Windows operating system, process switching is generally impossible to occur in user mode. The key to judging whether it can be executed in user mode is whether the event will execute privileged instructions.

First look at the system call. The system call is provided by the system to the user program to call the kernel function. When the user program executes the system call, it will switch the CPU state from the user state to the core state and execute the kernel function. After the execution, the control will be returned to The user program, and the CPU state switches from the kernel state to the user state. It can be seen from this process that although the CPU needs to switch to the core state during the execution of the system call, the system call (or reference, call) occurs in the user state, which is specially designed for the user state by the system, so the system call can be Occurs in user mode.

For external interrupts, when you hear "interruption", it is easy to think that all interrupts should be things in the core state, and cannot be executed in the user state. This understanding is wrong! Interrupts often occur in the system, such as keyboard input will cause external interrupts (external interrupts refer to interrupts caused by external events, such as interruptions caused by operations such as clicking the mouse and keyboard input), process page faults will generate page fault interrupts, etc. These often occur in user processes, and naturally these are also user-mode events. Taking keyboard input as an example, a user process requires the user to input a series of commands. When the user uses the keyboard to input, an external interrupt will be triggered (the CPU is still in the user state at this time), and the system will switch to the core state to execute the interrupt handler (then the CPU After processing, the processing program returns the input result to the user program and switches the CPU state to the user state, and the interrupt processing ends. It can be seen from this process that the occurrence and processing of interrupts are similar to system calls, and they all occur in user mode, and the corresponding functions are completed by switching to the core mode, and then return to user mode. The occurrence of system calls and interrupts is in the user state, and the processing is in the kernel state.

Let’s look at page faults again. Similar to external interrupts, a page fault interrupt will be generated when the user mode executes a process page fault (the interrupt occurs in the user mode), and then the system transfers to the core state to process the page fault interrupt, and then returns to the user mode, and the control right Handed back to the user process. Therefore, page faults can also occur in user mode.

Then why can't process switching happen in user mode. Process switching is actually a modification of the program state, so to modify the program status word, this is a privileged instruction and must be executed in the core state.

Do you understand what I said above?

Let's look at an example calculation. There are only two jobs P1 and P2 in a multi-channel batch processing system, and P2 arrives 5ms later than P1. The order of their computation and I/O operations is as follows:

P1: calculation 60ms, I/O 80ms, calculation 20ms. P2: calculation 120ms, I/O 40ms, calculation 40ms.

If scheduling and switching time are not considered, what is the minimum time required to complete the two jobs? Let's draw a picture:

 After drawing such a picture, we know that the time required to complete the two jobs is at least 260ms.

The occurrence of Windows operating system interruption is usually sudden, such as address out of bounds, etc., which is often unpredictable by the system (interruption of external input is also unpredictable, and the computer will not know when the user uses the keyboard to input). When the system is interrupted, it should be transferred to the interrupt handler. After processing, it should return to the instruction where the interrupt occurred to continue execution. Because the CPU may switch states when processing the interrupt (if an interrupt occurs in the core state, it will always be in the core state, not Need to switch), so when the interrupt processing returns, it is necessary to restore the current program state, including processor information, etc., which uses the contents stored in the program status word register. The program status word register is used to record the status of the current processor and the execution sequence of control instructions, and to retain and indicate various information related to the running program. Its main function is to realize the protection and recovery of the program status, so it must be Push the PSW onto the stack and save it. The subroutine call is predictable by the system, and the subroutine call is usually executed inside the process and will not change the program state. Even if the program state is changed, it only needs to update the register without saving, because everything is expected by the system. There is no need to protect and restore, so the subroutine call mainly saves local parameter information, etc., and does not need to push the program status word onto the stack.

Therefore, Windows operating system interrupt processing and subroutine calls need to push the stack to protect the scene. It is the program status word register that the interrupt processing must save and the subroutine call does not need to save its content. Interrupt handling and subroutine calling have the same operations on the program counter, general data registers, and general address registers.

When the user usually turns on the computer, the BIOS program stored in the ROM on the motherboard is first started (it is solidified on the ROM chip of the motherboard, and stores the most basic input/output programs of the computer, the self-test program after booting and the system self-starting program. Its main function is to provide the computer with the lowest and most direct hardware setting and control), and then it calls the Windows system in the hard disk, and automatically loads the operating system program into the system area in the memory. This area is RAM.

When a task (process) of the Windows operating system executes a system call and falls into the execution of the kernel code, we call the process in the kernel running state (kernel state). At this point, the processor is executing in the kernel code with the highest privilege level (level 0). When the process is in kernel mode, the executed kernel code will use the kernel stack of the current process. Each process has its own kernel stack. When the process is executing the user's own code, it is said to be in the user running state (user state), that is, the processor is running in the user code with the lowest privilege level (level 3). When the user program is being executed and suddenly interrupted by the interrupt program, the user program can also be symbolically called in the kernel state of the process at this time, because the interrupt handler will use the kernel stack of the current process. This is somewhat similar to the state of a process in kernel mode:

(1) Enter the core state when using the system call. Linux can only operate the hardware in the core state, which can be controlled by writing a driver. Operating hardware in user mode will cause core dump.

(2) Pay attention to the distinction between system calls and general functions. System calls are provided by the kernel, such as read(), write(), open(), etc. The general functions are provided by the function library in the software package, such as sin(), cos() and so on. There is no difference in syntax between the two.

(3) Under normal circumstances, the system call runs in the core state, and the function runs in the user state. However, there are also some functions that use system calls (such as fopen()) internally. Such functions enter the kernel state when the system call is called, and run in the user state at other times.

After the above description, let's look at some specific situations:

For example, dividing an integer by zero will cause an interrupt and enter the kernel state. For example, the sin() function call is provided by the function library in the software package and can be executed in user mode. For example, a system call must enter the kernel state.

The trap instruction, jump instruction and stack push instruction can all be executed in the user mode, and the trap instruction is responsible for converting from the user mode to the kernel mode. The interrupt-off command is a privileged command and must be executed in the core state. During external interrupt processing, the content of the program counter is automatically saved by the interrupt implicit instruction, and the content of the general register is saved by the operating system.

Assuming that the following instructions of the Windows operating system have been loaded into the instruction register, which ones will not cause the CPU to change from the user state to the kernel state when executed?

The first command DIV R0,R1;(R0)/(R1)->R0

The second command INT n; generates a soft interrupt

The third command NOT R0; the content of register R0 is negated

The fourth command MOV R0,addr; Put the memory data at address addr into register R0

In the first command, if the content in R1 is 0, an internal interrupt will occur, changing from user mode to kernel mode; the second command soft interrupt is executed in kernel mode; the third command register negation will not generate an interrupt, And it does not belong to other operating system kernels, so it will not change to the kernel state; the fourth addr is the address of the main memory, and memory access needs to enter the kernel state.

In the batch processing system, the jobs are sequentially input to the tape in an offline input mode, and the supervisory program executes the jobs on the tape in sequence, and the user cannot intervene in its operation when the job is executed. Batch processing system can be divided into single-channel batch processing system and multi-channel batch processing system according to the development history, the main difference is that there are single or multiple jobs in the memory at the same time. When a program in a multi-channel batch processing system is suspended due to an I/O request, the CPU turns to run another program with the help of interrupt technology.

The process of performing system calls by the Windows operating system includes some main operations, and their correct order of execution is:

Pass the system call parameters --> Execute into the trap instruction --> Execute the corresponding service program --> Return to the user state

When the Windows operating system executes a system call, it first passes the parameters required by the system call to the system kernel, then enters the kernel state by trapping instructions, pushes the return address into the stack for use, and then the CPU executes the corresponding kernel state service program , and finally return to user mode.

About the author: Li Yuan Weifeng, born in 1981, senior engineer, master of engineering from Zhejiang University, software engineering project supervisor, has worked as a programmer, software designer, system architect, early Windows programmer, loyal Visual Studio user, C/C++ user The author is a veteran who has studied, worked hard, and struggled in the computer industry for 25 years. He has experienced the UNIX era, the desktop WIN32 era, the Web application era, the cloud computing era, the mobile phone Android era, the big data era, the ICT era, and AI deep learning Era, the age of intelligent machines, I don't know what era there will be in the future, I just remember that this journey is full of hardships and gains, and I am willing to go on with you, full of hope.

Guess you like

Origin blog.csdn.net/wang2015cn/article/details/131738985