Serious question from back in my young impressionable days of What Even Is This Square Thing Anyway:

I once wanted to copy/record the layout of a particular PC's boot up sequence, and (without a camera) got the great idea (uh oh) to use the Pause key while staring at the BIOS screen.

I think... I think it worked too well.

Once I'd copied the layout onto paper and hit a key to un-pause the system, it started behaving... very weirdly. I don't remember exactly what it did, but I do remember getting really freaked out because something was very wrong.

What I do remember was playing a game (to test/see if the system would settle back down) and, as time went on, keyboard input became progressively less and less responsive and erratic, and the system started beeping like crazy, almost like the keyboard input buffer had indigestion.

IIRC, the machine hung shortly thereafter and would not turn back on (read: initialize video and POST). O.o

To this day I still wonder what happened to that poor box, and a part of me wants to buy another AT&T Globalist 515 and film it to see if the fault(?) wasn't specific to my machine and maybe figure out exactly what happened.

My initial theory was flash corruption; it's also possible I overheated the CPU, especially given the lack of a heatsink, but it was a 486DX2-66, which didn't need a heatsink, and I'd used the Pause key in DOS plenty of times prior with no issues.

Your application crashes. DOS does not.

Amen! I never had a problem that wasn't bad hardware or my fault. All MS-DOS did was manage the disk, and keep track of time. There wasn't much to go wrong.

I guess you never wrote DOS applications, nor used it on its prime days.

I did; I mean that if the system crashes it's your application's fault, not DOS's.

How can you prove that?

I suspect that they're alluding to the fact that DOS was more of a program loader than an OS and that once it loaded your program it was your program that was in the driver's seat. BUT there are subtle issues with drivers and networking still.

I know that, but unless you can 100% guarantee that the application was clean from any kind of DOS interrupt calls, there are zero guarantees that it wasn't DOS, one of the drivers or the pseudo multitasking TSRs that were the culprit, there is no way to assert that the application was the one at fault.

DOS was simple enough that it can be considered essentially bug free. And in an embedded setting there are not going to be TSRs (you just boot directly into the application) and probably no DOS calls during the runtime. You would only use disks for special operations such as software updates.

Ah such a lucky one, never crashing DOS code, I guess you never used MS-DOS 4, nor had the experience of porting code across PC-DOS, MS-DOS and DR-DOS.

Some DOS versions were better than others. But often the cause was non portable code on the applications. That wouldn't apply if the DOS version is frozen.