3 ms·

> Apple could have worked in multitasking in classic MacOS if they really wanted to They did, and they couldn’t. Most users had some code running that patched

> Apple could have worked in multitasking in classic MacOS if they really wanted to They did, and they couldn’t. Most users had some code running that patched system calls locally or globally or that peeked into various system data structures, and all applications assumed the system used cooperative multitasking. Going from there to a system with preemptive multitasking would mean breaking a lot of code, or a Herculean effort to (try to) hack around all issues that it caused with existing applications. I think that would have slowed down the system so much that it wasn’t worthwhile making the effort. Having said that, MacOS 9 had a preemptive multitasking kernel. It ran all ‘normal’ Mac applications cooperatively in a single address space, though. Applications could run ’tasks’ preemptively, but those tasks couldn’t do GUI stuff (https://developer.apple.com/library/archive/documentation/Carbon/Conceptual/Multitasking_MultiproServ/01introduction/introduction.html https://developer.apple.com/library/archive/documentation/Ca...)

miki123211 3y ago
Microsoft actually sort of did that with Windows 9x. There was a lot of Windows 3.1 and DOS software and drivers that they wanted to remain compatible, and those relied on DOS quirks. So, they had a copy (copies) of DOS always resident in RAM, mostly unused. All DOS syscalls (interrupts) were hooked so that they would call Windows instead. If a program added its own hooks, Windows would detect that and switch to 16-bit mode for the relevant operation. When the custom hook completed, it would call the next hook in the chain, which was the one that went back to Windows. Of course, this relied on Windows understanding DOS's internal data structures and keeping them in sync with what Windows was doing. A similar technique was used for drivers, if Windows found a driver it didn't understand, it would let that driver run in 16-bit mode. Raymond Chen (of Microsoft fame) explains this much better than I ever could https://devblogs.microsoft.com/oldnewthing/20071224-00/?p=24063 https://devblogs.microsoft.com/oldnewthing/20071224-00/?p=24...

miki123211 3y ago

Microsoft actually sort of did that with Windows 9x. There was a lot of Windows 3.1 and DOS software and drivers that they wanted to remain compatible, and those relied on DOS quirks. So, they had a copy (copies) of DOS always resident in RAM, mostly unused. All DOS syscalls (interrupts) were hooked so that they would call Windows instead. If a program added its own hooks, Windows would detect that and switch to 16-bit mode for the relevant operation. When the custom hook completed, it would call the next hook in the chain, which was the one that went back to Windows. Of course, this relied on Windows understanding DOS's internal data structures and keeping them in sync with what Windows was doing. A similar technique was used for drivers, if Windows found a driver it didn't understand, it would let that driver run in 16-bit mode. Raymond Chen (of Microsoft fame) explains this much better than I ever could https://devblogs.microsoft.com/oldnewthing/20071224-00/?p=24063 https://devblogs.microsoft.com/oldnewthing/20071224-00/?p=24...