3 ms·

Didn't most of the mainstream 90s OSes lack memory protection AND use cooperative multitasking, which meant one bug in an app and the entire system crashes or f

Didn't most of the mainstream 90s OSes lack memory protection AND use cooperative multitasking, which meant one bug in an app and the entire system crashes or freezes?

oneplane 5y ago
Yep, to some degree at least. Even some more modern systems after that had some similar problems, where there was less or no direct interaction anymore and userspace and kernelspace was the 'best' boundary there was to offer. But the same problems still persisted within the space if the other one goes down. Imagine having a fully functional app but you still can't do anything because the service 'on the other side' doesn't work. It's better because it won't crash the entire system, but it's the same because you still can't do the work you intended to do...
p_l 5y ago
No, that's pretty much MacOS Classic and classic windows line before 9x (9x added /some/ level of protection and preemption)
- grishka 5y ago
  > (9x added /some/ level of protection and preemption) I do remember games freezing windows 9x so much that you had to reach for that reset button. Also when the system threw up a BSOD if you ejected a CD when you weren't supposed to.
  - p_l 5y ago
    The latter was due to lack in error messaging to userspace - so you ended up with the only way the kernel could raise the error involved. Games often did things that put the system out of whack, and while 9x had preemption for 32bit code (16bit was cooperative as separate thread, iirc) it wasn't impossible to break the OS state by simply putting bits of hw in weird state or by using a lot of resources.
    - hnlmorg 5y ago
      There were user space errors when an application crashed[1]. Hardware operations run in the kernel space so if the hardware is in a weird space it doesn't matter how good your user space is coded, it's down to the kernel to capture that error handle it. In fact this was one of the big arguments in the 90s in favour of micro kernels vs monolithic kernels -- albeit history has now taught us that we can have monolithic kernels and protection against drivers and/or hardware failing. Any BSOD in Windows is a kernel panic. Most of the BSODs I recall were directly down Windows getting itself into a state that it couldn't recover from. Like IRQ errors, memory errors, etc. And it was often very easy for an application to force a BSOD. I remember this well as someone learning Win32 APIs "by experimentation". Also to say you "it wasn't impossible to break 9x by using a lot of resources" but that is a huge understatement. Even today tou can still break modern operating systems by using too many resources and they have far better protections (OOM killer, smarter paging and stored on media with orders of magnitude higher IOPS, multi-core CPUs that offer true parallelism of operations, etc). 9x, on the other hand, had very little to protect you in that regard. I couldn't even estimate the number of times I've hit ctrl+alt+del on Windows 9x, preying there is enough capacity for the OS to kick in the task manager[2], which back then would also suspend all operations of other applications, thus allowing me to manually terminate whatever processes were causing Windows to grind to a halt. As an aside, it was also possible for applications to hide themselves from task manager too. I had great fun playing around with writing a remote administration tool for college (sadly not for "official" purposes...) so figured out a number of tricks in 95 to work around user permissions, task management, and so on and so forth. Basically 9x was a playground where running applications could pretty much do whatever they wanted. [1] https://telcontar.net/store/archive/CrashGallery/images/crash/m/strangetext.png https://telcontar.net/store/archive/CrashGallery/images/cras... [2] https://telcontar.net/store/archive/CrashGallery/images/crash/m/mswordhang.png https://telcontar.net/store/archive/CrashGallery/images/cras...
mixmastamyk 5y ago
If by mainstream you mean cheap? Yes. But if you wanted to spend money on reliability it was the original option.
Jetrel 5y ago
Yeah, most of them did; especially most of the holdovers from the 80s. This was one of the big draws to pulling down "mainframe/workstation" systems like unix (or what MS did by hiring what IIRC was the VMS team to build NT) onto desktop machines. These mainframe systems actually had memory protection, and more generally, had been built to do what "pc OSes" hadn't been designed to do, which was running several programs at once, for long periods of time, and juggling resource contention between them. DOS machines, CP/M machines, Apples, Macs, Commodores, and several other early machines were pretty tactfully designed to avoid the (too heavy for their hardware) complexity of that by simply building themselves to run only one program at a time. There were hacks to let you run multiple programs (like the Multifinder in MacOS 6, which got mainlined into being a permanent thing in 7), but they were just that — hacks. They were fragile. As computers started taking on the burden of juggling tons of different simultaneous programs, this fragility really started to blow up on them, and these previously "seeming stable" systems started to crash all the time.

Didn't most of the mainstream 90s OSes lack memory protection AND use cooperative multitasking, which meant one bug in an app and the entire system crashes or freezes?

oneplane 5y ago

Yep, to some degree at least. Even some more modern systems after that had some similar problems, where there was less or no direct interaction anymore and userspace and kernelspace was the 'best' boundary there was to offer. But the same problems still persisted within the space if the other one goes down. Imagine having a fully functional app but you still can't do anything because the service 'on the other side' doesn't work. It's better because it won't crash the entire system, but it's the same because you still can't do the work you intended to do...

p_l 5y ago

No, that's pretty much MacOS Classic and classic windows line before 9x (9x added /some/ level of protection and preemption)

grishka 5y ago
> (9x added /some/ level of protection and preemption) I do remember games freezing windows 9x so much that you had to reach for that reset button. Also when the system threw up a BSOD if you ejected a CD when you weren't supposed to.
- p_l 5y ago
  The latter was due to lack in error messaging to userspace - so you ended up with the only way the kernel could raise the error involved. Games often did things that put the system out of whack, and while 9x had preemption for 32bit code (16bit was cooperative as separate thread, iirc) it wasn't impossible to break the OS state by simply putting bits of hw in weird state or by using a lot of resources.
  - hnlmorg 5y ago
    There were user space errors when an application crashed[1]. Hardware operations run in the kernel space so if the hardware is in a weird space it doesn't matter how good your user space is coded, it's down to the kernel to capture that error handle it. In fact this was one of the big arguments in the 90s in favour of micro kernels vs monolithic kernels -- albeit history has now taught us that we can have monolithic kernels and protection against drivers and/or hardware failing. Any BSOD in Windows is a kernel panic. Most of the BSODs I recall were directly down Windows getting itself into a state that it couldn't recover from. Like IRQ errors, memory errors, etc. And it was often very easy for an application to force a BSOD. I remember this well as someone learning Win32 APIs "by experimentation". Also to say you "it wasn't impossible to break 9x by using a lot of resources" but that is a huge understatement. Even today tou can still break modern operating systems by using too many resources and they have far better protections (OOM killer, smarter paging and stored on media with orders of magnitude higher IOPS, multi-core CPUs that offer true parallelism of operations, etc). 9x, on the other hand, had very little to protect you in that regard. I couldn't even estimate the number of times I've hit ctrl+alt+del on Windows 9x, preying there is enough capacity for the OS to kick in the task manager[2], which back then would also suspend all operations of other applications, thus allowing me to manually terminate whatever processes were causing Windows to grind to a halt. As an aside, it was also possible for applications to hide themselves from task manager too. I had great fun playing around with writing a remote administration tool for college (sadly not for "official" purposes...) so figured out a number of tricks in 95 to work around user permissions, task management, and so on and so forth. Basically 9x was a playground where running applications could pretty much do whatever they wanted. [1] https://telcontar.net/store/archive/CrashGallery/images/crash/m/strangetext.png https://telcontar.net/store/archive/CrashGallery/images/cras... [2] https://telcontar.net/store/archive/CrashGallery/images/crash/m/mswordhang.png https://telcontar.net/store/archive/CrashGallery/images/cras...

mixmastamyk 5y ago

If by mainstream you mean cheap? Yes. But if you wanted to spend money on reliability it was the original option.

Jetrel 5y ago

Yeah, most of them did; especially most of the holdovers from the 80s. This was one of the big draws to pulling down "mainframe/workstation" systems like unix (or what MS did by hiring what IIRC was the VMS team to build NT) onto desktop machines. These mainframe systems actually had memory protection, and more generally, had been built to do what "pc OSes" hadn't been designed to do, which was running several programs at once, for long periods of time, and juggling resource contention between them. DOS machines, CP/M machines, Apples, Macs, Commodores, and several other early machines were pretty tactfully designed to avoid the (too heavy for their hardware) complexity of that by simply building themselves to run only one program at a time. There were hacks to let you run multiple programs (like the Multifinder in MacOS 6, which got mainlined into being a permanent thing in 7), but they were just that — hacks. They were fragile. As computers started taking on the burden of juggling tons of different simultaneous programs, this fragility really started to blow up on them, and these previously "seeming stable" systems started to crash all the time.