OSDev.org

Hi all,

I was wondering how windows system calls work.

Say if I make a windows application, and make a system call through the Windows API such as OpenProcess(...). Would the OpenProcess API function just make a system call, e.g. through an interrupt, or how does it work?

As on Linux, system calls in Windows are implemented via an interrupt routine (32-bit) or the syscall instruction (64-bit). Unlike Linux, you should never, never make a direct call to a Windows system call. The numbers change with different versions of the OS, so it would be a nightmare trying to ensure the correct call. Use the .dlls; that's what they are there for.

System calls are exported from ntdll.dll. These are autogenerated stubs that place a function number in EAX followed by an int 2eh or sysenter instruction. The system looks up the correct number of parameters in a table and copies them to the system stack before executing the requested function.

See Windows Internals page 132 and further.

Thanks for the helpful replies.

So if I understand correctly, all the windows API functions that are included via header files such as <Windows.h> are just stubs that generate an interrupt or syscall, then the kernel does the functions work?

Dude, what? No, that's not true. The Windows API is a layer implemented in various DLLs that is built upon the actual (undocumented) real kernel API. Don't underestimate the amount of stuff that happens between a call to the Windows API and the kernel, if the kernel is even called at all. But yes, programs do communicate with the kernel through system calls, but a lot of stuff is between you and the raw system calls.

Contrast this with Unix systems where most libc system call functions are but a thin layer upon the a system call with the same semantics, unless you hit a compatibility layer in the C library that emulates such system calls on kernel that doesn't have them.

BMW wrote:Thanks for the helpful replies.

So if I understand correctly, all the windows API functions that are included via header files such as <Windows.h> are just stubs that generate an interrupt or syscall, then the kernel does the functions work?

Yes. Bear in mind some calls are executed competely or partially inside the dll as they don't need to perform a system call, if execution inside the kernel isn't actually required.

Also note that you should not use these system call interfaces directly. the DLL's for each version of Windows may use a different syscall interface with differing arguments and vectors. So while most of them probably stay the same across a few versions, your code may break if its ever changed. The only reason for accessing them directly would be perhaps to write teeny tiny programs for competitions or fun where standards compliance is not a factor.

Linux works in a similar way. They support the POSIX standard however (Strictly speaking it's actually a superset of it, that does have quirks) so a lot of the vectors and arguments are standardized and kept the same. So if you wanted to write small binaries for a particular architecture on linux you could micro-optimize the overhead of calling the stub code away (The compiler mostly does this anyway, but you could remove redundant error checking you've already done yourself .etc) inside hot loops with a lesser impact on the portability of your program.