Programm beenden und Resident bleiben - Terminate and stay resident program

Ein residentes Termination-and-Stay-Programm (üblicherweise TSR ) ist ein unter DOS laufendes Computerprogramm , das einen Systemaufruf verwendet , um die Kontrolle an DOS zurückzugeben, als ob es beendet wäre, aber im Computerspeicher verbleibt, damit es später reaktiviert werden kann. Diese Technik überwand teilweise die Beschränkung von DOS, nur ein Programm oder eine Aufgabe gleichzeitig auszuführen . TSRs werden nur in DOS verwendet, nicht in Windows .

Einige TSRs sind Dienstprogramme , die ein Computerbenutzer während der Arbeit in einem anderen Programm mehrmals täglich mit einem Hotkey aufrufen kann . Borland Sidekick war ein frühes und beliebtes Beispiel dieser Art. Andere dienen als Gerätetreiber für Hardware , die das Betriebssystem nicht direkt unterstützt.

Verwenden

Normalerweise kann DOS nur ein Programm gleichzeitig ausführen. Wenn ein Programm beendet ist, gibt es die Kontrolle an DOS zurück, indem es den Systemaufruf INT 21h/4Ch verwendet . Die verwendeten Speicher- und Systemressourcen werden dann als ungenutzt markiert. Dies macht es unmöglich, Teile des Programms neu zu starten, ohne alles neu laden zu müssen. Wenn ein Programm jedoch mit dem Systemaufruf INT 27h oder INT 21h/31h endet , verwendet das Betriebssystem einen bestimmten spezifizierten Teil seines Speichers nicht wieder.

Der ursprüngliche Anruf, INT 27h , heißt "terminate but stay resident", daher der Name "TSR". Mit diesem Aufruf kann ein Programm bis zu 64 KB seines Speichers resident machen. MS-DOS Version 2.0 führte einen verbesserten Aufruf INT 21h/31h ("Keep Process") ein, der diese Einschränkung beseitigte und das Programm einen Exitcode zurückgeben ließ . Vor diesem Aufruf kann das Programm einen oder mehrere Interrupt- Handler installieren, die in sich selbst zeigen, damit es erneut aufgerufen werden kann. Durch die Installation eines Hardware-Interrupt-Vektors kann ein solches Programm auf Hardware-Ereignisse reagieren. Durch die Installation eines Software-Interrupt-Vektors kann dieser vom aktuell laufenden Programm aufgerufen werden. Durch die Installation eines Timer-Interrupt-Handlers kann ein TSR periodisch ausgeführt werden (siehe ISA und programmierbarer Intervall-Timer , insbesondere den Abschnitt " IBM-PC-kompatibel ").

Das typische Verfahren zur Verwendung eines Interrupt-Vektors beinhaltet das Lesen seines gegenwärtigen Wertes (der Adresse), das Speichern desselben im Speicherplatz des TSR und das Ersetzen desselben durch eine Adresse in seinem eigenen Code. Die gespeicherte Adresse wird vom TSR aufgerufen, wodurch sie eine einfach verkettete Liste von Interrupt-Handlern , auch Interrupt-Service-Routinen oder ISRs genannt, bildet. Dieses Verfahren zum Installieren von ISRs wird als Verketten oder Hooken eines Interrupts oder eines Interrupt-Vektors bezeichnet.

Durch Verketten der Interrupt-Vektoren können TSRs die vollständige Kontrolle über den Computer übernehmen. Ein TSR kann eines von zwei Verhaltensweisen haben:

  • Übernehmen Sie die vollständige Kontrolle über einen Interrupt, indem Sie keine anderen TSRs aufrufen, die zuvor denselben Interrupt-Vektor geändert haben.
  • Kaskadieren Sie mit anderen TSRs, indem Sie den alten Interrupt-Vektor aufrufen. Dies kann vor oder nach der Ausführung des eigentlichen Codes erfolgen. Auf diese Weise können TSRs eine Kette bilden, in der jeder den nächsten anruft.

Die Methode "Terminate-and-Stay-Resident" wird von den meisten DOS- Viren und anderer Malware verwendet, die entweder die Kontrolle über den PC übernehmen oder im Hintergrund bleiben können. Diese Malware reagiert auf Datenträger-E/A- oder Ausführungsereignisse, indem sie ausführbare Dateien (.EXE oder .COM) bei der Ausführung und Datendateien beim Öffnen infiziert .

TSRs können jederzeit geladen werden; entweder während der Sequenz Start DOS (beispielsweise von AUTOEXEC.BAT ) oder auf Wunsch des Benutzers (zB Borland ‚s Handlanger und Turbo - Debugger, Quickens QuickPay oder FunStuff Software Persönlicher Kalender). Teile von DOS selbst verwenden diese Technik, insbesondere in DOS-Versionen 5.0 und höher. Zum Beispiel werden der DOSKEY- Befehlszeileneditor und verschiedene andere Dienstprogramme installiert, indem sie über die Befehlszeile ausgeführt werden (manuell oder von AUTOEXEC.BAT oder INSTALLinnerhalb von CONFIG.SYS ), anstatt sie als Gerätetreiber durch DEVICEAnweisungen in CONFIG zu laden. SYS.

Einige TSRs haben keine Möglichkeit, sich selbst zu entladen, sodass sie bis zu einem Neustart im Speicher bleiben. Das Entladen ist jedoch extern möglich, indem Utilities wie die MARK.EXE / RELEASE.EXE- Kombination von TurboPower Software oder Soft-Reboot- TSRs verwendet werden, die eine bestimmte Tastenkombination abfangen und alle danach geladenen TSRs freigeben. Da die Kette von ISRs einzeln verknüpft ist und ein TSR die Verknüpfung zu seinem Vorgänger an beliebiger Stelle speichern kann, gibt es für einen TSR keine allgemeine Möglichkeit, sich selbst aus der Kette zu entfernen. Daher muss beim Entladen eines TSR normalerweise ein Stub im Speicher verbleiben, was zu einer Speicherfragmentierung führt. Dieses Problem führte zu TSR-Kooperationsrahmen wie TesSeRact und AMIS.

Teilen unterbrechen

Um Probleme mit vielen TSRs zu bewältigen, die sich denselben Interrupt teilen, wurde von Ralf D. Brown eine Methode namens Alternate Multiplex Interrupt Specification (AMIS) als Verbesserung gegenüber den bisher verwendeten Diensten vorgeschlagen, die über INT 2Fh angeboten werden. AMIS bietet Möglichkeiten zur kontrollierten gemeinsamen Nutzung von Software-Interrupts . Es ist dem Interrupt Sharing Protocol von IBM nachempfunden , das ursprünglich für die gemeinsame Nutzung von Hardware-Interrupts eines x86-Prozessors entwickelt wurde. AMIS-Dienste sind über Int 2Dh verfügbar.

Der Vorschlag fand zu seiner Zeit unter Programmierern nie eine breite Anziehungskraft. Es existierte neben mehreren anderen konkurrierenden Spezifikationen unterschiedlicher Raffinesse.

Fehler

Obwohl sie sehr nützlich oder sogar unerlässlich sind, um die Einschränkungen von DOS zu überwinden , haben TSRs den Ruf, Unruhestifter zu sein. Viele kapern das Betriebssystem auf unterschiedliche dokumentierte oder undokumentierte Weise, was oft dazu führt, dass Systeme bei ihrer Aktivierung oder Deaktivierung abstürzen, wenn sie mit bestimmten Anwendungen oder anderen TSRs verwendet werden. Wie oben erläutert, wurden einige Viren und andere Malware als TSRs codiert und sind absichtlich lästig. Außerdem müssen unter DOS alle Programme, auch solche mit viel physischem RAM , in die ersten 640  KB RAM (den konventionellen Speicher ) geladen werden . TSRs sind keine Ausnahme und nehmen Blöcke von diesen 640 KB, die daher für andere Anwendungen nicht verfügbar sind. Dies bedeutete, dass das Schreiben eines TSR eine Herausforderung war, die kleinstmögliche Größe für ihn zu erreichen und ihn auf Kompatibilität mit vielen Softwareprodukten verschiedener Hersteller zu überprüfen – oft eine sehr frustrierende Aufgabe.

In den späten 1980er und frühen 1990er Jahren stießen viele Videospiele auf der PC-Plattform an diese Grenze und ließen immer weniger Platz für TSRs – sogar für wichtige wie CD-ROM- Treiber – und die Dinge so anzuordnen, dass genügend freier RAM zum Ausführen vorhanden war die Spiele, während die notwendigen TSRs vorhanden waren, wurden zu einer schwarzen Kunst. Viele Spieler hatten mehrere Bootdisketten mit unterschiedlichen Konfigurationen für verschiedene Spiele. In späteren Versionen von MS-DOS ermöglichten "Boot-Menü"-Skripte die Auswahl verschiedener Konfigurationen über eine einzelne "Boot-Diskette". Mitte bis Ende der 1990er Jahre, als viele Spiele noch für DOS geschrieben wurden, wurde die Grenze von 640 KB schließlich überwunden, indem Teile der Spieldaten oder des Codes über die ersten 1 MB des Speichers gelegt und der Code unter 640 KB verwendet wurde, um auf die erweiterter Speicher (unter Verwendung von DOS-Erweiterungsmethoden ), wobei Code als Overlays in das unterste 1 MB RAM ausgelagert wird . Da das Programmieren mit vielen Overlays an sich schon eine Herausforderung darstellt, wurde der Erweiterungsspeicher, sobald das Programm zu groß war, um vollständig in etwa 512 KB zu passen, fast immer mit einem DOS-Extender eines Drittanbieters verwendet, der VCPI oder DPMI implementiert , weil es zu viel einfacher und schneller auf den Speicher oberhalb der 1-MB-Grenze zuzugreifen und Code in diesem Bereich auszuführen, wenn der x86-Prozessor vom Real-Modus in den Protected-Modus geschaltet wird . Da DOS und die meisten DOS-Programme jedoch im Realmodus laufen (VCPI oder DPMI lässt ein Programm im geschützten Modus für DOS und den Rest des Systems wie ein Programm im Realmodus aussehen, indem es zwischen den beiden Modi hin- und herwechselt), DOS TSRs und Device Treiber laufen auch im Real-Modus, und jedes Mal, wenn man die Kontrolle übernimmt , muss der DOS-Extender zurück in den Real-Modus wechseln, bis er die Kontrolle aufgibt , was zu einer Zeitstrafe führt (es sei denn, sie verwenden Techniken wie DPMS oder CLOAKING ).

Zurückkehren

Mit dem Aufkommen von Erweiterungsspeicherkarten und insbesondere von Intel 80386- Prozessoren in der zweiten Hälfte der 1980er Jahre wurde es möglich, Speicher über 640 KB zum Laden von TSRs zu verwenden. Dies erforderte komplexe Softwarelösungen, die als Expanded Memory Manager bezeichnet werden . Einige Speichermanager sind QRAM und QEMM von Quarterdeck , 386 MAX von Qualitas , CEMM von Compaq und später EMM386 von Microsoft . Die zum Laden von TSRs über 640 KB verwendbaren Speicherbereiche werden als „ Upper Memory Blocks “ (UMBs) und das Laden von Programmen in diese als Loading High bezeichnet . Später begannen Speichermanager, Programme wie Quarterdecks Optimize oder Microsofts MEMMAKER einzubinden, die versuchen, den verfügbaren Speicherplatz in den ersten 640 KB zu maximieren, indem sie bestimmen, wie TSRs am besten zwischen niedrigem und hohem Speicher verteilt werden.

Ablehnen

Mit der Entwicklung von Spielen mit DOS-Extendern (ein frühes Beispiel war Doom ), die die 640-KB-Grenze umgingen, verschwanden viele der Probleme im Zusammenhang mit TSRs und mit der weit verbreiteten Einführung von Microsoft Windows und insbesondere Windows 95 (gefolgt von Windows 98 ) – was die meisten TSRs unnötig und einige TSRs inkompatibel machte – der TSR war veraltet, obwohl Win16- Anwendungen TSR-ähnliche Tricks wie das Patchen der Interrupt-Deskriptor-Tabelle (IDT) ausführen können, weil Windows dies zuließ.

Windows Me und Windows NT (letzteres einschließlich Consumer-Betriebssysteme ab Windows XP ) laufen die ganze Zeit im geschützten Modus oder im langen Modus , wodurch die Möglichkeit deaktiviert wird, in den Realmodus zu wechseln, der für die Funktion von TSRs erforderlich ist. Stattdessen verfügen diese Betriebssysteme über moderne Treiber- und Service- Frameworks mit Speicherschutz und präemptivem Multitasking , sodass mehrere Programme und Gerätetreiber gleichzeitig ausgeführt werden können, ohne dass spezielle Programmiertricks erforderlich sind. der Kernel und seine Module wurden ausschließlich dafür verantwortlich gemacht, die Interrupt-Tabelle zu modifizieren.

Siehe auch

Verweise

Externe Links