Un programa residente de terminación y permanencia (comúnmente TSR ) es un programa de computadora que se ejecuta bajo DOS y que utiliza una llamada al sistema para devolver el control a DOS como si hubiera terminado, pero permanece en la memoria de la computadora para que pueda reactivarse más tarde. [1] Esta técnica superó parcialmente la limitación de DOS de ejecutar solo un programa o tarea a la vez. Los TSR se utilizan solo en DOS, no en Windows .
Algunos TSR son programas de utilidad que un usuario de computadora puede ejecutar varias veces al día, mientras trabaja en otro programa, mediante el uso de una tecla de acceso rápido . Borland Sidekick fue un ejemplo temprano y popular de este tipo. Otros sirven como controladores de dispositivos para hardware que el sistema operativo no admite directamente.
Normalmente, DOS solo puede ejecutar un programa a la vez. Cuando un programa termina, devuelve el control a DOS mediante la llamada al sistema INT 21h/4Ch de la API de DOS . [2] La memoria y los recursos del sistema utilizados se marcan como no utilizados. Esto hace que sea imposible reiniciar partes del programa sin tener que volver a cargarlo todo. Sin embargo, si un programa termina con la llamada al sistema INT 27h o INT 21h/31h , el sistema operativo no reutiliza una parte específica de su memoria.
La llamada original, INT 27h , se denomina "terminar pero permanecer residente", de ahí el nombre "TSR". Con esta llamada, un programa puede hacer que hasta 64 KB de su memoria permanezcan residentes. La versión 2.0 de MS-DOS introdujo una llamada mejorada, INT 21h/31h ('Keep Process'), que eliminó esta limitación y permitió que el programa devolviera un código de salida . Antes de realizar esta llamada, el programa puede instalar uno o varios controladores de interrupciones que apuntan hacia sí mismo, de modo que se lo pueda llamar nuevamente. La instalación de un vector de interrupción de hardware permite que un programa de este tipo reaccione a los eventos de hardware. La instalación de un vector de interrupción de software permite que sea llamado por el programa que se está ejecutando actualmente. La instalación de un controlador de interrupciones de temporizador permite que un TSR se ejecute periódicamente (utilizando un temporizador de intervalo programable ).
El método típico de utilizar un vector de interrupción implica leer su valor actual (la dirección), almacenarlo dentro del espacio de memoria del TSR y reemplazarlo con una dirección en su propio código. La dirección almacenada se llama desde el TSR, formando en efecto una lista enlazada simple de manejadores de interrupciones , también llamados rutinas de servicio de interrupción o ISR. Este procedimiento de instalación de ISR se llama encadenamiento o enganche de una interrupción o un vector de interrupción.
Los TSR se pueden cargar en cualquier momento; ya sea durante la secuencia de inicio de DOS (por ejemplo, desde AUTOEXEC.BAT ), o a petición del usuario (por ejemplo, Sidekick y Turbo Debugger de Borland , QuickPay de Quicken o Personal Calendar de FunStuff Software). Partes del propio DOS utilizan esta técnica, especialmente en las versiones DOS 5.0 y posteriores. Por ejemplo, el editor de línea de comandos DOSKEY y varias otras utilidades se instalan ejecutándolas en la línea de comandos (manualmente, o desde AUTOEXEC.BAT o a través de CONFIG.SYS ) en lugar de cargarlas como controladores de dispositivos a través de instrucciones en CONFIG.SYS.INSTALLDEVICE
Algunos TSR no tienen forma de descargarse a sí mismos, por lo que permanecerán en la memoria hasta que se reinicie. Sin embargo, la descarga es posible de forma externa, utilizando utilidades como la combinación MARK.EXE/RELEASE.EXE de TurboPower Software o TSR de reinicio suave que capturará una combinación de teclas específica y liberará todos los TSR cargados después de ellos. Como la cadena de ISR está vinculada individualmente y un TSR puede almacenar el enlace a su predecesor en cualquier lugar que elija, no existe una forma general para que un TSR se elimine a sí mismo de la cadena. Por lo tanto, generalmente se debe dejar un trozo en la memoria al descargar un TSR, lo que provoca la fragmentación de la memoria. Este problema dio lugar a marcos de cooperación de TSR como TesSeRact y AMIS. [3]
Para gestionar los problemas que surgen cuando muchos TSR comparten la misma interrupción, Ralf D. Brown propuso un método llamado Alternate Multiplex Interrupt Specification (AMIS) como una mejora con respecto a los servicios ofrecidos anteriormente a través de INT 2Fh. AMIS proporciona formas de compartir interrupciones de software de una manera controlada. Está basado en el protocolo de compartición de interrupciones de IBM, inventado originalmente para compartir interrupciones de hardware de un procesador x86. Los servicios AMIS están disponibles a través de Int 2Dh. [4]
La propuesta nunca tuvo una aceptación generalizada entre los programadores en su época. Existió junto con otras especificaciones competidoras de diferente sofisticación. [5]
Si bien son muy útiles, o incluso esenciales para superar las limitaciones de DOS , los TSR tienen fama de ser problemáticos. Muchos secuestran el sistema operativo de diversas formas documentadas o no, y a menudo provocan que los sistemas se bloqueen al activarse o desactivarse cuando se utilizan con determinadas aplicaciones u otros TSR.
Al encadenar los vectores de interrupción, los TSR pueden tomar el control total de la computadora. Un TSR puede tener uno de dos comportamientos:
La mayoría de los virus DOS y otros programas maliciosos utilizan el método de terminación y permanencia residente , que puede tomar el control del equipo o permanecer en segundo plano. Este programa malicioso puede reaccionar a eventos de ejecución o de E/S del disco infectando archivos ejecutables (.EXE o .COM) cuando se ejecuta y archivos de datos cuando se abren.
Además, en DOS todos los programas, incluso aquellos con grandes cantidades de RAM física , deben cargarse en los primeros 640 KB de RAM (la memoria convencional ). Los TSR no son una excepción y toman partes de esos 640 KB que, por lo tanto, no están disponibles para otras aplicaciones. Esto significaba que escribir un TSR era un desafío para lograr el tamaño más pequeño posible y verificar su compatibilidad con muchos productos de software de diferentes proveedores, una tarea a menudo muy frustrante.
A finales de los años 1980 y principios de los 1990, muchos videojuegos para PC se enfrentaron a este límite y dejaron cada vez menos espacio para los TSR (incluso los esenciales, como los controladores de CD-ROM ), y organizar las cosas de modo que hubiera suficiente RAM libre para ejecutar los juegos, manteniendo presentes los TSR necesarios, se volvió muy complicado. Muchos jugadores tenían varios discos de arranque con diferentes configuraciones para diferentes juegos. En versiones posteriores de MS-DOS, los scripts de "menú de arranque" permitían seleccionar varias configuraciones a través de una única entrada de menú. A mediados y finales de los años 1990, mientras muchos juegos todavía se escribían para DOS, el límite de 640 KB finalmente se superó colocando partes de los datos del juego por encima del primer 1 MB de memoria y usando el código por debajo de los 640 KB para acceder a la memoria extendida utilizando memoria expandida (EMS) mediante el uso de la técnica de superposición . Un enfoque alternativo posterior fue cambiar la CPU al modo protegido utilizando extensores de DOS y ejecutar el programa en modo protegido. Este último permitió tener código y datos en el área de memoria extendida. [ cita requerida ]
Debido a que programar con muchas superposiciones es un desafío en sí mismo, una vez que el programa era demasiado grande para caber completamente en aproximadamente 512 KB, el uso de memoria extendida casi siempre se hacía usando un extensor DOS de terceros que implementaba VCPI o DPMI , porque se vuelve mucho más fácil y rápido acceder a la memoria por encima del límite de 1 MB, y es posible ejecutar código en esa área, cuando el procesador x86 se cambia del modo real al modo protegido . Sin embargo, dado que DOS y la mayoría de los programas DOS se ejecutan en modo real (VCPI o DPMI hace que un programa en modo protegido parezca un programa en modo real para DOS y el resto del sistema al cambiar de un modo a otro), los TSR y los controladores de dispositivos de DOS también se ejecutan en modo real, y por lo tanto, cada vez que uno obtiene el control, el extensor DOS tiene que volver al modo real hasta que ceda el control, lo que incurre en una penalización de tiempo (a menos que utilicen técnicas como DPMS o CLOAKING ).
Con la llegada de las placas de memoria expandida y especialmente de los procesadores Intel 80386 en la segunda mitad de la década de 1980, se hizo posible utilizar memoria por encima de 640 KB para cargar TSR. Esto requirió soluciones de software complejas, llamadas administradores de memoria expandida . Algunos administradores de memoria son QRAM y QEMM de Quarterdeck , 386 MAX de Qualitas, CEMM de Compaq y más tarde EMM386 de Microsoft . Las áreas de memoria utilizables para cargar TSR por encima de 640 KB se denominan " bloques de memoria superior " (UMB) y la carga de programas en ellas se denomina carga alta . Más tarde, los administradores de memoria comenzaron a incluir programas como Optimize de Quarterdeck o MEMMAKER de Microsoft que intentan maximizar el espacio disponible en los primeros 640 KB determinando la mejor manera de asignar TSR entre memoria baja y alta.
Con el desarrollo de juegos que utilizaban extensores DOS (un ejemplo temprano fue Doom ) que saltaban la barrera de los 640 KB, muchos de los problemas relacionados con los TSR desaparecieron, y con la adopción generalizada de Microsoft Windows y especialmente Windows 95 (seguido por Windows 98 ) -que hizo que la mayoría de los TSR fueran innecesarios y algunos TSR incompatibles- el TSR cayó en la obsolescencia, aunque las aplicaciones Win16 pueden hacer trucos similares a los TSR, como parchear la tabla de descriptores de interrupción (IDT) porque Windows lo permitía. Windows Me no permite que una computadora arranque en un kernel DOS apagando Windows Me; por lo tanto, los TSR se volvieron inútiles en Windows Me.
La serie Windows NT (que incluye Windows 2000 , Windows XP y posteriores) reemplazó completamente a DOS y se ejecuta en modo protegido o modo largo (solo versiones posteriores de 64 bits) todo el tiempo, deshabilitando la capacidad de cambiar al modo real, que es necesario para que funcionen los TSR. En cambio, estos sistemas operativos tienen marcos de controladores y servicios modernos con protección de memoria y multitarea preventiva , lo que permite que varios programas y controladores de dispositivos se ejecuten simultáneamente sin la necesidad de trucos de programación especiales; el núcleo y sus módulos se han hecho exclusivamente responsables de modificar la tabla de interrupciones.
{{cite web}}: CS1 maint: unfit URL (link)