Terminate and Stay Resident

From Wikipedia, the free encyclopedia

Terminate and Stay Resident (TSR) is a system call in DOS operating systems that returns control to the system as if the program has quit, but keeps the program in memory. Many software vendors use 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 are effectively device drivers for hardware not directly supported by MS-DOS, while others are small utility programs offering frequently-used functionality such as scheduling and contact directories.

1 Brief history
2 Using TSR
3 Faults
4 Return
5 Decline
6 See also
7 External links

[edit] Brief history

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

[edit] Using TSR

The original call, INT 27H, is called 'Terminate But Stay Resident', hence the name 'TSR'. Using this call, a program can make only up to 64KB of its memory resident. MS-DOS version 2.0 introduced an improved call, INT 21H/31H ('Keep Process'), which removed this limitation and also let the program return an exit code. Before making this call, the program can install one or several interrupt vectors pointing into itself, so that it can be called again. Installing a hardware interrupt vector allows such a program to react to hardware events; a software interrupt vector allows it to be called by the currently running program; using a timer interrupt allowed a TSR to be summoned periodically.

By chaining the interrupt vectors TSR programs could take complete control of the computer. A TSR could have one of two behaviours:

Take complete control of an interrupt by not calling other TSRs that had previously altered the same interrupt vector.
Cascade with other TSRs by calling the old interrupt vector. This could be done before or after they executed their actual code. This way TSRs could form a chain of programs where each one calls the next one.

The 'Terminate and Stay Resident' method was used by most MS-DOS viruses which could either take control of the PC or stay at the background. Viruses would react on disk I/O or execution events by infecting executable (.EXE or .COM) files when they were run and data files when they were opened.

A TSR program can be loaded at any time; sometimes, they are 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 will, as 'TSR' implies, stay resident in memory while other programs are executing. Most of them^{[verification needed]} do not have an option for unloading themselves from memory, so calling TSR means the program will remain in memory until a reboot. However unloading is possible externally, using utilities like the MARK.EXE/RELEASE.EXE combo by TurboPower Software or soft reboot TSRs which will catch a specific key combination and release all TSRs loaded after them.

[edit] Faults

While very useful, or even essential to overcome 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 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.

[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 are 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 is called "Upper Memory Blocks" (UMBs) and loading programs into them is called loading high. Later, memory managers started including programs which would try to automatically determine how to best allocate TSRs between low and high memory (Quarterdeck's Optimize or Microsoft's MemMaker) in order to try and maximize the available space in the first 640 KB.

[edit] Decline

With the development of games using DOS extenders (a notable early example was Doom) 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 (followed by Windows 98) — which rendered most 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. The TSR has now almost disappeared completely, as multitasking operating systems such as Windows XP, Mac OS X, 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.