(Notes from "Operating Systems: Design and Implementation," by Andrew S. Tanenbaum and Albert S. Woodhull, and “Advanced Programming in the UNIX Environment,” by W. Richard Stevens and Stephen A Rago).
An application is made up from a single process, or multiple processes, on an operating system. But a process can’t directly manipulate the underlying hardware of a computer system. It must go through a set of system calls, which execute privileged operations in the kernel on behalf of the process.
When the system call comes in, the kernel validates the request, and then executes the task on behalf of the user (“kernel mode”). After the task is completed, it then returns control back to the process, which lives in user mode.
Each process has an address space, a dedicated portion of the system’s memory where the program gets full read and write access. Into this memory space, the computer puts the program code, its data and the “stack,” a collection of local variables, function arguments, return addresses, and stack frames for active function calls.
Every resource request a process makes to an OS is done through a system call. Here is the whole lifecycle:
A running process creates a new process by calling fork(), which instructs the kernel to duplicate the parent process's memory address space and kernel attributes. This is to run a duplicate of the parent process. To tell them apart, the parent gets a return value of the child’s process ID and the child gets a return value of 0. Use getpid() to find out what the process ID is.
To run a different executable, fork() is called and the resulting child process is loaded with a separate executable core of data and code using the execve() family of system calls. Changing the size of the data segment can be done with brk(address) or sbrk().
A process terminates itself by invoking exit() or _exit() directing the kernel to release memory and the “file descriptors” that point to any file or I/O resource opened by the process.
Whenever the child process changes state, the kernel sends a "SIGCHLD" signal to the parent. The parent process can retrieve details of the exact change (such as the child exiting) by issuing either the wait() system call (which puts the parent asleep until the child exits) or the waitpid() system call. If the child process has terminated, either call tells the kernel to remove the now-zombied process from the process table, the final step in erasing the process from the system.
In short: The fundamental UNIX process execution flow is that the parent invokes fork(), after which the child runs and optionally calls exec() until it hits exit(), while the parent eventually calls wait() or waitpid() to collect its termination status.
(Feature art: Ed Garman's "No. 265," North Carolina Museum of Art).