Iyfjky

Question

Preemptive (rather than cooperative) multitasking was a highly-touted feature for PC's in 1996, with its inclusion in Windows 95 for the first time. It was also highly-touted for 2001 Macs when included with OS X. Earlier versions of both these mainstream consumer OS's supported cooperative multitasking.

Meanwhile, preemptive multitasking was the default for more sophisticated OS's, like Unix and OS/2, even decades earlier. And the Amiga shipped with a consumer OS with preemptive multitasking in 1985.

Notwithstanding the Amiga being 15 years ahead, why was it such a long time for preemptive multitasking to be supported by the mainstream consumer OS's?

Wild speculation: Customers wouldn't care enough about it to justify the implementation cost, but when they got around to supporting it (Windows 95 changing lots of internals, and OS X completely rebuilding the OS on top of BSD) it was a great thing to market because it had the word "preemptive" in it. — 3 hours ago
Windows 3 had pre-emptive multi-tasking between VMs too (the DOS VMs and the Windows VM), didnÃ¢Â€Â™t it? (Yeah, nitpicking, since the Windows apps multi-tasked cooperatively, until one crashed...) — 3 hours ago
The Apple Lisa had preemptive multitasking in 1983; you just need to redefine consumer to be equal in wealth to four or five consumers. — 2 hours ago
I ran DESQview with pre-emptive multitasking in the late '80's as well, and I believe IBM's Topview did the same before then. — 2 hours ago
Would you consider TSRs like Borland Sidekick to be pre-emptive multitasking? They fit many of the criteria of multitasking: time-slicing, context-switching, and even system support (in the form of the InDOS flag)! — 2 hours ago

PoC 967 · Answer 1 · 2018-09-26 18:41:51Z

Speaking for the Macintosh here.

TL;DR: It wasn't possible to do this in a compatible manner after the hardware was capable enough. Compatible to the already existing application base.

You'll need to see this in context with the heritage of the Macintosh Operating System itself. It was built to run in an considerably limited environment, regarding CPU power and available real memory. Add the fact that the initial release was certainly not production quality code, time pressure was high to get the whole thing running good enough for the highly anticipated release. See Folklore.org for details.

(Lacking memory remapping support in the CPU plus initial floppy-only machines prevented to implement paging in a bearable manner. See Memory Management Unit in Wikipedia for details.)

When RAM got cheaper over time but floppies still were current as permanent storage medium, the Switcher was born by chance. Applications were adapted to better behave with Switcher and vice versa.

From there, MultiFinder was the next step, coming out in 1987. It (also) takes advantage of the fact that there's relatively little to change in Applications for not only sitting in RAM, waiting to be switched to foreground but also being able to run in background. MultiFinder simply exploited the main loop every program was executing, mostly waiting for the user to do something. Applications mostly were stuck in a system routine which delivers an event (Keyboard entry, mouse click, Ã¢Â€Â¦) to the application program to handle. MultiFinder kind of steals control from applications stuck in this routine and passes control to the next eligible Application. If an Application rarely calls this getNextEvent() routine, it behaves poorly in MultiFinder. Regardless if background or foreground. Best negative example is using Background Printing. Print Monitor searches the Network for the chosen (selected) printer. If the printer is switched off, the whole machine hangs for nearly a minute until Print Monitor returns with an error after a timeout, displaying error condition indicators and calling getNextEvent() so it can handle the user's input.

Over time, developers made Applications more multitasking-friendly by adding getNextEvent() in internal processing routines, so lengthy processing didn't block other applications. This usually doesn't feel as fluent as cooperative multitasking in a graphical environment, though.

(Novell Netware 3 and later also supported cooperative multitasking between extensions of the Kernel, server.exe. These NLMs were loaded at runtime and provided hardware services like drivers for mass storage adapters and network adapters as well as additional network protocols like AppleTalk and TCP/IP, and application support such as pserver.nlm, the print server or database support from Oracle, Ã¢Â€Â¦ I never programmed NLMs but Novell's implementation of cooperation was either very sophisticated and/or in a text based environment, the possibly non-monotonic time slices weren't as apparent as in a GUI environment like the Macintosh ones.)

System 7 added some more code to smooth out multitasking further. I can't prove it but I think, Apple changed the way to decide which Applications were eligible to get CPU control. Kind of dynamic scheduling instead of a dumb cycle through all open Applications: Foreground Application gets control more often than background ones.

In the meantime there were a lot of applications for the Mac. Commercial, free- and shareware. Apple's struggle to keep up with competition while trying to reimplement a new OS with features we today take for granted while keeping compatibility with this pool of Applications can be searched in online media archives of the late 1990s. Search terms include Taligent, Copeland, BeOS and finally NExTStep reborn as Mac OS X.

Switcher was a quick hack; MultiFinder extended the possibilities and that's about it. I think, Apple was too busy creating the next big thing instead of trying to use bolts and nuts to add stuff which involves changing basic OS stuff in an possibly incompatible way.

Btw., the Amiga had the advantage of it's coprocessors relieving the main CPU from certain tasks. I can't prove it but I think that in such an environment, cooperative Multitasking was a better way to exploit this seemingly-parallel execution environment.

Wondering if there is a typo in your last paragraph? Should it be "preemptive multitasking is a better way..."? — 1 hour ago
What were the "considerable limits" you mention in the third paragraph? — 34 mins ago

Will Hartung 2,728617 · Answer 2 · 2018-09-26 18:31:39Z

Memory protection.

It's not that preemptive multi-tasking is expensive, or hard. It's not. It's easy. It (can) costs, essentially, the same as cooperative multitasking. You have to save process state in both cases.

But what was holding back the older systems was their early reliance on systems without inherent memory protection, and those legacy's lasted long past the availability of hardware that actually had supported Memory Management Units (MMU).

Take the Mac. It's legacy was the 68000, which had not direct MMU support.

It was not long before the Mac came out with 68020 based machines (which DID have such support). But the OS has to run not just on the new hardware, but the old hardware, and the two systems are quite incompatible. Plus the actual impact on software design on those systems.

When you start from scratch, like OS/2, then, yea, "it's easy".

MacOS heritage held it back for a long, long time before they were able to replace with with MacOS X via it's Carbon compatibility layer for the software in the new, Unix-ish environment.

The OS for the Apple IIGS was actually a "better" MacOS in someways, notably in process management and memory management. MacOS 2.0.

Windows suffered similarly. Recall early Windows ran on the 8088. Not the 80286, the 8088. That legacy also burdened it for quite sometime.

Code has momentum, choices have consequences. Be amazed they worked at all.

The Amiga featured preemptive multitasking without memory protection. I don't think that the kind of multitasking (preemptive vs. cooperative) and memory protection are related. The Amiga also had a 68000 CPU, without MMU. — 1 hour ago
The Sinclair QL had preemptive multitasking even a year earlier. It had a 68008, thus no memory protection as well. Memory protection is no precondition for preemptive multitasking. — 46 mins ago
I had ran a fully preemptive lightweight OS such as FreeRTOS even in small 8-bit AVRs that only have a few KB of internal RAM, with no memory protection, no MMU and not protected modes at all. — 34 mins ago

Raffzahn 35.3k478140 · Answer 3 · 2018-09-26 20:03:28Z

To start with, the only needed hardware for preemptive multitasking is a interrupt capable timer. Everything else can be done in software. Though, some memory management would be helpful. Beside custom solutions that hardware was already ready off the shelf for 8 Bit CPUs. Beside more generic solutions like TI's 74610 series, more advanced solutions like Motorolas 6829 where available.

Notwithstanding the Amiga being 15 years ahead,

Lets skip that subjektive part, ok :))

why was it such a long time for preemptive multitasking to be supported by the mainstream consumer OS's?

Now hold the horses. I hope you agree that CP/M was a mainstram consumer OS, wouldn't you? DR did offer it's preemptive multitasking brother MP/M already in 1979. It did already work with 'only' 32 KiB, but ofcourse considerable better with several 64 KiB address spaces, one for each.

This 'huge' memory requirement also marks the primary reason why usage was limited: THe price for such a computer. MP/M was targeted at 'power users' with an urgent need to have multiple applications running in parallel. While RAM prices did drop, this need for a use case stayed.

MP/M-86 was available right with the IBM-PC and turned later on into Concurent-DOS. Still it was the missing USE case that stoped a broader usage. Not at least due missing software that would benefit from multitasking at all. Other more limited products like DoubbleDOS and desq had more success to the general public by offerering the chance to hold more than one program in memory, handy to reduce load times. Otherwise there was little gain, as these programs worked virually seperated.

More problem centric solutions like Sidekick did gain much popularity, as they offered at least some (workflow) integration. Apple on the other hand did focus from the begining on a more user centric aproach. Already the original Finder supported clipboard exchange and accessories in addition to a (single) main application. With System 5's Multifinder more than one application could be loaded. still, it took some time until this realy got a foothold thru better integration.

Bottom Line: It's about the appcation, stupid.

From a users perspective there is no real difference between cooperative and preemptive multiprocessing. It's all about what can be done. No matter how we engineering orientatet people value these concepts, Multiprogramming, Multitasking, Multiprocessing and all the other Multi* are only tools to enable the user to do his tasks and no real value in itself. Seperated Addresspaces, premptive multitasking ans so on only became standard when according hardware came for free and at first only support programmers in creating applications (or help handling theri inability to do so), not offering any direct benefit to the user.

PoC 967 · Answer 4 · 2018-09-26 18:41:51Z