34

I seem to remember that IBM claimed one of its versions of OS/2 was crashproof. I believe they specifically said it was "crashproof" or some similar term to indicate that it would never crash.

But someone came up with an exploit that caused OS/2 to crash, and IBM stopped advertising it as crashproof.

A PC Magazine article backs up my recollection:

Years ago, IBM tried to promote a version of OS/2 as "crash-proof." This gambit ended when Microsoft designed some code specifically to crash the system and during a COMDEX event, Steve Ballmer went from machine to machine with a floppy disk crashing these "crash-proof" OS/2 machines.

Also, a photo of the back of an OS/2 Warp box shows that it says:

Its Crash Protection helps prevent a single, wayward program from affecting the rest of your system.

Although my recollection is that they changed their description of OS/2 from "crashproof" to "crash protected" after the release of the exploit.

Was there a specific feature or design/architecture that OS/2 had that IBM believed would prevent it from crashing, and what was the exploit that proved that wasn't true?

10
  • 5
    It's an intriguing question, but what evidence do you have that IBM claimed that? I have no memory, though it was meant to be better than DOS/Windows because it offered a degree of pre-emptive multitasking and some form of memory protection or isolation. Commented Dec 30, 2020 at 20:43
  • 2
    While mentioning it, the Article does not contain any testable source, just the same claim. I think without some proof of this claim being made by IBM, this stays rather in the vague realm of personal memory.
    – Raffzahn
    Commented Dec 30, 2020 at 20:58
  • 2
    @Raffzahn I am not saying that "crashproof" meant that not even an application would crash. I found articles by John Dvorak (who I think is reputable) saying that IBM suggested the OS itself would never crash. Here is a link where he said IBM tried to trademark "crashproof". Commented Dec 30, 2020 at 21:50
  • 2
    There was a period of time when it was not unusual to find various "kiosk" machines - ATMs, airport arrival/departure displays, etc - with an NT blue screen or an OS/2 crash screen out there in the open air for anyone to see. ATMs were OS/2 if I recall, airport displays preferred NT ....
    – davidbak
    Commented Dec 30, 2020 at 22:46
  • 1
    And you could bring it down without crashing it. Tried it to run an unattended DOS program--we kept finding it hung. Then I figured out it wasn't hung, just memory-leaked so badly that it would take a minute of thrashing to respond in the slightest. There's no way the program could have done that, it had to be a system issue. Commented Jan 1, 2021 at 6:53

3 Answers 3

37

I'm not sure about the advertising, but OS/2 1.3 really was extremely stable. Later versions were also quite stable, though it never seemed to me that any of the others quite matched the last of the 1.x series.

Most of that came from using the processor's protected mode, which most other OSes that were in wide use on PCs at the time didn't use.

In particular, most people on PCs at the time ran MS-DOS, which ran in real mode. In real mode, all code running on the machine had access to all memory locations, so it was entirely trivial for a normal program to overwrite things like the operating system or the interrupt table. The interrupt table was especially vulnerable because it was right at the beginning of memory, so writing via a null pointer would overwrite more or less arbitrary interrupt vectors.

By the time of OS/2 1.3, many MS-DOS users did use some sort of memory manager (e.g., 386^Max). In this case, MS-DOS was technically running in a V86 process, and the processor itself was running in protected mode. For better or worse, however, unless you also ran something else as a "supervisor" (e.g., DesqView), the fact that you were in protected mode was mostly hidden, so the system provided (at best) a minimal improvement in stability over actual real mode.

Since then, use of protected mode has become ubiquitous. While it's still possible to crash a computer (e.g., Windows' notorious blue screen of death) there's really no comparison to how things were under MS-DOS.

I'm not sure it was ever used as the basis of an actual attack, but others have mentioned OS/2's queuing problem, but nobody's explained what the problem was.

As events arrive from the keyboard, mouse, etc., they're put into a queue. Then the PM figures out where they should be routed, and the target process removes the event from the queue. Lather, rinse, repeat.

The problem arose if a program simply quit removing its events from the queue. There was one queue shared between all PM processes, so if one didn't retrieve its message, nobody else could retrieve theirs either, and the system quickly ground to a halt.

enter image description here

For Windows NT, Microsoft changed the architecture just a bit, to prevent this:

enter image description here

In this architecture, the OS kernel code removes events from the shared queue, sorts out where they should go, and deposits each in the event queue associated with the proper process. If a process quits processing its events, its own queue will back up (and the user will get an error message), but it won't affect any other processes.

Windows certainly has its share of problems as well, but this particular problem definitely is not one of them (unless you're looking at Windows 3.x/9x/Me, which was an entirely different beast).

2
  • 2
    I concur with Jerry's answer, from my experience of having written a ground-up protected-mode microkernel: Intel's 4-ring model could be made extremely robust. Noted @ArthurKalliokoski's answer, but what that's really demonstrating is that the GUI could be locked up, rather than that the underlying OS- supporting multiple server processes etc.- could be crashed. Having said which, my recollection of OS/2 isn't pleasant. Commented Dec 31, 2020 at 10:47
  • When MSDos software and native OS2 software was used OS2 was very stable, Once Windows software was used it did not do as well. Commented Dec 31, 2020 at 14:30
26

SteveB went on the road to see the top weeklies, industry analysts and business press this week to give our systems strategy. The meetings included demos of Windows 3.1 (pen and multimedia included), Windows NT, OS/2 2.0 including a performance comparison to Windows and a “bad app” that corrupted other applications and crashed the system. It was a very valuable trip and needs to be repeated by other MS executives throughout the next month so we hit all the publications and analysts.

http://techrights.org/2009/06/17/steve-ballmer-crimes-vs-os2/

Unfortunately, OS/2 had a crucial flaw in its design: a Synchronous Input Queue (SIQ). What this meant was that all messages to the GUI window server went through a single tollbooth. If any OS/2 native GUI app ever stopped servicing its window messages, the entire GUI would get stuck and the system froze. OK, technically the operating system was still running. Background tasks continued to execute just fine. You just couldn’t see them or interact with them or do anything, because the entire GUI was hung. Some enterprising OS/2 fan wrote an application that polled the joystick port and was supposed to unstick things when the user pressed a button. It rarely worked.

https://arstechnica.com/information-technology/2019/11/half-an-operating-system-the-triumph-and-tragedy-of-os2/5/

14
  • 17
    The comments in the first link are interesting: It shows that Microsoft deliberately included a “bad app” so as to sabotage the OS/2 demonstrations Technically, the "bad app" is something that I'd expect a good QA engineer to implement, to provide a solid example of how the OS designers had screwed up. OK, so it was a bit aggressive to run it at trade shows rather than filing a critical bug report, but on the other hand, as a software designer, I'd say your defence against being embarrassed is to not screw up so badly.
    – dave
    Commented Dec 30, 2020 at 23:31
  • 8
    The Synchronous Input Queue does seem to have been the Achilles heel of OS/2 Warp. It was apparently fixed in Warp 4, but by then Win95 was well established and OS/2's reputation had been thoroughly tanked.
    – Chromatix
    Commented Dec 31, 2020 at 2:57
  • 18
    And ironically, in 2020 Windows 10 still has the same problem - a full-screen game can lock up and get stuck in the foreground. You can still start Task Manager, but Windows 10 handles that as "just another program" so it doesn't get shown when there's a full-screen game running. Alt-Tab shows the preview, but you can't interact with it due to the frozen game, and therefore you can't kill the game. The fundamental problem is the same: both OS'es forgot that the chief task of an OS is to give the user the ability to manage programs. To start them, but also to stop them.
    – MSalters
    Commented Dec 31, 2020 at 12:08
  • 1
    OK, so to be clear, Microsoft's "bad app" or terminator disk crashed OS/2 by corrupting other applications. I haven't seen anything suggesting that the bad app relied on the SIQ flaw to crash OS/2. Commented Dec 31, 2020 at 20:00
  • 3
    Ironically, Windows 95 had an almost identical flaw to the synchronous queue issue. Windows 95's GDI (responsible for all graphics at a low level) was pretty much the same as Windows 3.1. It was 16 bit code and it was never designed to be thread safe. So Microsoft created a semaphore which applications had to grab to do graphics. If process hung whilst in control of the semaphore, every other process would block as soon as it wanted to do graphics. The machine would appear frozen, but then spring to life, if the process with the semaphore died or was killed somehow.
    – JeremyP
    Commented Jan 2, 2021 at 15:55
5

Is there any source beside your memory for this or a similar claim? It would be helpful to see a first hand source supporting that IBM made it, like an advertisement or some promotional matter or manual or a lake. The cited PC Magazine posting seems as well rather based on memory.

Also, the cited OS/2 Warp box clearly mentions Crash-Protection as a function to isolate single processes from crashing the whole system. Something that was almost the default behaviour on Windows prior to NT.

While being an OS/2 developer (and user) since 1.2 (but only really felt in love with 2.0), I do not remember any claim for it being 'crashproof'. And it seems rather dubious that IBM would have changed that somehow along the way.

Now, having mentioned OS/2 Version 2.0, it did come with an advertising campaign using the claim of being

"a better DOS than DOS and a better Windows than Windows"

Was it maybe this line that got stuck in your memory?

OS/2 was in fact way more stable than any DOS/Windows of the same time - and years to follow. Mostly due its use of 286/386 protection mechanics to really separate processes while providing safe(r) interfaces than DOS/Windows.

3
  • 3
    See my edit, and I'm also not the only person with this recollection: groups.google.com/g/comp.os.os2.misc/c/9nJyzFT2fhE/m/… Commented Dec 30, 2020 at 20:56
  • 1
    Not saying it didn't happen, would just love to see some serious proof.
    – Raffzahn
    Commented Dec 30, 2020 at 21:04
  • No less a reference than Encyclopedia Britannica reports "With OS/2.20 the WorkPlace Shell was created and became a GUI standard, and future OS/2 iterations ran Windows with a reliability that led IBM to label the system “crash proof.”" britannica.com/technology/IBM-OS-2 Commented Jan 1, 2021 at 23:04

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .