Part of the OSTEP notes
Virtualizing the CPU means more than one thing can run on it. We need some notion of “a thing which can run on the CPU for a little while”. And we want a process scheduler, which can allow each process to have its turn on the CPU.
You need some operating system-level API to spawn and delete processes, check the current status (running? stopped? waiting on something?), maybe ask to pause or resume it or change its importance.
Programs exist as files on the hard drive. The CPU runs instructions from memory. The hard drive is not memory.
So of course, starting a program requires copying its code from the hard drive and dumping it somewhere in memory. Programs also require data
There’s lots of subtopics to drill into. An example: it would be silly if a program that required 20mb of scratch memory needed 20mb of blank space in the file. So there are ways to tell the loader “allocate X amount of memory for me and fill it with zeroes” without literally including a template for that memory in the file.
forkLinux has a very silly way to make processes. If you call fork the OS more-or-less copies and pastes your process control block into a new process.
That’s why fork “returns twice” - from the original process, fork returns just like any other function call, and in the copied process, execution begins in the middle of fork, and the first thing the new process does is return from fork.
In the main process fork returns with the pid of the new, child process. The child process returns with 0 (if it wants to know the pid of the parent, there are separate APIs for that).
There’s wait, which waits for a process to stop, and exec, which replaces the current process with another one (it invokes the loader).
Yes fork and exec are weird; you can’t just ask the OS to come up with a new process for you. Say you’re a desktop and you want to start a program. First you fork the desktop process, then in the fork you exec the program you want to run.
The trick is that exec doesn’t overwrite everything, so between calling fork and exec you have the opportunity to configure the child process (environment variables, where stdin and stdout are wired…). Critically, you configure the child process the same way you’d configure your own process – you are about to become the child process, after all – and so they didn’t need to pack a bunch of configuration options into exec itself.
Compare the Windows API which packs a bunch of settings into CreateProcessW, and allows you to create already-suspended processes if you want to configure even more settings about them before they run. Nothing wrong with the Windows approach, it’s just a different one!
Then there’s signals, process groups, owning users…