Editing Terminate-and-stay-resident program

{{Multiple issues|
{{More citations needed|date=October 2009}}
{{Original research|date=June 2024}}
}}
A '''terminate-and-stay-resident program''' (commonly '''TSR''') is a [[computer program]] running under [[DOS]] that uses a [[system call]] to return control to DOS as though it has finished, but remains in [[computer memory]] so it can be reactivated later.<ref>{{cite web |author-last=Maybury |author-first=Rick |author-link=Rick Maybury |title=Beat the Bug—Computer Viruses |work=PC Top Tips |date=1998 |url=http://www.pctoptips.co.uk/Bootcamp/1998/004.htm |access-date=2012-02-09 | archive-url=https://web.archive.org/web/20090928221309/http://www.pctoptips.co.uk/Bootcamp/1998/004.htm | archive-date=September 28, 2009 | url-status=usurped}}</ref> This technique partially overcame DOS's limitation of executing only one program, or [[task (computing)|task]], at a time. TSRs are used only in DOS, not in [[Microsoft Windows|Windows]].

Some TSRs are [[utility software]] that a computer user might call up several times a day, while working in another program, by using a [[keyboard shortcut|hotkey]]. [[Borland Sidekick]] was an early and popular example of this type. Others serve as [[device driver]]s for [[computer hardware|hardware]] that the operating system does not directly support.

==Use <span class="anchor" id="Using TSRs"></span>==
Normally [[DOS]] can run only one program at a time. When a program finishes, it returns control to DOS using the [[system call]] {{mono|INT 21h/4Ch}} of the [[DOS API]].<ref>[http://stanislavs.org/helppc/int_21-0.html] HelpPC reference: INT 21,0 – Program Terminate</ref> The memory and system resources used are then marked as unused. This makes it impossible to restart parts of the program without having to reload it all. However, if a program ends with the system call {{mono|INT 27h}} or {{mono|INT 21h/31h}}, the operating system does not reuse a certain specified part of its memory.

The original call, {{mono|INT 27h}}, is called "terminate but stay resident", hence the name "TSR". Using this call, a program can make up to 64&nbsp;KB of its memory resident. MS-DOS version 2.0 introduced an improved call, {{mono|INT 21h/31h}} ('Keep Process'), which removed this limitation and let the program return an [[exit status|exit code]]. Before making this call, the program can install one or several [[interrupt]] handlers pointing into itself, so that it can be called again. Installing a hardware interrupt vector allows such a program to react to hardware events. Installing a software interrupt vector allows it to be called by the currently running program. Installing a timer interrupt handler allows a TSR to run periodically (using a [[programmable interval timer]]).

The typical method of using an interrupt vector involves reading its present value (the address), storing it within the memory space of the TSR, and replacing it with an address in its own code. The stored address is called from the TSR, in effect forming a singly linked list of [[interrupt handler]]s, also called ''interrupt service routines'', or ISRs. This procedure of installing ISRs is called ''chaining'' or ''[[hooking]]'' an interrupt or an interrupt vector.

TSRs can be loaded at any time; either during the DOS startup sequence (for example, from [[AUTOEXEC.BAT]]), or at the user's request (for example, [[Borland]]'s [[Borland Sidekick|Sidekick]] and Turbo Debugger, Quicken's QuickPay, or FunStuff Software's Personal Calendar). Parts of DOS itself use this technique, especially in DOS versions 5.0 and later. For example, the [[DOSKEY]] command-line editor and various other utilities are installed by running them at the command line (manually, or from [[AUTOEXEC.BAT]] or through [[INSTALL (CONFIG.SYS directive)|<code>INSTALL</code> from within CONFIG.SYS]]) rather than loading them as device drivers through <code>[[DEVICE (CONFIG.SYS directive)|DEVICE]]</code> statements in CONFIG.SYS.

Some TSRs have no way to unload themselves, so they 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. As the chain of ISRs is singly linked, and a TSR may store the link to its predecessor anywhere it chooses, there is no general way for a TSR to remove itself from the chain. So usually a stub must be left in memory when unloading a TSR, causing memory fragmentation. This problem gave rise to TSR cooperation frameworks such as [[TesSeRact]] and AMIS.<ref>{{cite web |url=http://hdebruijn.soo.dto.tudelft.nl/newpage/interupt/CAT-042.HTM |title=a list of TSR libraries |url-status=dead |archive-url=https://web.archive.org/web/20070817023830/http://hdebruijn.soo.dto.tudelft.nl/newpage/interupt/CAT-042.HTM |archive-date=2007-08-17}} also known as frameworks.</ref>

=== Interrupt sharing ===

To manage problems with many TSRs sharing the same interrupt, a method called Alternate Multiplex Interrupt Specification (AMIS) was proposed by [[Ralf D. Brown]] as an improvement over previously used services offered via INT 2Fh. AMIS provides ways to share [[INT (x86 instruction)|software interrupts]] in a controlled manner. It is modeled after IBM's Interrupt Sharing Protocol, originally invented for sharing hardware interrupts of an x86 processor. AMIS services are available via Int 2Dh.<ref>{{cite web |title=int 2D |url=https://www.ctyme.com/intr/int-2d.htm |access-date=2019-11-14 |url-status=live |archive-url=https://web.archive.org/web/20171201103232/http://www.ctyme.com/intr/int-2d.htm |archive-date=2017-12-01}}</ref>

The proposal never gained a widespread traction among programmers in its days. It existed alongside several other competing specifications of varying sophistication.<ref>{{cite web |title=TSR Libraries |date=2016-06-19 |url=https://www.ctyme.com/intr/cat-042.htm |access-date=2019-11-14 |url-status=live |archive-url=https://web.archive.org/web/20160619045026/http://www.ctyme.com/intr/cat-042.htm |archive-date=2016-06-19}}</ref>

==Faults==
While very useful, or even essential to overcome [[DOS]]'s limitations, TSRs have a reputation as troublemakers. Many hijack the operating system in varying documented or undocumented ways, often causing systems to crash on their activation or deactivation when used with particular applications or other TSRs.

By chaining the interrupt vectors TSRs can take complete control of the computer. A TSR can have one of two behaviors:

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

The terminate-and-stay-resident method is used by most DOS [[computer virus|viruses]] and other malware, which can either take control of the PC or stay in the background. This malware can react to disk I/O or execution events by infecting [[executable]] (.EXE or .COM) files when it is run and data files when they are opened.

Additionally, in DOS all programs must be loaded into the first 640&nbsp;[[kilobyte|KB]] of RAM (the [[conventional memory]]), even on computers with large amounts of physical [[random-access memory|RAM]]. TSRs are no exception, and take chunks from that 640&nbsp;KB that are thus unavailable to other applications. 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 game]]s 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 very complicated. Many gamers had several [[boot disk]]s with different configurations for different games. In later versions of MS-DOS, "boot menu" scripts allowed various configurations to be selectable via a single menu entry. In the mid- to later 1990s, while many games were still written for DOS, the 640&nbsp;KB limit was eventually overcome by putting parts of the game's data above the first 1&nbsp;MB of memory and using the code below 640&nbsp;KB to access the extended memory using [[expanded memory]] (EMS) by making use of [[overlay (programming)|overlay]] technique. An alternative later approach was to switch the CPU into Protected Mode by using [[DOS extender]]s and run the program in protected mode. The latter allowed to have code and data in the extended memory area.{{cn|date=June 2024}}

Because programming with many overlays is a challenge in and of itself, once the program was too big to fit entirely into about 512&nbsp;KB, use of extended memory was almost always done using a third-party DOS extender implementing [[Virtual Control Program Interface|VCPI]] or [[DOS Protected Mode Interface|DPMI]], because it becomes much easier and faster to access memory above the 1&nbsp;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 most 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 (unless they utilize techniques such as [[DOS Protected Mode Services|DPMS]] or [[DOS Protected Mode Services#CLOAKING|CLOAKING]]).

==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&nbsp;KB to load TSRs. This required complex software solutions, named ''expanded memory managers''. Some memory managers are [[QEMM#QEMM product ranges|QRAM]] and [[QEMM]] by [[Quarterdeck Office Systems|Quarterdeck]], [[386MAX|386<sup>MAX</sup>]] by [[Qualitas]], [[CEMM]] by [[Compaq]], and later [[EMM386]] by [[Microsoft]]. The memory areas usable for loading TSRs above 640&nbsp;KB are called "[[upper memory area|upper memory blocks]]" (UMBs) and loading programs into them is called ''loading high''. Later, memory managers started including programs such as Quarterdeck's Optimize or Microsoft's [[MEMMAKER]] which try to maximize the available space in the first 640&nbsp;KB by determining how best to allocate TSRs between low and high memory.

==Decline==
With the development of games using [[DOS extender]]s (an early example was ''[[Doom (1993 video game)|Doom]]'') which bypassed the 640&nbsp;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]])&nbsp;– which rendered most TSRs unnecessary and some TSRs incompatible&nbsp;– the TSR faded into obsolescence, though [[Win16]] applications can do TSR-like tricks such as patching the [[interrupt descriptor table]] (IDT) because Windows allowed it.
[[Windows Me]] does not allow a computer to boot into a DOS Kernel by shutting down Windows Me; thus TSRs became useless on Windows Me.

The [[Windows NT]] series (including [[Windows 2000]], [[Windows XP]], and later) replaced DOS completely and run in [[protected mode]] or [[long mode]] (later 64-bit versions only) all the time, disabling the ability to switch to real mode, which is needed for TSRs to function. Instead these operating systems have modern driver and [[Windows service|service]] frameworks with [[memory protection]] and [[preemptive multitasking]], allowing multiple programs and device drivers to run simultaneously without the need for special programming tricks; the [[kernel (operating system)|kernel]] and its modules have been made exclusively responsible for modifying the interrupt table.

==See also==
* [[Daemon (computing)|Daemon]] (Unix)
* [[Desk accessory]]
* [[DOS Protected Mode Services]] / DPMS
* [[Extension (Mac OS)]]
* [[Resident System Extension]] / RSX (CP/M)
* [[Windows service]]

==References==
{{Reflist}}

==External links==
* [https://groups.google.com/g/net.micro.pc/c/vDZFBq-WIgg An early TSR]
* comp.os.msdos.programmer FAQ – [http://www.faqs.org/faqs/msdos-programmer-faq/part4/section-21.html How can I write a TSR (Terminate-and-Stay-Resident) utility?]
* [http://guideme.itgo.com/atozofc/ A to Z of C]; a free book on DOS programming in C; Chapter 27 – {{cite web |title=TSR programming |url=http://guideme.itgo.com/atozofc/ch27.pdf}}&nbsp;{{small|(80&nbsp;KB)}}
* [https://web.archive.org/web/20100403220515/http://www.simtel.net/product/view/id/46893 IBM's Interrupt-Sharing Protocol], zip archive, 6.5&nbsp;KB ([[Simtel]])
* The [https://www.cs.cmu.edu/~ralf/pub-files/altmpx35.zip Alternate Multiplex Interrupt Specification] (AMIS), v.3.5 (zipfile)
* [https://www.cs.cmu.edu/~ralf/pub-files/amisl092.zip AMISLIB] – a function library to write self-highloading, removable TSRs in assembler (zipfile)

{{DEFAULTSORT:Terminate And Stay Resident}}
[[Category:DOS technology]]
[[Category:DOS memory management]]