Did any MS-DOS program ever use the System Request interrupt?

Question

As I remember, the SysRq key generated a special, unique interrupt (not an ordinary keyboard interrupt). It was supposed to let the user interrupt any process in a multitasking situation and return control to a special handler in the system. But, as far as I know, no one ever used it.

It seems like it would have been a great interrupt to hook if you wanted to interrupt a hung program. Early DOS days had no Windows Task Manager. It could also be intercepted by a long process to report the status of the process. I used something similar on a mainframe that processed a huge number of records and ran for hours.

It could be used to swap execution contexts, like in the GEM operating system. But I don't believe anyone ever used it for anything.

Is that true? It seems like an incredible waste.

Answer 1

TL;DR: One of the great Ideas that never Materialized

Contrary to what is often assumed, the key was not added to support some 3270-style emulation(*1), but to enable a basic multi application/OS environment where DOS may be only one of several applications. Support for that was added with the AT, but it never came to be.

---

As I remember, the SysRq key generated a special, unique interrupt (not an ordinary keyboard interrupt).

Kind of. When pressed, the keyboard will issue a hardware IRQ 1 just like for any other key. IRQ 1 is routed to INT 09h, which handles all keyboard input. With an AT BIOS (or later), the BIOS handler will call INT 15h(*2) function 85h if SysRq is pressed or released.

• Sub-function 0 is called when SysRq is pressed.
• Sub-function 1 is called when SysRq is released.

It was supposed to let the user interrupt any process in a multitasking situation and return control to a special handler in the system.

Jup, SysRq was intended as part of a set of functions to enable creation of a bare metal hypervisor, intended to run multiple OSes at once and in parallel.

But, as far as I know, no one ever used it.

Yes and no. The development version of OS/2 used SysRq to bring up a very primitive (*3) task manager. The first customer release changed the name to OS/2 1.0 and its keystroke to Ctrl+Esc(*4).

I used something similar on a mainframe that processed a huge number of records and ran for hours.

That was exactly the idea behind addition of these services.

It seems like a incredible waste

It was originally intended to be used with OS/2, but that changed from being a simple multi-tasking system to a more ambiguous one.

DOS 4.0 in turn used a complete different structure⁵.

---

*1 - The 3270 knew more than one single-key message, so adding only one key wouldn't help much. Even less is there a need to add a special interrupt service for only one, since the application gets all keys anyway.

Both the 3270 PC and the 3270 AT used their own large keyboard with more than a dozen additional keys. To handle this, an additional ISA card was used, to which the keyboard was connected via a special cable. It handled the additional keys as well as a loop thru mode to use the keyboard as well for regular PC usage.

*2 - Int 15h originally handled cassette I/O (function 0-3h). The new AT functions, called "Extended AT Services", were added with function numbers starting at 80h. Those included basic functionality for extended memory support (access of memory above 1 MiB for real-mode programs), but also basic services needed for a hypervisor to manage multiple OSes in parallel. SysRq handling was one of those services, intended to be used to switch to the hypervisor's user interface.

The main idea of those functions was to offer a very basic set of communication interfaces to share resources (devices, memory, and processing time) between otherwise independent OS instances. One of them -handling the sharing - much like back in the 1960s with CP/CMS on /360 mainframes. It consisted of the Hypervisor CP-40 and the CMS OS running as one of its guest OS.

*3 - It was just a list of running applications. Only the names; no other information. All it could do was switch.

*4 - It is interesting that one of the names, before IBM and MS settled for OS/2, was CP/DOS, quite an obvious reference to CP/CMS.

*5 - DOS 4 is what Microsoft developed as a multitasking followup to DOS 3, continuing a soft switchover to Xenix. When Microsoft joined IBM with their OS/2 approach, all of that got dumped.

Answer 2

The SysRq key is a perfectly normal key on the keyboard.

It does not generate a special or unique interrupt by itself.

The standard keyboard interrupt of BIOS just does what it does for all keys and reacts accordingly, and for the SysRq key, it simply calls INT 15h with AH=85h.

So not any different from Print Screen key where BIOS calls INT 5h or Ctrl-Break sequence where BIOS calls INT 1Bh.

So if a DOS program is hung, it is hung. The system cannot return to DOS from a game or program that has already gone haywire and the only thing left to try is to reboot with Ctrl-Alt-Del, if it even works any more.

The intention for SysRq key was originally supposed to be used on 286 PCs which had protected mode that allows isolation of say Unix kernel from programs and thus bring up a console to kill the hung program.

Apparently some debuggers used it as triggering a TSR and Linux can be configured to use it.

Answer 3

The DOS version of the SoftICE debugger allowed the use of the SysRq key to pop up the debugger UI.

The VM/386 system allowed up to 99 virtual DOS machines to run simultaneously using a single copy of MS-DOS, and the SysRq key brought up a hypervisor-style menu.

Answer 4

It's not implemented like you might think. It's like an arrow key or page up/down. These keys have an os-wide defined use which can be overridden in a command line app. You can also define SysRq as a well-known command in your app or some sort of Easter egg. So there is no telling if it was used in DOS apps at all.

Many Unix/Linux kernels support the SysRq magic keys and you can use the SysRq key the same way you might use any other key on the keyboard. The Google Pixel 7 shipped with these features enabled, as a recent commercial example.

However it's use extends into modern day Linux. By enabling certain flags in the kernel build, you can use it to hard reboot by using a magic key sequence+b(alt+sysrq+b), kill all processes except init with magic+I, or cause a kernel panic with magic+c. These are useful for debugging and empirical security feature testing.