Hacker News Reader

Comment by jandrese | Hacker News Reader

It's amazing how far we've come that one of the selling points on the NeXT box over the traditional Windows 3.11/DOS development machine at the time was that the NeXT box didn't lock up or crash constantly.

People today forget just how annoyingly common it was for old versions of Windows to lock up or crash for no apparent reason at completely random times.

View on HN

Indeed. There's a reason this Dilbert strip, from just a couple of years after the time Carmack was working on Doom, resonated so widely:

http://farm1.static.flickr.com/87/240803829_9212773615_o.png

I remember that when I was developing C++ code on Windows 3.11, the operating system would frequently crash when the program I was writing crashed. I was very happy when I installed Windows NT 3.51 and finally got a stable operating system. It was much more productive not having to reboot your machine all day.

The old Macs (before they had a Unix-based operating system) were also pretty unstable if you were doing software development on them (no memory protection).

Was the nature of the crashes due to poor process isolation? Processes going into infinite loops? Memory corruption of the OS?

It seems like the limitations were probably not hardware related, although many hardware features since have made certain tasks and isolation easier. Though unix had a reputation for requiring more capable computers to run.

In my experience, crappy drivers were a frequent reason for crashes. ISA Plug and Play was the worst kind of hack and it bluescreened many machines in its day. But also, computer hardware in general was just crappier back then and the drivers were often just total shit.

These days there are lots of standards to help compatibility, and for simple things (like mice) you have the built-in drivers that work fine. But back in the day everyone had to write their own drivers and most of them were poorly tested and thanks to the lack of process isolation could very easily step on other crappy drivers written by other hardware companies.

Application bugs could also overwrite parts of the kernel by just accidentally dereferencing a null pointer. Those pre-NT Windows systems were built on a house of cards, and every card was made by a different person who never got to look at any of the other cards.

>In my experience, crappy drivers were a frequent reason for crashes.

Indeed. In the XP era:

"The main cause of BSOD in Windows XP was device drivers, which were responsible for some 85 percent of hiccups in the OS."

http://www.zdnet.com/article/why-the-blue-screen-of-death-no...

And in the Vista era, looks to be a bit under 82% according to evidence presented in a lawsuit:

https://www.engadget.com/2008/03/27/nvidia-drivers-responsib...

Pretty sure Win 3.x had no concept of processes and no memory isolation of any kind. Contemporary Macs were in a similar position. Both were ludicrously unreliable by 21st century standards. And in both cases the hardware - Intel 80386s and Motorola 68000s - offered support for protected memory. The software just wasn't there yet.

Both were ludicrously unreliable by 21st century standards.

They were ludicrously unreliable by 20th century standards, too. It's just that not a lot of people had hands-on access to a mainframe or a mini running Unix, so the end-users got to think that's just how computers work. From my POV, PCs and Macs of that era were toys that coincidentally would occasionally allow useful work to get done. That's not to say I didn't do a lot of development for both, but my $DEITY did I wish I had to money for a real machine like a NeXT.

And MacOS didn't get protected memory until Apple acquired NeXT!

I think Win3.x was relatively poor in all of those. This reminds me that the OS/2 2.0 fiasco is one of my favorite topics.

Here's another interesting point to consider. Once you started exposing computers to the Internet directly, just about every OS had to be rebooted very frequently.

Reply on news.ycombinator.com