Terminate and Stay Resident (TSR) computer programs were the only way to achieve a primitive sort of multitasking using only the generic MS-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.
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.
The call, introduced in MS-DOS version 2, was called 'Terminate and Stay Resident', hence the name 'TSR'. 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.
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, undocumented ways, often causing systems to crash on their activation or deactivation when used with particular application programs or other TSRs. Additionally, all program code in MS-DOS systems, even those with large amounts of physical RAM, had to be loaded into the first 640 kilobytes of RAM. TSRs were no exception, and took chunks from that 640K 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, and Microsoft (in later DOS versions) and other commercial vendors provided utilities to perform the necessary calculations.
With the development of games using DOS extenders (a notable early example was Wolfenstein 3D) which bypassed the 640K barrier, many of the issues relating to TSRs disappeared, and with the widespread adoption of Microsoft Windows and especially Windows 95 the TSR faded into the background. The TSR has now disappeared completely, as multitasking operating systems such as Microsoft Windows XP, Mac OS, and Linux provide the facilities for multiple programs to run simultaneously without the need for special programming tricks.