Were you actually a Mac user? The initial release of OS X was quite inferior to OS 9--it was an incredible proof of concept and perfect developer target, but for an end user, not so much.
I've been in computer labs full of Mac OS 8/9 machines happily browsing the internet so I'm not sure what your claim about "unreliable network stack" is referencing. Unless you mean "a crash requires a reboot" which was true, but also often true for Windows 95/98 as well!
If you had good enough hardware to run OS X, running OS 9 stuff in Classic meant that at least you didn't have to restart your whole computer when something froze, just all your OS 9 software. OS X was definitely slow and a bit buggy early on, but IIRC it got good enough for daily use around when Jaguar came out (late 2002?).
OS 9 running Microsoft Internet Explorer! I can remember the puck mice and the noise of the hard drive grinding away while pulling up Ebay and the campus webmail (Horde/Roundcube debates going on and on...)
I remember browsing using 5 slightly offset IE windows stacked diagonally, since this was somehow before tabs in browsers.
When I was in grad school I worked in a corner which had a mac on one side and an IBM POWER system with a huge screen on the other side.
Early on the mac was crashing all the time when I was browsing the net, at some point in the 8-9 era they added a bunch of locks to stop the crashes and then it was beachball city all the time.
My understanding was that classic was built on the assumption that events come in from the keyboard and mouse and once you added more events from the network it exposed race conditions. It probably didn't help that we were on "Internet 2" had were early to get 100 Mbps ethernet. If you were using dialup it was probably not so bad.
People think "you have race conditions or you don't" and that is true on some level but if your utilization factors are low they might cause problems once a month but increase the load and those problems are happening once an hour. I saw all the symptoms that I expected such as a brand new and faster mac crashing less often than the old mac because it had more capacity to process events and less overlap between them.
Yeah '95 was bad, NT not much better despite the fanbois saying otherwise (had terrible fights w/ a prof who was a roommate of Bill Gates who got a grant from Wintel to get new x86 machines.) Once we got those machines there were two of us you'd always find in front of the NT machines: the student who liked NT and myself who would use VNC to log into one of the few Linux machines. One day that prof came around and said "you win Paul!" and announced that most of those NT machines would be switched to Linux.
The rainbow beachball cursor was added in OS X. I think your memory of the Mac OS 9 machines might be mixed up.
Classic Mac OS used a cooperative threading model which meant that one program locking up would lock up the whole computer, but Windows 95 was only slightly better in this regard. It didn't have any classical race conditions with the network as you can't "race" in a world with no preemptive threads--control is only ever handed off when a program explicitly yielded.
It was a wristwatch back then, right?
Win 95 had real processes and threads, memory protection and all of that but it wasn't terribly effective. The whole machine would go down frequently (as did Win NT despite Microsoft’s insistence otherwise; Microsoft kept repeating "It's the hardware stupid", Win2K was a great improvement but WDDM in Vista meant you could crash your display system and not crash the rest of the machine and I think got us in "rock solid" territory except for the the power management crashes that still dog us today) and it was absolutely endemic that applications would crash, I think because of memory safety problems. The industry went through a transition of "those crashes are annoying" to "those crashes prove your system is vulnerable to hacking..
I have had to argue with people so many times over that "you can't have race conditions in systems that have cooperative multithreading" in teams that couldn't fix those race conditions because they didn't believe they can exist.
Like yeah, thread A can't stomp on data that thread B depends on but you can definitely have situations where different things happen because of different orders of events. Like I was working on a knowledge graph editor in GWT around 2005 or so that had problems because it would try to cache results of XHRs and very different things could happen if a function called a callback synchronously with data from the cache or if later that callback got called by a callback that was called by the XHR. If you are systematic about things you can do it right, everybody is aware of these problems in threaded systems and threaded systems give you tools for protecting your data but in cooperative systems people will tell you don't exist even when the systems are crashing and corrupting data right before their eyes.
(Look at how Python has synchronization primitives for async that are roughly parallel to the ones in threading. In old school cooperative multithreading you are taking code that could be threaded and cutting it up into pieces manually and that gets super-difficult as complexity. Even if you don’t want to face up with concurrency means concurrency doesn’t want to face up to you.)
> My understanding was that classic was built on the assumption that events come in from the keyboard and mouse and once you added more events from the network it exposed race conditions. It probably didn't help that we were on "Internet 2" had were early to get 100 Mbps ethernet. If you were using dialup it was probably not so bad.
They added preemptive multitasking around System 7.5, but anything that used the Toolbox still had to run in the main thread and be cooperatively multitasked so it wasn't much of an improvement (hence the lockups).
For that matter when they added SMP support to Linux they put most of the kernel behind a giant lock so, effectively, applications could run multiple processors even though the OS could only handle one. I guess you could have done the same thing with a single-process OS.
The list of classic Mac OS programs which actually spawned preemptive threads was probably in the single digits. Very few of the machines were multi-core, so it didn't matter much.
I'm not sure exactly how many programs used them, but support was fairly widespread in a lot of popular programs because it was the only way for Classic Mac OS to make use of the second processor in multiprocessor machines. Some examples of software that used preemptive threads are Photoshop, Final Cut Pro, After Effects, Premiere, Lightwave, and Cinema 4D (see https://www.macworld.com/article/159778/mp_mac.html ).