Originally posted by: The Linuxator
the answer can be simply because win9x mostly utilizes 16-bit code instead of the mainstream 32-bit code , and as you know using 16-bit code can be a hurdle in the face of the simplest attempts of multitasking , and maybe thats why your system tends to freeze alot.
There wasn't all that much 16-bit code in Win95 to begin with. As I recall, GDI and USER remained 16-bit to provide maximal backward compatibility with 16-bit Windows apps. An interesting tidbit: Windows 3.11 served as a sort of demo for Win95 technology and even contained a 32-bit disk controller device driver.
But Win95 supports 16-bit device drivers and certain areas aren't protected. Atleast the first 1088KB address space is left largely unprotected. E.g. 16-bit apps can directly modify the interrupt vector table (handily located at the first 1K) and it can mess with the interrupt controller.
Try running DEBUG from the command line, and try the following commands:
- o 21, ff
- f 0:0 L ffff 00
the first should effectively disable all interrupts (port 20 was EOI, and 21 the interrupt controller, right? I keep mixing them up), thereby freezing your computer, and the second should mess up the interrupt vector table. Under Windows Toystation you'll get fireworks, but under a real OS only the current VM will be affected (just alt-tab and you'll be back in business).
Multitasking 16-bit code isn't hard. Windows NT can run several 16-bit apps simultaneously just fine. But in Win95 they kept GDI unchanged and all code that does anything graphical will have to pass through a part of the OS that is only executing in a single thread. (Windows NT prior to NT4 had problems multitasking graphic-intensive apps as well, despite running off a pure 32-bit codebase -- NT4 OTOH moved GDI into the kernel to better support multi proc systems).
But bottom line: Maintaining any form of stability under Win9x is a pipe dream.