3 ms·

> (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 t

> (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...

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...