Why weren't bootable game disks ever common on the IBM PC?

Question

While for other platforms of that era (primarily, Amiga), putting a game on a bootable disk was quite a normal practice, this approach never taken off on IBM PC. Why not?

I do remember people having multiple menu-driven autoexec.bat and config.sys configurations because one would have to boot MS-DOS with only the bare minimum to satisfy the requirements of some memory-demanding games. Since MS-DOS was by and large a single-task operating system, wouldn't booting a game directly from disk be more efficient than going through all the hassle of finding a working configuration of HIMEM, EMM386 and whatever else?

Even when Windows took over, would there be benefits for a demanding game to have full control over the PC resources as opposed to competing with a multitude of random background processes potentially spoiling the smooth FPS?

I understand that games in such a scenario would have to include a minimalist operating system, but I guess a carefully tuned Linux kernel along with drivers for all the popular graphics cards would be enough? This is for the Windows era, that is - for MS-DOS, I guess all the essentials games of that time needed were available directly from BIOS (well, file system support could have been an issue but I recall Amiga games of that time used to read the game data directly from sectors on the disk).

Answer 1

There were three primary reasons:

1. Space - PC games were at an awkward juncture in time where both the OS and the games had grown but floppy disks had not, so there was often too little space on the disk to include the OS, even for single-disk games, let alone multi-disk games.

2. License - They couldn’t just throw a copy of DOS on the disk; that would be piracy. They'd have to have a license to include it, but that would have increased the price of the games which were often already quite expensive.

3. Variation

   Apologies if I was vague in my wording. Take Doom, Heretic or Hexen as an example. These games were using a so called "DOS extender" which, in a way, was a mini-kernel running in protected mode that didn't rely on MS-DOS for anything but probably accessing the file system. So, assuming that a game like this a) would be able to boot from CD by using only BIOS routines and b) would include a FAT driver for making "saves" on the HDD - such a game wouldn't need MS-DOS at all. Ideally it wouldn't even use BIOS since calling BIOS from protected mode was royal pain in the ... – DmytroL

   Games that required DOS extenders did come with them. It sounds like you’re asking why PC games didn't include their own (mini) OS, as opposed to running on DOS at all. If so, I assume you’re referring to how some Amiga games had custom boot-blocks that bypassed Kickstart and didn’t use AmigaOS. That was because doing things like graphics, sound, and input was simple enough on the Amiga that they could do that. However, it was not a common practice, it was usually only done by “bedroom-coders” who enjoyed digging into the system and “hacking” things for themselves. Studio games rarely did that unless there was a pressing need like squeezing out every byte of disk space.

   On PCs, it was more of a pain to do low-level things manually, so it was rarely worth the effort (though it did occasionally happen; it's not a game, but even today, “DOS” copies of MemTest86+ come in a non-FAT disk image and boot directly into the program using a custom version of Linux, as does Clonezilla).

   A big reason for programming on PCs being harder than on Amigas, C64s, game consoles, etc. is that unlike original IBMs and other systems that had a defined specification, PCs (IBM clones) quickly became a morass of complexity with a wide variation of hardware. Therefore, it was a lot more work (especially before each standard was established) to accommodate differing hardware; it was easier to just let the installed operating system and drivers do that work. (This was still an issue even in Windows until Microsoft unified the programming experience with DirectX.)

Answer 2

Bootable game disks do exist for the IBM PC. Conflict in Vietnam is an example of such a game. As can be seen on page 8 of the manual, the game boots directly without loading DOS first.

The main reason it wasn't common was for compatibility. A self booting game has to have its own drivers for all the hardware it wants to support. As PCs quickly diversified and software was used to provide compatibility with the original IBM hardware, it became much easier to use DOS drivers instead. In comparison the Amiga hardware was largely fixed and compatible through it's entire commercial lifespan under Commodore, and no clones ever gained significant market share.

Answer 3

Well there were some PC booter titles (MobyGames lists 249), but most of these were quite early games, even before hard drives, XMS or EMS even existed. These were almost always self contained single floppy games, that could run on the very specific hardware that existed. All they used was BIOS for disk access. Also DOS was not the only operating system, so it sort of made sense to have a simple booter game that could be booted from a single floppy, without a specific OS. As the game itself does not require DOS for anything, it would have taken too much floppy space to include DOS just for the purpose of loading a game.

When games became larger and hard drives mainstream, and in practice the consumer OS had settled to DOS, it was much simpler to boot the PC to DOS as usual and then run the game executables either from floppy directly or from the hard drive. Also games that have multiple files like graphics and sound files can just very easily read those files under DOS, without understanding anything about the actual file system structures.

Even later, with 386 and 32-bit protected mode games, DOS was just used as the platform that was able to execute the DOS extender and load the 32-bit game executable into memory for the purpose of running it.

Answer 4

The IBM PC was NOT a Game Machine

Plenty of people played plenty of games on IBM & compatible computers. But the IBM PC was designed as a business machine, not a game machine.

This is most obvious with audio capabilities. Where Atari 400/800, VIC-20, Commodore 64, Amiga and many other machines of the era included some (for the time) serious sound capabilities, the IBM PC did not. As a result, within a short amount of time, there were a number of different sound cards available, each of which needed a driver or specific application programming to work.

Video was not quite as bad, but even there, the original PC had a choice of two very different video cards (MDA & CGA) and soon EGA and others came along, each with their own video modes (bit depth, resolution, memory-mapped video RAM location, etc.), while many of the other popular machines had video, often with better support for games (e.g., sprites), built in to the motherboard.

Due to the sheer size of the market, there were many games available for the IBM PC. But due to design issues, many of these games needed either extra hardware (e.g., sound card) or extra software (to support different sound, video, extended/expanded memory), all of which was a lot easier to support by booting into MS/PC-DOS first. In addition, hard drives were quite common with the IBM PC (at least after the introduction of the XT), so installation of a game onto the hard drive, sometimes with insertion of the original floppy at the beginning of the game for copy protection, made a lot more sense than trying to cram everything into one or two bootable floppy disks.

Answer 5

Games that were designed to be run from floppy were usually self-booting, and often could only be run by booting from floppy. In many cases, the game code could be stored in ways that would not be understood by MS-DOS (using things like non-standard sector sizes), and booting into a game would be faster than booting MS-DOS and then booting the game. The big problem was that a self-booting game would be generally be able to access anything that required any sort of loadable device driver, nor--in most cases--any information that was stored on a normal MS-DOS disk. If one wanted to save one's progress in Zork I or Wizardry, one would have to format a disk specifically for that purpose, as opposed to merely being able to store a file on an existing MS-DOS volume [I think Wizardry used disks formatted to the UCSD P-system standard, and its save files might have been able to co-exist with files for other P-system applications, but Wizardry is the only one I know of].

Note that if a game knows that it will need to use a certain specific set of files, it can simply have a list of files and their locations built into the game's code. If a game were using MS-DOS and wanted to read foo.dat, it would need to read one or more sectors of directory information, then one or more sectors of the FAT, before finally being able to read the data for the file of interest. If instead the game code is hard-coded table that says file #23 is stored from sectors 293 to 299, the code can simply read those sectors directly, thus offering faster performance than if the game were using DOS to read the information from floppy (though probably slower than using DOS to read from a hard drive).

Answer 6

Your question is backwards, the Amiga and Atari ST were really the only computers that had mainly bootable games on floppy, pretty much every other disk-based PC required you to boot into the OS first, then boot your game. There are a very small number of exceptions on the PC, but they are rare.

The simple answer is that the Amiga and ST had part of their OS stored on ROM, for the Amiga this was named a "Kickstart" ROM and this could be updated or flashed with new versions. This was effectively "DOS" for the Amiga, and it was built into every machine. You could load the more fleshed-out "Workbench" from floppy or HDD, but Kickstart was always loaded when the machine turned on.

If a game wanted to be self-booting on the Amiga, all they needed to do was issue a few Kickstart commands and you would be ready to go.

If a game wanted to be self-booting on the PC, there was no built-in OS, just some very high-level BIOS commands as standard. The game would have to have an entire kernel and OS included, and you couldn't just distribute DOS with your game. So unless you wanted to code an entire IBM PC kernel and OS (which was far more possible in the early days when there was only three types of CPU, two types of graphics adapter and one type of sound hardware), then you would have to rely on the user to already have DOS.

Answer 7

I'd like to question the premise, here.

I understand that games in such a scenario would have to include a minimalistic operating system, but I guess a carefully tuned Linux kernel along with drivers for all the popular graphics cards would be enough?

Space is an issue, so it would be beneficial if it were possible to have the kernels separately, or else have multiple different copies of the game with different sets of drivers. The "separate kernel" model seems more efficient, and what is DOS if not this?

Now, even when Windows took over, would there be benefits for a demanding game to have full control over the PC resources as opposed to competing with a multitude of random background processes potentially spoiling the smooth FPS?

There is a convenience in being able to start your games quickly, and to Alt-Tab, and to use the network you've already configured your computer to use, etcetera. And computers powerful enough to run Windows were often powerful enough to run most games without stuttering, especially since Windows gave priority to the programs the user was interacting with.

Nevertheless, many games on my Arcade ClassiX CD-ROM required me to boot into single-process (MS-DOS) mode in order to run properly; it appears that such games existed. It wouldn't surprise me if such bootable disks as you describe in your question also existed. But such launch systems reduce the target audience with very little benefit, so I wouldn't expect many to exist.

Answer 8

1. Floppy disks were extremely unreliable. As a consumer, if I knew a game would only be usable by booting from it's own floppy disk, I'd be immediately turned off on buying that game because I know that sooner or later, that floppy disk is going to be rubbed raw by the floppy drive's read heads and turned into rubbish. Then I'll be out of my money and without my game. Even if the bootable game didn't employ copy protection schemes (which most bootable games did), I'd still be out the cost of a replacement floppy disk.

   Hard drives, while still a bit unreliable back then, were significantly better.

2. Self booting means you don't have access to any of the FAT filesystem code in DOS. That means you can't safely access the hard disk. In fact, you couldn't even use many of the standard C library routines. You'd have to make BIOS calls yourself and try accessing the raw disk directly, which is pretty impractical. Tiny games could be contained within the size limitations of a floppy so that using raw BIOS reads (without a filesystem) might be manageable, but beyond that it was so much more reasonable to just simply require DOS.

3. Booting was really slow in the old days. Many BIOS's would do a Power On Self Test procedure that would take way too long. Imagine trying to develop a game where you had to reboot to test each iteration of your code? Pretty impractical. So, most programs were developed under DOS where you could switch back and forth between testing your code and running your development environment pretty quickly. Your game was by default already DOS compatible at this point, so making it into a self-booting image meant you had to do MORE development before you could release. Waste of time for most people, other than those bent on implementing copy protection schemes.

4. Incompatibility. The IBM PC was largely popular because there were so many competing vendors producing different, yet still mostly compatible clones of each other's hardware, driving down costs of computers. The problem is, you often needed software to, at the very least, initialize the hardware into a state of compatibility at boot time. Or in the case of Mice and CD-ROM drives, you needed a terminate and stay resident driver that knew how to talk the proprietary hardware protocols, while providing a generic API for applications. Making a self booting game meant that your game very likely would have compatibility problems for many of your otherwise potential users.

Answer 9

Firstly, it's not true. There were many bootable games for DOS. The most popular answer here names a bootable DOS game, then goes on to explain why they might not be as popular(?) Perhaps your question makes sense for the original IBM PC. That brings up another distorting variable; PCs have been around since 1981, and today's PCs are direct descendants. In comparison Amiga was only made by Commodore from 1985 to '96.There were many features later PCs and "clones" had that the original PC and PC XT didn't have, but by 1986, Compaq had put out the first 386 desktop PC, the Deskpro. If your friend had a PC that was as new as your Amiga, a PC which would probably have been running Windows 3.1 on a hard drive, you would have a very different experience. Also, making a floppy disk bootable in DOS was as simple as, "sys a:". This would put a boot sector, and a "DOS BIOS" (IO.SYS) file and a DOS kernel (MSDOS.SYS), on the disk. (IBM renamed these to IBMBIO.COM and IBMDOS.COM.) It's a rather trivial operation, and it's no wonder over 200 major games included this feature, and probably a number of homebrew games as well. There's also the fact that two floppy drives became vary popular soon after the IBM PC came out. The first successful "clone", the Compaq Portable had two floppy drives. The Apple IIe was also commonly bought with two drives, but not the Amiga. For most non-business purposes, the DOS disk was kept in one drive (A: or B:), and games and other applications in the second drive. Even if the game was bootable, it was common to run it after the DOS disk was already present and booted. This might be what distorts your memory of PCs.