link#

Summary#

System calls fundamentally connect user-space programs to the operating system kernel in both Linux and Windows, allowing programs to request privileged services like file access or process creation. However, their implementation and public exposure differ significantly between the two systems.
기본적으로 사용자 공간 프로그램을 리눅스와 윈도우의 운영 체제 커널에 연결하여 프로그램이 파일 접근이나 프로세스 생성과 같은 권한 있는 서비스를 요청할 수 있도록 합니다. 그러나 두 시스템 간에 구현 방식과 공개 노출은 크게 다릅니다.
- System Call시스템 콜은 유저 프로그램이 커널 모드에서만 가능한 기능을 안전하게 사용할 수 있도록 도와주는 인터페이스이다.
  - 나무wiki설명
    - https://namu.wiki/w/%EC%8B%9C%EC%8A%A4%ED%85%9C%20%EC%BD%9C

https://ko.wikipedia.org/wiki/%EC%8B%9C%EC%8A%A4%ED%85%9C_%ED%98%B8%EC%B6%9C
영문 https://en.wikipedia.org/wiki/System_call
시스템 호출이란 프로그래밍 언어에서 지원하지 않는 기능에 대하여 운영 체제의 루틴을 호출하여 이용하는 것을 말한다. 시스템 호출의 세 가지 기능은 다음과 같다.
- 사용자 모드에 있는 응용 프로그램이 커널의 기능을 사용할 수 있도록 한다.
- 시스템 호출을 하면 사용자 모드에서 커널 모드로 바뀐다.
- 커널에서 시스템 호출을 처리하면 커널 모드에서 사용자 모드로 돌아가 작업을 계속한다.
시스템 호출의 유형
- 프로세스 제어(process control)
- 파일 조작(file manipulation)
- 장치 관리(device management)
- 정보 유지(information maintenance)
- 통신(communication)

Feature	Linux	Windows
Primary Interface	Direct system calls via `libc`	Windows API (Win32, etc.) in DLLs
System Call Names	Well-documented and stable (e.g., `read`, `write`, `open`)	Undocumented, private, and unstable (e.g., `NtCreateFile`, `ZwAllocateVirtualMemory`)
Stability	System call numbers are relatively stable	System call numbers change between OS versions/builds
Invocation	Direct use of assembly instructions (`syscall`, `int 0x80`) by standard libraries	Indirect via library calls which then execute the low-level syscall instruction

The following illustrates various equivalent system calls for Windows and UNIX operating systems.

	Windows	Unix, Linux and MacOS
Process control	`CreateProcess()` `ExitProcess()` `WaitForSingleObject()`	`fork()` `exit()` `wait()`
File management	`CreateFile()` `ReadFile()` `WriteFile()` `CloseHandle()`	`open()` `read()` `write()` `close()`
Device management	`SetConsoleMode()` `ReadConsole()` `WriteConsole()`	`ioctl()` `read()` `write()`
Information maintenance	`GetCurrentProcessID()` `SetTimer()` `Sleep()`	`getpid()` `alarm()` `slepp()`
Communications	`CreatePipe()` `CreateFileMapping()` `MapViewOfFile()`	`pipe()` `shm_open()` `mmap()`
Protection	`SetFileSecurity()` `InitlializeSecurityDescriptor()` `SetSecurityDescriptorGroup()`	`chmod()` `umask()` `chown()`

Source : Silberschatz, A., Galvin, P. B., & Gagne, G. (2018). Operating system concepts. Willey
- System libraries in Linux vs. Windows

Direct Interface: Linux provides a consistent, well-documented, and stable set of system calls across different distributions and versions. Developers can use the C standard library (libc) to make these calls, which translates functions like open(), read(), and write() into the appropriate underlying system calls.
Invocation: System calls are typically invoked using an assembly instruction like syscall (on x86-64 systems) or a software interrupt, which switches the CPU from user mode to a more privileged kernel mode.
Stability: The system call numbers (SSNs) are relatively stable, allowing applications to rely on a consistent interface.
Examples: Common Linux system calls include fork() and exec() for process creation, and exit() for termination.
Tools: Tools like strace allow users to monitor the sequence of system calls made by a program for debugging and analysis.

Indirect Interface: Windows abstracts its low-level system calls behind a higher-level set of functions known as the Windows API (Win32 API). These APIs reside in Dynamic Link Libraries (DLLs) like kernel32.dll and ntdll.dll.
API Wrappers: User-space programs call these documented API functions as normal library functions. The DLLs, in turn, contain the actual, private system call stubs (prefixed with Nt or Zw, e.g., NtCreateFile) that handle the user-to-kernel mode transition.
Instability: The underlying system call numbers are not stable and can change between different Windows builds and versions. This instability is why direct system calls are discouraged for general developers, as it would break application compatibility with future OS updates.
Compatibility: This API-based approach allows Microsoft to maintain long-term compatibility for applications, as they only need to ensure the high-level API remains consistent, while the underlying kernel implementation can change.