<P> The architecture of most modern processors, with the exception of some embedded systems, involves a security model . For example, the rings model specifies multiple privilege levels under which software may be executed: a program is usually limited to its own address space so that it cannot access or modify other running programs or the operating system itself, and is usually prevented from directly manipulating hardware devices (e.g. the frame buffer or network devices). </P> <P> However, many normal applications obviously need access to these components, so system calls are made available by the operating system to provide well - defined, safe implementations for such operations . The operating system executes at the highest level of privilege, and allows applications to request services via system calls, which are often initiated via interrupts . An interrupt automatically puts the CPU into some elevated privilege level, and then passes control to the kernel, which determines whether the calling program should be granted the requested service . If the service is granted, the kernel executes a specific set of instructions over which the calling program has no direct control, returns the privilege level to that of the calling program, and then returns control to the calling program . </P> <P> Generally, systems provide a library or API that sits between normal programs and the operating system . On Unix - like systems, that API is usually part of an implementation of the C library (libc), such as glibc, that provides wrapper functions for the system calls, often named the same as the system calls they invoke . On Windows NT, that API is part of the Native API, in the ntdll. dll library; this is an undocumented API used by implementations of the regular Windows API and directly used by some system programs on Windows . The library's wrapper functions expose an ordinary function calling convention (a subroutine call on the assembly level) for using the system call, as well as making the system call more modular . Here, the primary function of the wrapper is to place all the arguments to be passed to the system call in the appropriate processor registers (and maybe on the call stack as well), and also setting a unique system call number for the kernel to call . In this way the library, which exists between the OS and the application, increases portability . </P> <P> The call to the library function itself does not cause a switch to kernel mode (if the execution was not already in kernel mode) and is usually a normal subroutine call (using, for example, a "CALL" assembly instruction in some Instruction set architectures (ISAs)). The actual system call does transfer control to the kernel (and is more implementation - dependent and platform - dependent than the library call abstracting it). For example, in Unix - like systems, fork and execve are C library functions that in turn execute instructions that invoke the fork and exec system calls . Making the system call directly in the application code is more complicated and may require embedded assembly code to be used (in C and C++) as well as knowledge of the low - level binary interface for the system call operation, which may be subject to change over time and thus not be part of the application binary interface; the library functions are meant to abstract this away . </P>

What system call creates a process on windows systems