Terminate and Stay Resident - Faults

Faults

While very useful, or even essential to overcome DOS's limitations, TSR programs had a reputation as troublemakers. Many of the programs effectively hijacked the operating system in varying documented or undocumented ways, often causing systems to crash on their activation or deactivation when used with particular application programs or other TSRs. As explained above, some viruses were coded as TSRs, and were deliberately troublesome. Additionally, all program code in DOS systems, even those with large amounts of physical RAM, had to be loaded into the first 640 KB of RAM (the conventional memory). TSRs were no exception, and took chunks from that 640 KB that were thus unavailable to application programs. This meant that writing a TSR was a challenge of achieving the smallest possible size for it, and checking it for compatibility with a lot of software products from different vendors—often a very frustrating task.

In the late 1980s and early 1990s, many video games on the PC platform pushed up against this limit and left less and less space for TSRs—even essential ones like CD-ROM drivers—and arranging things so that there was enough free RAM to run the games, while keeping the necessary TSRs present, became a black art. Many gamers had several boot disks with different configurations for different games. In later versions of MS-DOS, "boot menu" scripts allowed various configurations to be selectable via a single "boot disk". In the mid- to later 1990s, while many games were still written for DOS, the 640K limit was eventually overcome by putting parts of the game's data and/or program code above the first 1 MB of memory and using the code below 640K to access the extended memory (using DOS extension methods), with code being swapped into the lowest 1 MB of RAM as overlays. Because programming with many overlays is a challenge in and of itself, once the program was too big to fit entirely into about 512 KB, use of extended memory was almost always done using a third-party DOS extender implementing VCPI or DPMI, because it becomes much easier and faster to access memory above the 1 MB boundary, and possible to run code in that area, when the x86 processor is switched from real mode to protected mode. However, since DOS and all DOS programs run in real mode (VCPI or DPMI makes a protected mode program look like a real mode program to DOS and the rest of the system by switching back and forth between the two modes), DOS TSRs and device drivers also run in real mode, and so any time one gets control, the DOS extender has to switch back to real mode until it relinquishes control, incurring a time penalty.