Interesting! I don't use Windows, so I didn't know. The C11 threading model is basically a subset of POSIX C threads with different names, so I still think looking at the explanations wrt. POSIX processes and threads gives a pretty universal view, although various OSes have their quirks.Originally Posted by gemera
Although Phantomotap already gave a pretty good answer, I'd like to get a bit more in depth.
As I wrote earlier, processes and threads are logical constructs used by the operating system. They do not "exist" before the operating system kernel (the kernel, not all operating system services) is fully up and running, and quite a lot of interesting stuff happens before that.
When you turn on the power, the motherboard starts supplying power to the various components like clock chips, memory, and so on. When the voltages (and clock output) has stabilized, the primary core in the primary CPU starts executing code from firmware -- BIOS or EFI in x86 and x86-64 machines, Open Firmware on SPARCs, and so on. In the past, this code resided in a memory-mapped ROM chip, nowadays more typically in Flash memory, with circuitry on the motherboard to deny accidental writes during normal operation ("BIOS write protect", "BIOS boot protect", and so on).
The initial firmware brings the machine to a stable state. It configures all the buses, assigns resources like memory apertures and IRQ lines, and so on. Open Firmware uses bytecode Forth residing in each (complicated) device to do this. BIOS and EFI often use ACPI standard to describe the devices.
The BIOS/EFI/Open Firmware also probes all mass storage devices in the system, and reads their partition tables -- basically the index describing what the device contains, then chooses which one to boot from. (You can interrupt this process by a keypress, and override the choice.)
To boot, it reads a specially prepared executable from the boot device. Exactly where, and what format this executable uses, depends on the firmware type. (As far as I know, these are now known openly/publicly, and the only problem is that some EFI firmwares will only accept executables signed by a key owned by a specific company, making it impossible (in some cases) to boot your own OS. Fortunately, most EFI firmwares allow you to override that check, or add your own accepted key.)
This boot loader is still a very special environment; it is not really even a process in the normal sense, because it is the only thing being executed on the computer at that point (aside from snippets of firmware, either by calling into it, or by IRQ lines or such triggering interruptions and jumping temporarily to the firmware code). Similarly, there is no "thread" yet, just because this is still such a special environment.
When the boot loader has picked the OS kernel it chooses, it loads the kernel into memory. (Note that the stuff that is loaded into memory is not just executable code, either. In fact, the Linux kernels are compressed, and the boot loader often loads a minimal "disk image" containing boot-time stuff, like the graphics shown during bootup and so on.)
When the boot loader hands off the machine to the kernel, the kernel initializes itself -- most importantly, sets up virtual memory and usually fires up the rest of the CPU cores, but does not yet initialize or start any of the nonessential devices. This is called early boot, and is quite a tricky part even for kernel programmers.
After the kernel has stabilized -- all memory accounted, kicked out the bootloader, and so on -- it is ready to start new processes and threads. At this point, Unix and POSIX operating systems start the init process, PID 1, whose purpose at this point is to bring up all the drivers and then the services. (In Linux, this process is usually from the initial disk image, ramdisk, and loads device driver kernel modules, and starts the boot splash graphics. After the drivers have been loaded, and all filesystems found, root is "pivoted" by mounting the actual storage devices, and the initial init process replaces itself with the proper one, that starts the services.)
If, instead of power-on, the machine resumes from disk, the process is slightly different. The details vary a bit, but the firmware or the boot loader or the early kernel, instead of starting from scratch, reads the contents of RAM from the suspend image, and prepares the processes etc. accordingly. It sounds complicated, but it really boils down to storing and restoring the memory contents, and the kernel's idea of currently running processes and threads, and the resources they have claimed.
One reason I prefer Linux and the BSDs over Windows and Mac OS X, is the way I can fine-tune this process. For example, I use a custom boot splash. When my computer boots up, it shows Tux (my avatar) on black background (this is my BIOS/EFI background picture, i.e. shown during BIOS startup, prior to bootloader). Bootloader also shows the same image. When the kernel starts loading, Tux starts rolling its eyes, and does so until all necessary services are up and the login screen pops up. (The animation cleverly uses sprites, so it's very lightweight, and does not increase the bootup time at all. I checked.)
What I do not understand is why high-profile companies and organizations do not leverage this configurability, to both visually pop out their workstations, but also customize the machines to best fit the workflows. One or two Linux nuts on payroll is not that expensive.
