Why did some old MS-DOS games lack the ability to exit them?

Question

While playing around in DOSBox-X, I'm reminded of some DOS games which appear to entirely lack the ability to exit/quit/close them.

One prime example of that is "Paratrooper" from 1982. I've tried every key on the keyboard, including Alt+F4. Nothing makes the damn thing close. I have to kill the entire emulator to make it go away. Is this really how it was designed? If so, why?

All the sane DOS games either allow you to just press Escape to instantly get dumped back to the DOS prompt (oftentimes with a snarky remark about how boring it is and how you should continue playing the fun game instead), or at least allow for exiting the game through its menu system.

But Paratrooper does not. And it's not the only one. It's also not even an EXE, but a COM. Is this somehow related to its inability to exit?

Answer 1

Paratrooper was originally a “PC booter”. All PC booters run without DOS or any other operating system¹ — to start them, you would insert the floppy into the drive, and switch the computer on (or reboot it). There was nothing for such a game to exit to — once you’d finished playing, you’d switch the computer off, or reboot it from a different floppy (or from the hard drive, if you had one). As pointed out by ssokolow, this is similar to how many other micros were used at the time, and continued for a long time on home computers such as the Atari ST.

In most cases, people converting PC booters to DOS executables wouldn’t add an exit feature — it would likely have been quite complex to do so. “Ripping” a booter to an executable already involves making a number of changes in many cases: some PC booters were copy-protected, so that has to be defeated, and many would write to their floppy, which also would have to be disabled (or re-implemented). As Jim Nelson explained in a comment, rebooting wasn’t at all unusual in DOS days², so adding an exit feature wouldn’t have been high on anyone’s to-do list!

However, Paratrooper is well-behaved — it doesn’t overwrite anything it shouldn’t —, so you can add an exit feature to the game yourself: download HBREAK, and run it before you run the game. Pressing CtrlAltC (followed by Enter in some environments) will return you to the DOS prompt. This works fine in DOSBox and DOSBox-X.

You can also exit the game if you use an image of the original booter version, instead of the DOS conversion: there’s a piece of software, Flopper, which can “boot” booter games on top of DOS, and it allows you to exit back to DOS. If you’re interested in how it goes about this, it comes with extensive documentation and complete source code.

The reference for PC booters was Retrograde Station; the site disappeared long ago, but most of it is archived, including many images of games.

Another project to look at if you’re interested in booter games is Digger; this is a remaster of a booter game, and its documentation includes various titbits about booters in general.

As far as the executable extension (.COM or .EXE) goes, it doesn’t have any impact on whether the program can exit or not. The extension itself doesn’t distinguish between executable formats, but booters do tend to be ripped as binary images rather than MZ-type executables: whichever technique is used to dump the executable, it’s easier to store it as a headerless binary than work out the MZ header. Most booter games are small so they wouldn’t run into the size limits associated with the format either.

---

¹ Games don’t need much in the way of operating system services, and everything needed by typical DOS games of the era, other than file access, was provided by the BIOS and easily re-implemented with direct hardware access anyway. File access wasn’t important in the days of floppy disks — booter games would “own” their disk, so they didn’t have to care about files, and any disk access they cared about (e.g. to store a high-score table) could be done through the BIOS or by directly programming the floppy-disk controller.

² So much so that later versions of QEMM even implemented a “fast reboot” feature — it allowed DOS to be rebooted without actually resetting the computer and going through the system’s POST again.

Answer 2

If a program hooks or disables all interrupts, and never invokes any DOS or BIOS functions, it may use all of RAM following the last enabled interrupt vector (typically the keyboard vector at address 0x00024-0x00027) in whatever manner it sees fit, without regard for what portions of RAM might have been reserved for use by DOS or BIOS functions. If a game included the ability to exit, it would need to determine what areas of memory DOS or the BIOS might be using and ensure that it doesn't disturb them. If there is no way of exiting other than to reboot, then the amount of memory available to the game will be greater, and the game won't have to worry about the possibility that a machine might have enough memory to meet the game's requirements but some of it is reserved.

Answer 3

Back then, the operating system was much less powerful than you are used to today.

MS-DOS was a disk operating system. It primarily took care of the disk (floppy disks, mostly), including reading, writing and executing files, and handling directory structures. Sure, it had a few other functions which would wrap around lower level features of the system, but not too many. It did provide the command line interface and a lot of individual small programs - e.g. to copy files and such - but those aspects are irrelevant for the question at hand as a game would use none of those.

The other important system component back then was the BIOS (basic input output system) which an application could use for, well, text input and output - if the application had no particular performance requirements and preferred an easier API instead of low level access to the devices. BIOS text processing incurred a very much noticeable performance overhead, and generally limited what you can do a lot.

Especially iIn the later days of the 286, 386, 486 and with the advent of more memory, when paging or memory virtualization became more frequently necessary, there were added subcomponents for memory handling, which could be started or configured separately (see Upper Memory Area or DOS Memory Management for nice overviews and links to more information).

Aside from these system components, many programs, and certainly most if not all graphically intensive games, talked to the hardware directly. They had direct control over all aspects of the screen (including intricate timings in the phases where the electron beam moved back between lines, or from the bottom to top border), and the keyboard. Sometimes even direct or low-level access to the floppy drive (bypassing DOS), for copyright protection purposes. There was no preemptive multitasking like in every general purpose OS today - there simply was no "power" in the system which could influence the running program that much.

Speaking of which, there was always one running program. It would even be far-fetched to call it "process" in our modern meaning; there were none of the features we associate with processes today (priority, time scheduling, ownership of particular resources, separate user/kernel-level permissions etc.), although DOS did keep track of some of the resources and could reserve them for programs loaded at the same time...

... to be used, amongst others, for a type of application called TSR ("terminate and stay resident programs"), which meant that you could start small utilities which would stick around, and would usually intercept keyboard interrupts - so they could do some action on the press of a button, even if another program was currently active. This worked, mostly, but usually not very usefully while in a game which did fancy stuff with the screen. There was no way for a TSR to sanely take control, modify the screen, and restore everything to the previous setting. Of course one could try, but it was always a hack, nothing at all like today. There were no system-level video drivers which could do the state recovery, and so on.

If a program exited on ESC, that was purely a convention. Alt-F4 or other standard key combinations did not exist. Figuring out which keys a game used at all was always part of the fun, especially if you had a decentralized backup copy of a game without the manual...

Answer 4

One possible explanation could be: because the game has corrupted or leaked the memory or resources (video modes, sounds) and you'd need a reboot to get back the system in a clean state anyway, so better not give a false hope to the user.

It's not as easy as it seems to cleanly exit from a program, specially on old OSes.

Answer 5

Because reset times were negligible

Having to reset the PC is only an issue if the PC takes a long time to boot afterwards.

Assuming you had the memory check turned off in your BIOS, the time from powering on your PC to the DOS shell running was single-digit seconds. There really wasn't any inconvenience to it.

Answer 6

I don't know to which games this might apply, but I'm sure that some programmers simply did not consider an exit feature to be important. Back in the early DOS days, your program may not have been the product of a team, but the output of a single programmer with an idea. Some were self-taught and had not programmed long enough to recognize that some of their users would expect a clean exit. Even if they did recognize this, if it was not an important program feature for their own taste, why would they bother? They got this neat thing they want to share and maybe make a buck, so get it out there!