Back when machines only had one or two CPUs (still the case for embedded devices) the OS Kernel was responsible for making sure that the machine coule process more than one instruction “path” at a time. I started coding back on the Commodore 64, and there it was easy to lock up the machine: just run a program that does nothing. I’d have to look back at the Old Programmer’s Guide, but I am pretty sure that a program had to voluntarily give up the CPU if you wanted any form of multi-tasking.
The alternative is called “preemptive multitasking” where the hardware provides a mechanism that can call a controller function to switch tasks. The task running on the CPU is paused, the state is saved, and the controller function decides what to do next.
While preemptive multi tasking had been a server feature for a while, it took some time for it to creep down to the personal level. Like the Commodore 64, MS DOS programs took over the entire machine, and it was not uncommon to have to reboot to switch programs due to some start-state-assumption not being met. Preemptive multitasking was one of the driving factors behind the OS/2 effort. But then IBM and Microsoft stopped working together on this effort. Windows 95 was a halfway there implementation; true preemptive multitasking would have to wait for Windows NT. Apple didn’t really achieve preemptive multitasking until OSX came out. In the case of Apple, the argument was that, especially for timing sensitive applications like Music generation, you wanted strict control of the the machinery and the timers.
EDIT: Win95 had preemption…it just had other issues.
Yah, I am skipping a whole bunch of other things out there, like OS9 and the TRS/80. Commodore Amiga.
Meanwhile, the Open Source Operating Kernels based on the Unix model had some form of preemptive multitasking from the get-go. Multics, written as an example OS for academic purposes, was used outside of the class room in limited circumstances. The various flavors of Berkeley Systems Division (BSD) Unix had preemptive multitasking, but their adoption was hamstrung by an IBM lawsuit….which left the field open for Linux to become the OS of choice for a class of user.
Note the complete lack of citations above. Why? Because this is from memory, and should not be considered scholarly or definitive. Assume that I am making mistakes, and confirm what I am saying else where if you wish authoritative support. So why am I writing this? I want to give context around the follow on articles discussing the Kernel Scheduler abstraction.
Windows 95 was fully preemptive and memory was protected, but there were shared resources that applications could pollute which would bring down GDI or KERNEL. That problem was what NT fixed.
[1] https://beej.us/guide/win95sch.html
Right…right… It was DOS compatibility, essential for adoption, but harmful to stability, that was the issue IIRC. There were some significant compromises made along that front. I was never that deep in the details; once I started working on this professionally, it was mostly NT based work, as the libraries I worked on had to work on both, and our server was on NT. I just remember hunting down a bug about a double click and my coworker exclaimed that the second click was impossible due to non-preemption. I’d filed that away in the back of my memory. IIRC we fixed it by moving the offending command down into a sub where it belonged as opposed to having it as a top level menu item.