Terminate and Stay Resident
From Wikipedia, the free encyclopedia
Terminate and Stay Resident (TSR) was a system call in the MS-DOS operating system that returned control to the system as if the program had quit, but left the program in memory. Many software vendors used the call to create the appearance of multitasking, by transferring control back to the terminated program on automatic or externally-generated events. Some TSR programs 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.
Contents |
[edit] 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.
[edit] Using TSR
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 program 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 calling TSR meant the program would remain in memory 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.
[edit] Faults
Whilst very useful, or even essential to overcome MS-DOS's limitations, TSR programs 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 (the conventional memory). 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.
[edit] 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.
[edit] 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, though Win16 applications could do TSR-like tricks such as patching the IDT because real-mode Windows allowed it. 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 and device drivers to run simultaneously without the need for special programming tricks, and the modern notion of protected memory makes the kernel and its modules exclusively responsible for modifying an interrupt table.
[edit] See also
- Daemon (Unix)
- Windows service
