Editing System call (section)

== The library as an intermediary ==
Generally, systems provide a [[Library (computing)|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 standard library|C library]] (libc), such as [[glibc]], that provides [[wrapper function]]s 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 {{mono|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 language|assembly]] level) for using the system call, as well as making the system call more [[modularity|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 register]]s (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 [[Software portability|portability]].

The call to the library function itself does not cause a switch to [[kernel mode]] and is usually a normal [[subroutine call]] (using, for example, a "CALL" assembly instruction in some [[Instruction set architecture]]s (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, <code>fork</code> and <code>execve</code> are C library functions that in turn execute instructions that invoke the <code>fork</code> and <code>exec</code> 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 (programming language)|C]] and [[C++]]), as well as requiring 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.

On [[exokernel]] based systems, the library is especially important as an intermediary. On exokernels, libraries shield user applications from the very low level kernel [[Application programming interface|API]], and provide [[Abstraction (computer science)|abstractions]] and [[Resource (computer science)|resource]] management.

IBM's [[OS/360 and successors|OS/360]], [[DOS/360 and successors|DOS/360]] and [[TSS/360]] implement most system calls through a library of assembly language [[Macro (computer science)|macros]],{{efn|In many but not all cases, IBM documented, e.g., the SVC number, the parameter registers.}} although there are a few services with a call linkage. This reflects their origin at a time when programming in assembly language was more common than [[High-level programming language|high-level language]] usage.  IBM system calls were therefore not directly executable by high-level language programs, but required a callable assembly language wrapper subroutine. Since then, IBM has added many services that can be called from high level languages in, e.g., [[z/OS]] and [[VSE (operating system)|z/VSE]]. In more recent release of [[MVS/SP]] and in all later MVS versions, some system call macros generate Program Call (PC).