1. PROGRAM EXECUTION load a program into memory, run it, and handle its termination — normal or abnormal. On UNIX this is fork() + exec() + wait(). 2. I/O OPERATIONS a program must not need to know how a disk or a network card works. The OS provides uniform read/write on file descriptors, and drivers translate. 3. FILE-SYSTEM MANIPULATION create, delete, read, write, search files and directories; manage permissions. 4. COMMUNICATION between processes on one machine (shared memory, pipes, message queues) or across machines (sockets). 5. ERROR DETECTION AND HANDLING hardware errors (memory parity, disk failure), I/O errors, and program errors (divide by zero, invalid memory access). The OS must respond without taking the system down — normally by terminating just the offending process. 6. USER INTERFACE a shell, a window system, or a touch interface. SERVICES FOR THE SYSTEM'S BENEFIT (the user does not ask for these; the OS needs them to function) 7. RESOURCE ALLOCATION CPU cycles, memory, file handles, I/O devices — divided among competing processes. Every allocation is also a policy decision about fairness. 8. ACCOUNTING / LOGGING which user consumed what. Historically for billing, now for capacity planning, debugging and cloud metering. 9. PROTECTION AND SECURITY protection = controlling access BETWEEN processes and users (permissions, isolation) security = defending the system from the OUTSIDE (authentication, encryption, firewalls) The distinction is examined: protection is internal mechanism, security is the external threat model.

/* Verified on Darwin 25.5.0 arm64.

   THE UNIX MODEL, and it surprises people: creating a process
   and running a program are TWO SEPARATE operations.
     fork()  duplicates the calling process
     exec()  REPLACES the current program image
   A shell running `ls` does fork(), then exec("ls") in the
   child, then wait() in the parent. */
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <sys/wait.h>

int main(void) {
    int x = 42;
    printf("  before fork: pid=%d x=%d\n", getpid(), x);
    fflush(stdout);   /* flush BEFORE fork, or the child
                         inherits a copy of the buffer and the
                         text prints twice */

    pid_t pid = fork();          /* ← ONE call, TWO returns */
    if (pid == 0) {
        /* CHILD: a separate copy of everything */
        x += 100;
        printf("  CHILD  pid=%d ppid=%d x=%d\n",
               getpid(), getppid(), x);
        fflush(stdout);   /* _exit skips stdio cleanup */
        _exit(7);
    }
    int status;
    waitpid(pid, &status, 0);     /* reap the child */
    printf("  PARENT pid=%d x=%d  (child exited %d)\n",
           getpid(), x, WEXITSTATUS(status));
    return 0;
}
MEASURED OUTPUT:
  before fork: pid=74967 x=42
  CHILD  pid=74968 ppid=74967 x=142
  PARENT pid=74967 x=42  (child exited 7)

READ THE OUTPUT CAREFULLY — it proves the central fact: child x = 142 (it added 100) parent x = 42 (UNCHANGED) The child got a COPY of the parent's memory, not a shared view. Two processes, two address spaces, two values of x. That is the defining difference from threads, and it is why processes need explicit IPC to communicate. FORK'S RETURN VALUE — the idiom to memorise: > 0 you are the PARENT; the value is the child's pid = 0 you are the CHILD < 0 fork FAILED (no memory, process limit reached) Checking for < 0 is not optional; fork can and does fail. THE fflush LESSON is a real bug, not pedantry. fork() copies the process's stdio BUFFER along with everything else, so any text still sitting unflushed is duplicated — the parent prints it and so does the child. VERIFIED on this machine, with the first fflush REMOVED: $ ./nofl # output to a terminal before fork: pid=75054 x=42 CHILD x=142 before fork: pid=75054 x=42 <- PRINTED TWICE PARENT x=42 $ ./nofl | cat # output to a pipe before fork: pid=75056 x=42 CHILD x=142 before fork: pid=75056 x=42 <- same duplication PARENT x=42 Note it duplicates in BOTH cases here. Textbooks usually say this only bites when output is redirected to a pipe, reasoning that a terminal is line-buffered and would already have flushed at the newline. On this platform the duplicate appears either way, so the safe rule is unconditional: ALWAYS fflush(stdout) before fork(). The general principle matters more than the platform detail: fork() duplicates userspace state you may have forgotten about, and stdio buffers are the most common example. THE ZOMBIE AND ORPHAN CASES, both examinable: ZOMBIE the child has exited but the parent has not called wait(). The exit status must be kept, so a process table entry remains. Visible as state Z in ps. A parent that never reaps leaks table entries. ORPHAN the parent exited first. The child is re-parented to init/launchd (pid 1), which reaps it automatically. Orphans are harmless; zombies accumulate. exec() FAMILY — replaces the image, so it does NOT return on success: execl, execlp, execle, execv, execvp, execve The letters mean: l = list of args, v = vector of args, p = search PATH, e = pass a new environment. If exec returns at all, it failed.

SYSTEM PROGRAMS are ordinary user-mode programs shipped with the OS. They are NOT the kernel. file management ls, cp, mv, rm, mkdir status information ps, top, df, uptime, date file modification editors (vi, nano) language support compilers, assemblers, linkers program loading ld, dynamic loader communication ssh, curl, mail background services daemons: sshd, cron, syslogd Every one of these runs in USER MODE and works by issuing system calls. `ls` is a loop over opendir/readdir/stat. WHY THIS DISTINCTION IS EXAMINED: students often answer that "the OS includes the compiler and the shell". Precisely: · the KERNEL is the privileged core · the OPERATING SYSTEM as a shipped product includes system programs · the shell and compiler are system programs, not kernel components Linux the kernel vs "a Linux distribution" is exactly this distinction — Debian and Fedora ship the same kernel with different system programs. THE THREE INTERFACES TO OS SERVICES: 1. COMMAND-LINE (shell) scriptable, composable 2. GRAPHICAL (GUI) discoverable, hard to automate 3. SYSTEM CALL / API what programs use The API is the real interface; the other two are programs that use it. MEASURED ON THIS MACHINE: ps ax | wc -l → 599 Of those 599 processes, exactly ONE is the kernel; the rest are system programs, daemons and applications — all of them making system calls to get anything done.