19

I just want to ask, I know that standart system calls in Linux are done by int instruction pointing into Interrupt Vector Table. I assume this is similiar on Windows. But, how do you call some higher-level specific system routines? Such as how do you tell Windows to create a window? I know this is handled by the code in the dll, but what actually happend at assembler-instruction level? Does the routine in dll calls software interrupt by int instruction, or is there any different approach to handle this? Thanks.

B.Gen.Jack.O.Neill
  • 8,169
  • 12
  • 51
  • 79

2 Answers2

8

Making a Win32 call to create a window is not really related to an interrupt. The client application is already linked with the .dll that provides the call which exposes the address for the linker to use. Since you are asking about the difference in calling mechanism, I'm limiting the discussion here to those Win32 calls that are available to any application as opposed to kernel-level calls or device drivers. At an assembly language level, it would be the same as any other function call since most Win32 calls are user-level calls which internally make the needed kernel calls. The linker provides the address of the Win32 function as the target for some sort of branching instruction, the specifics would depend on the compiler.

[Edit] It looks like you are right about the interrupts and the int. vector table. CodeGuru has a good article with the OS details on how NT kernel calls work. Link:
http://www.codeguru.com/cpp/w-p/system/devicedriverdevelopment/article.php/c8035

Kelly S. French
  • 12,198
  • 10
  • 63
  • 93
  • 2
    Yes, I know that dll has the needed calls inside, I wrote that. But basicly everything I ask for is: Has the dll routine for drawing a windows syscalls in form of software interrupts, or, if not, how does it tell windows kernel to make a window? Becouse as far as I know you cannot switch from the space your program is running another way than int instruction becouse of ringl evel limitaion. – B.Gen.Jack.O.Neill May 03 '10 at 17:01
  • b-gen-jack-o-neill: AFAIK the kernel is not responsible for window managment. – Billy ONeal May 03 '10 at 17:13
  • 6
    On newer processors, the sysenter/sysexit instructions are used instead of issuing a software interrupt with the INT instruction. The concept is the same, it's a way to switch to kernel mode. A window is not managed in the kernel though, you won't find a CreateWindow system call, instead it's built on top of numerous other system calls, including communicating with other processes - such as a window manager – nos May 03 '10 at 17:44
  • 2
    Wow, finally I am closing to desired answer. So, I thought that every action that you want OS to perform is represented in one or more kernel calls. So, based of what you wrote, there is a window manager process that runs in kernel mode, which you communicate with using .dll library that hous routines that establish interprocess communication with windows manager thru kernel calls? Maybe, can you recommend me some good article about this? Thank you. – B.Gen.Jack.O.Neill May 04 '10 at 14:04
  • Well the window manager is another userspace process and for GUI stuff the kernel only intervenes in the actual communication with that process, and also in the way that process actually does the displaying itself. – Paul Stelian Apr 29 '19 at 18:46
  • Found this after googling for a similar question. The link doesn't work anymore, use this one instead https://www.codeguru.com/windows/how-do-windows-nt-system-calls-really-work/ – Nick Collier Sep 19 '22 at 22:35
7

Windows doesn't let you call system calls directly because system call numbers can change between builds, if a new system call gets added the others can shift forward or if a system call gets removed others can shift backwards. So to maintain backwards compatability you call the win32 or native functions in DLLs.

Now there are 2 groups of system calls, those serviced by the kernel (ntoskrnl) and by the win32 kernel layer (win32k).

Kernel system call stubs are easily accessible from ntdll.dll, while win32k ones are not exported, they're private within user32.dll. Those stubs contain the system call number and the actual system call instruction which does the job.

So if you wanted to create a window, you'd call CreateWindow in user32.dll, then the extended version CreateWindowEx gets called for backwards compatability, that calls the private system call stub NtUserCreateWindowEx, which invokes code within the win32k window manager.

Ugne
  • 71
  • 1
  • 2