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?

  • 4
    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. Dec 30, 2020 at 20:43
  • 1
    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
    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". 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
    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. Jan 1, 2021 at 6:53

3 Answers 3


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.


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.


  • 15
    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. Dec 30, 2020 at 23:31
  • 7
    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
    Dec 31, 2020 at 2:57
  • 16
    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
    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. Dec 31, 2020 at 20:00
  • 1
    @MSalters That always feels more like bad window management of hung fullscreen apps to me. You can bring the taskbar to foreground, and with extension programs, make the task manager "top most" and it will stay visible above the app. What was more similar to the OS/2 issue was the then-newly introduced DWM in Vista being capable of being locked up by frozen apps utilizing its features in some scenario I forgot, which was apparently fixed in SP1. Wish I remembered the sources to that...
    – Ray
    Jan 1, 2021 at 14:59

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 sort of memory manager (e.g., 386Max). In this case, MS-DOS was technically running on a V86 process, and the processor itself was actually 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).

  • 1
    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. 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. Dec 31, 2020 at 14:30

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 Magazin 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 seams 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(er) interfaces than DOS/Windows.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.