Terminate and Stay Resident (TSR) computer programs were the only way to achieve a primitive sort of multitasking (usually just task-switching) using the DOS operating system. Some TSRs were effectively device drivers for hardware not directly supported by MS-DOS, whilst others were small utility programs offering frequently-used functionality such as scheduling and contact directories.

Brief history

---

Normally, in the MS-DOS operating system, only one program could be running at any given time, and when it wanted to stop running, it relinquished the control to MS-DOS's shell program, COMMAND.COM, using the system call INT 21H/4CH. The memory and system resources used by the program were marked as unused, effectively making it impossible to summon parts of it again. However, if a program ended with the system call INT 21H/31H, the operating system did not reuse a certain, specified, part of the program's memory.

Using TSRs

---

The call, introduced in MS-DOS version 2, was called 'Terminate and Stay Resident', hence the name 'TSR'. Later, the version 5 of the Microsoft MS-DOS Programmer's Reference called it 'Keep Program'. Before making this call, the program could install one or several interrupt vectors pointing into itself, so that it would be called again. Installing a hardware interrupt vector allowed such a program to react to hardware events; a software interrupt vector allowed it to be called by the currently running program; using a timer interrupt allowed a TSR to be summoned periodically.

A TSR could be loaded at any time; sometimes, they were loaded immediately after the operating system's boot, by being explicitly loaded in either the AUTOEXEC.BAT or CONFIG.SYS scripts, or alternatively at the user's request (for example, Borland's SideKick and Turbo Debugger). These programs would, as the name implied, stay resident in memory whilst other programs were executing. Most of them didn't have an option for unloading themselves from memory, so loading a TSR meant it would stay until a reboot. However unloading was possible externally, using utilities like the MARK.EXE/RELEASE.EXE combo by TurboPower Software or soft reboot TSRs which would catch a specific key combination and release all TSRs loaded after them.

Faults

---

Whilst very useful, or even essential to overcome MS-DOS's limitations, TSRs had a reputation as troublemakers. 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. Some viruses were coded as TSRs, and were deliberately troublesome. Additionally, all program code in MS-DOS systems, even those with large amounts of physical RAM, had to be loaded into the first 640 KB of RAM. TSRs were no exception, and took chunks from that 640 KB that was 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.

Return

---

With the arrival of expanded memory boards and especially of Intel 80386 processors in the second half of the 1980s, it became possible to use memory above 640 KB to load TSRs. This required complex software solutions, named Expanded Memory Managers, but provided some additional breathing room for several years. Famous memory managers were QRAM and QEMM by Quarterdeck, 386Max by Qualitas, CEMM by Compaq and later EMM386 by Microsoft. The memory areas usable for loading TSRs above 640 KB have been called "Upper Memory Blocks" (UMBs) and loading programs into them was called loading high. Later, memory managers started including programs which could automatically determine how to best allocate TSRs between low and high memory (Quarterdeck's Optimize or Microsoft's MemMaker) in order to maximize the available space in the first 640 KB.

Decay

---

With the development of games using DOS extenders (a notable early example was Wolfenstein 3D) which bypassed the 640 KB barrier, many of the issues relating to TSRs disappeared, and with the widespread adoption of Microsoft Windows and especially Windows 95 - which rendered TSRs unnecessary and some TSRs incompatible - the TSR faded into the background. Windows Me discontinued support for all TSRs. The TSR has now disappeared completely, as multitasking operating systems such as Windows XP, Mac OS, and Linux provide the facilities for multiple programs to run simultaneously without the need for special programming tricks, and the modern notion of protected memory makes it unthinkable that an application should be able to modify an interrupt table.

DOS on IBM PC compatibles

TSR-Programme | TSR | Program rezydentny | Резидентная программа | 램 상주 프로그램