49

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?

9
  • 41
    It should be mentioned that in that time period, rebooting and power-cycling a microcomputer throughout the day was expected. Many of the machines had a prominent RESET button on their keyboard for that very reason.
    – Jim Nelson
    Aug 26 at 18:23
  • 4
    "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?" No, it isn't. Besides you should really look at the file magic to determine whether it is an MZ executable or a flat .COM-style executable. That's what DOS does. It allows either filename extension for either type of executable. Only the presence of either an "MZ" or "ZM" signature (both work) indicates a non-flat executable.
    – ecm
    Aug 26 at 18:39
  • 15
    This is not specific to MS-DOS either; Commodore 64 games and ZX Spectrum are also like that. Just take control over the whole machine, and you can forget the operating system even exists.
    – OmarL
    Aug 27 at 7:36
  • 4
    This is also how console gaming platforms worked for a long time. Insert game, start console, then turn the console off or reset it with a different game inside.
    – Taejang
    Aug 27 at 13:29
  • 10
    Alt+F4 was never a shortcut in DOS - it first arrived in Windows (at least since 3.1)
    – Melllvar
    Aug 27 at 22:15
120

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. 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.

3
  • Comments are not for extended discussion; this conversation has been moved to chat.
    – Chenmunka
    Aug 27 at 20:23
  • On machines like the TRS-80 and original Mac, having a game boot from disk was often an extra layer of copy protection. There was no operating system and therefore the data on the disk was not formatted as any publicly documented file system. Aug 29 at 1:17
  • 6
    In a sense, a booter is an operating system. An operating system that does nothing but play the one game. Aug 29 at 3:00
25

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.

6
  • 1
    Wasn't much of the upper memory area including the memory in which the BIOS resided read-only? The video memory obviously could be written as well, but I'm pretty sure that at least the BIOS area could never be used and overwritten by any program. That was at least one reason why the 640k limit was so hard to overcome.
    – Schmuddi
    Aug 27 at 6:49
  • 1
    @Schmuddi the BIOS uses RAM as well, the BIOS data area, e.g. for the keyboard buffer. Aug 27 at 9:15
  • 3
    @StephenKitt: If the game takes over all interrupts and doesn't chain to any of the BIOS routines, no BIOS code will get to execute until the system is rebooted.
    – supercat
    Aug 27 at 14:32
  • 3
    @StephenKitt: Many of these games wouldn't plan on using anything past the first 128K-256K. If one wanted to a game to run on a 128K system, leaving DOS in memory would cut substantially into the amount of memory available for the game.
    – supercat
    Aug 27 at 14:33
  • 2
    @supercat and Paratrooper was designed for PCs with only 48K of RAM (which reinforces your point) — see mobygames.com/game/pc-booter/paratrooper/cover-art/… Aug 27 at 14:39
12

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...

6
  • 1
    Do you have any examples of “complicated and incompatible subcomponents for memory handling, which could be started or configured separately from both DOS and BIOS”? Also, while processes under DOS did mean much less than in current, multi-tasking OSs, there was process ownership of particular resources. And your last paragraph is incorrect, see HBREAK in my answer. Aug 27 at 9:03
  • 1
    Thanks @StephenKitt, I have integrated your points.
    – AnoE
    Aug 27 at 9:14
  • 4
    Hah, I've not heard the euphemism "decentralized backup copy" before, but have fond memories of racing to guess the controls for a flight simulator (from which the startup screen had been removed) before the plane crashed.
    – IMSoP
    Aug 27 at 10:42
  • 1
    The restriction in your latest edit, “... to be used for a type of application called TSR”, isn’t warranted: resource ownership was also useful for programs running other programs, starting with COMMAND.COM ;-). It’s mostly based around the PSP, used for example in MCBs. This is how service 0x4C could find the memory to free and files to close on program exit. Sep 1 at 8:54
  • 1
    @StephenKitt, this answer is going to be a reference documentation for DOS. :) I've defused my previous edit with a further one.
    – AnoE
    Sep 1 at 11:06
6

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.

3
  • 3
    As this was a booter game, it basically was the OS. Just like you can't quit the DOS operating system and warm boot into same or another OS because there is no need to do that, there is also no need to exit from a game booted to run without OS.
    – Justme
    Aug 26 at 18:19
  • 1
    @Justme You actually can ‘quit’ DOS, in a way: you can enter DEBUG and invoke interrupt 0x18/0x19, or launch a boot loader of another OS that supports being run from within DOS (like GRUB4DOS or LOADLIN). I seem to recall there is even some code in the DOS kernel itself to support doing the former. Aug 26 at 19:43
  • 1
    @user3840170 You can invoke the bootstrap int 19h, but it is not a preferred reboot method - generally it would not know about how to shut down DOS or anything running below it gracefully. A loader for another OS like Linux that is run from DOS would generally understand enough about DOS and the hardware to disable interrupts and relocate itself to somewhere so Linux kernel can be safely loaded and executed. Some memory managers and disk caches can hook int 19h to get a warning to shut themselves down gracefully, like flush caches to disk.
    – Justme
    Aug 26 at 20:30
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.

3
  • 2
    Somewhat agree. Reset times were certainly shorter for most home micros at the time (e.g. Apple II reset was sub-second), but the original IBM PC and frankly many PCs through the late 1980s did a memory test which took 5-20 seconds depending on how much memory you had installed. That being said, some games would let the Ctrl-Alt-Del reset work to get out which may avoid the memory check, but I seem to remember at least a few games that you needed to physically power cycle the machine which would cause the check to happen.
    – bjb
    Aug 27 at 12:45
  • PC's power-on test was really annoyingly long. An interesting feature I learned about a few years ago, though, which really surprised me is that the BIOS looks for a special diagnostic code from the keyboard connector and can be made to skip launch code supplied via the keyboard port if the diagnostic code is received. Since the BIOS was published, I find it interesting that nobody designed and built a fast-boot gizmo that daisy-chained into the keyboard port.
    – supercat
    Aug 27 at 17:03
  • 2
    Another reason why rebooting is more of an issue on modern computers is that you're likely to have other programs running simultaneously and a reboot would interfere with whatever they are/were doing. With a single-tasking OS, that problem wouldn't come up (TSR's notwithstanding) Aug 29 at 19:33
0

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!

4
  • 3
    I imagine it's probably easier to make a game if you're able to quit out of it and change things.
    – knol
    Aug 27 at 15:42
  • 2
    and being able to quit is also important for debugging
    – phuclv
    Aug 29 at 10:24
  • @knol and phucly, In a case where the programmer is writing a self-booting program that self-boots, bypassing DOS, then including a clean exit would be tantamount to a reboot anyway. Assuming the development system had a hard drive, reboot time to DOS would be short. A reason to do this is if you were targeting a small system with just 64k or 128k of RAM. You might also be using a development system that makes target builds for a different machine, but would still provide debug hooks.
    – RichF
    Sep 1 at 1:23
  • 2
    @phuclv and Knol, Even if your development machine has sufficent RAM for DOS, the development environment, and your game, the low-end machines you plan to support may not.
    – RichF
    Sep 1 at 1:35

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.