Now, the OS. This is a quick rundown on what goes on, in general terms. In reality, it can get much more complex, but you'll find that success is less about complexity and more about saturation (of drivers). The job of an operating system is to provide a common interface for coders to write programs, without having to write code to do everything. Later operating systems allowed for "concurrency," or "threads," which allow programmers to make programs that can coexist with other programs.

Generally, the operating system can be divided into the bootloader, the kernel, the drivers, the HAL, and the bloatware.

The bootloader: The definition seems to change depending on the architecture, unfortunately. Sometimes a BIOS is present (UEFI is still a BIOS even if everyone says it's not, and the old BIOS standard is still preferred [at time of writing, and probably whenever you're reading this] over the newer UEFI standard [it made a lot of promises that it didn't deliver, and the transition was horrible]), which makes things easier. Basically, on x86 machines, you have a BIOS that provides certain "universal drivers" for certain types of hardware. The bootloader uses these to load the rest of the OS into RAM from wherever it is stored, since on x86 only the first 512 bytes are loaded off the bat. For other systems, the bootloader is the first thing that runs and allows for reprogramming the program EEPROM. In this case, the bootloader can be erased, but it's usually small and allows for reprogramming the EEPROM over USB or something to that effect, so most people leave it alone.

The Kernel: The objective of the kernel is to provide the basic interface between the remaining parts of the OS. Typically the kernel houses the "universal drivers," or the basic drivers that the BIOS would normally provide (if it is present), but enhanced so that the OS has more control over the drivers and doesn't have to "switch modes" (which x86 has to do to use the universal drivers). The kernel also makes it possible for more than one program to run at a time, and establishes the rules for which programs interact.

The drivers: These are programs that're usually written by 3rd parties to allow hardware to work with the kernel and/or HAL. The idea is, not all keyboards and mice follow the same rules. Some people like to have extra buttons on their mice. This requires a whole new driver. GPUs pretty much always need their own drivers, but often allow for a fallback driver like the ones provided by the BIOS. The reason for this is, alot of GPUs provide functions and techniques that cannot be predicted at the time of writing the OS. What I don't understand is, to even use these features the programs that would be able to take advantage of them would have to know how to use them. What I've noticed, however, is that alot of the drivers end up unloading alot of the work on the CPU instead of the GPU, which allows the GPU to appear faster than it really is if it's backed by a fast CPU. And since the code is copyrighted, it doesn't get ported to other OSes, which has been helping Microsoft keep control of the market, since no one wants to make a game for Linux if it won't run very well since Linux is constantly falling back on the VESA drivers, even if it's otherwise the better OS.

The Hardware Abstraction Layer: Basically, a layer between the drivers (not always all, though) and the kernel. The objective here is to provide an interface so the kernel doesn't have to keep changing with the drivers and the drivers having to constantly change with the kernel. In practice, it usually fails at this job to the degree that looking at wikipedia right now shows me a grand total of 3 overly successful examples.

Bloatware: These are the programs that come pre-installed with the OS, that you can't dislodge even if you wanted to (and we know you actually do want to, but no one told the company that). These are your default programs for things, as well as the advertising software, some sort of forced news feed and weather service that you don't care for, etc. Usually there's some gems in there, though, like an API (Application Programming Interface), which is just a fancy name for "3rd party code that provides functions to a certain standard that can be readily learned and used to make your own programs, and often with an abstraction layer so they can be made available to others.

Get your own web kitty here!
┬ęCopyright 2010, 2011, 2012, 2013, 2014, 2017, 2018. All rights reserved.