Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>In order to answer this question, it's important to understand the difference between user and kernel mode. Kernel mode is the most privileged CPU mode, where executing code has complete access to the hardware. It is used for the most low-level operating system functionality. User mode is a much more restricted CPU mode. It prevents code from directly accessing the hardware. Applications run in user mode. Of course, they still need to access the hardware somehow, so they need to call into the kernel.</p> <p>That's where your question leads to. In order to allow user mode code to call into the kernel, the Windows kernel sets up an entry point. On x86-based systems, this entry point is either a software interrupt (int 2e) or the sysenter/syscall instruction. Executing these instructions causes a CPU mode switch, transitioning the CPU from user mode into kernel mode. Once the CPU has switched modes, it calls a function specified by the kernel. In Windows, this function is the system service dispatcher.</p> <p>The system service dispatcher is responsible for calling the kernel service that the user mode code wants. It takes the function number, which was specified by the user mode code, and looks it up in the system service descriptor table (SSDT). The SSDT is basically a list of function pointers to each kernel services. Once it identifies the correct kernel service, it calls it with the arguments that the user mode application also specified. After the kernel service completes, the CPU returns to the application, either through the iret instruction (if coming from a software interrupt) or sysexit/sysret (if coming from sysenter/syscall).</p> <p>All of this sounds quite complex, and it is, which is why Windows hides these details from programmers. Instead of requiring them to directly communicate with the kernel through the entry point the kernel sets up, Windows provides programmers with several DLLs, which do this for them.</p> <p>Now here's where it once again gets somewhat more complicated. The process of calling kernel services from user mode is implemented in ntdll.dll, but ntdll.dll isn't directly used by most programmers. Instead, it exports a generic set of kernel services called the Native API. Above this, the Win32 API is implemented in kernel32.dll. Most functions in kernel32.dll are simply wrappers of functions in ntdll.dll.</p> <p>You might ask why this is done. Why not just have kernel32.dll call the kernel functions directly? The reason for this is to allow for different multiple user mode APIs. Windows NT was designed to support multiple APIs, not just Win32, but also POSIX and OS/2. Each user mode API calls into ntdll.dll to implement their own APIs, preventing them from needing to directly call kernel services themselves.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload