In Bezug auf Computer ist ein Programm zum Beenden und Bleiben (üblicherweise vom Initialismus TSR bezeichnet) ein Computerprogramm, das einen Systemaufruf in DOS-Betriebssystemen verwendet, um die Steuerung zurückzugeben der Computer an das Betriebssystem, als ob das Programm beendet worden wäre, sich aber im Computerspeicher befindet, sodass er durch einen Hardware- oder Software-Interrupt wieder aktiviert werden kann. [1] Diese Technik hat die Einschränkung von DOS-Betriebssystemen, nur ein Programm auszuführen, teilweise überwunden. oder Aufgabe zu einer Zeit. TSR ist einzigartig für DOS und wird nicht in Windows verwendet.
Einige Programme zum Beenden und Beibehalten von residenten Programmen waren Hilfsprogramme, die ein Computerbenutzer möglicherweise mehrmals täglich aufrufen konnte, während er in einem anderen Programm mit einem Hotkey arbeitete. Borland Sidekick war ein frühes und beliebtes Beispiel für diesen Typ. Andere TSRs dienen als Gerätetreiber für Hardware, die das Betriebssystem nicht direkt unterstützt.
Verwenden von TSRs [ edit ]
Normalerweise kann unter DOS-Betriebssystemen immer nur ein Programm gleichzeitig ausgeführt werden. Um den Betrieb anzuhalten, gibt er die Kontrolle an das DOS-Shell-Programm COMMAND.COM zurück, wobei der Systemaufruf INT 21h / 4Ch verwendet wird. [2] Der verwendete Speicher und die verwendeten Systemressourcen vom Programm werden dann als nicht verwendet markiert. Dies macht es tatsächlich unmöglich, Teile des Programms neu zu starten, ohne das gesamte Programm von Grund auf neu laden zu müssen. Wenn ein Programm jedoch mit dem Systemaufruf INT 27h oder INT 21h / 31h endet, verwendet das Betriebssystem einen bestimmten angegebenen Teil des Programmspeichers nicht erneut.
Der ursprüngliche Aufruf, INT 27h wird als "Beenden, aber bleiben bleiben" bezeichnet, 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 ein, INT 21h / Funktion 31h ('Keep Process'), der diese Einschränkung beseitigte und das Programm einen Exit-Code zurückgeben ließ. Vor diesem Aufruf kann das Programm einen oder mehrere Interrupt-Handler installieren, die auf sich selbst zeigen, sodass es erneut aufgerufen werden kann. Durch die Installation eines Hardware-Interrupt-Vektors kann ein solches Programm auf Hardwareereignisse 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 programmierbare Intervall-Timer, insbesondere Abschnitt "IBM PC-kompatibel").
Das typische Verfahren zur Verwendung eines Interrupt-Vektors besteht darin, seinen aktuellen Wert (die Adresse) zu lesen, ihn im Speicherbereich des TSR zu speichern und einen Zeiger auf seinen eigenen Code zu installieren. Die gespeicherte Adresse wird vor oder nach dem Empfang des Interrupts durch den TSR aufgerufen und ist mit seiner Verarbeitung beendet. Dadurch wird eine einfach verknüpfte Liste von Interrupt-Handlern gebildet, die auch Interrupt-Service-Routinen oder ISRs genannt werden. Dieses Verfahren zum Installieren von ISRs wird als Verketten oder Einhaken als Interrupt- oder Interrupt-Vektor bezeichnet.
Durch die Verkettung der Interrupt-Vektoren könnten TSR-Programme die vollständige Kontrolle über den Computer übernehmen. Ein TSR könnte eines von zwei Verhalten haben:
- Übernehmen Sie die vollständige Kontrolle eines Interrupts, indem Sie keine anderen TSRs aufrufen, die zuvor denselben Interruptvektor geändert hatten.
- Kaskadieren Sie mit anderen TSRs, indem Sie den alten Interruptvektor aufrufen. Dies kann vor oder nach der Ausführung des eigentlichen Codes erfolgen. Auf diese Weise könnten TSRs eine Kette von Programmen bilden, in denen jedes das nächste aufruft.
Die "Terminate and Stay Resident" -Methode wurde von den meisten DOS-Viren verwendet, die entweder die Kontrolle über den PC übernehmen oder im Hintergrund bleiben könnten. Viren reagieren auf Platten-E / A- oder Ausführungsereignisse, indem sie ausführbare Dateien (.EXE oder .COM) infizieren, wenn sie ausgeführt wurden, und Datendateien, wenn sie geöffnet wurden.
Teile von DOS selbst, insbesondere in DOS-Versionen 5.0 und höher, verwendeten dieselbe Technik, um nützliche Funktionen auszuführen, wie den DOSKEY-Befehlszeilen-Editor und verschiedene andere installierbare Dienstprogramme, die durch Ausführen in der Befehlszeile (manuell) installiert wurden , von AUTOEXEC.BAT oder über INSTALL aus CONFIG.SYS), anstatt sie als Gerätetreiber durch DEVICE -Anweisungen in CONFIG.SYS zu laden.
Ein TSR-Programm kann jederzeit geladen werden. Manchmal werden sie unmittelbar nach dem Start des Betriebssystems geladen, indem sie explizit im Stapelverarbeitungsprogramm AUTOEXEC.BAT oder alternativ auf Anforderung des Benutzers geladen werden (z. B. Borlands Sidekick und Turbo Debugger, Quicken's QuickPay oder der persönliche Kalender von FunStuff Software). Diese Programme bleiben, wie "TSR" impliziert, im Speicher erhalten, während andere Programme ausgeführt werden. Einige von ihnen haben keine Möglichkeit, sich selbst aus dem Speicher zu entladen. Wenn Sie also TSR aufrufen, bleibt das Programm bis zu einem Neustart im Speicher. Das Entladen ist jedoch extern möglich. Dazu werden Dienstprogramme wie die MARK.EXE / RELEASE.EXE-Kombination von TurboPower Software oder Soft Reboot TSRs verwendet, die eine bestimmte Tastenkombination abfangen und alle danach geladenen TSRs freigeben. Da die ISR-Kette einzeln verknüpft ist, gibt es keine Vorkehrung, um die Adresse des vorherigen Handlers zu ermitteln (abgesehen von dem Versuch, die Interrupt-Kette zurückzuverfolgen) oder dem Vorgänger mitzuteilen, dass er seine "nächste Adresse, zu der springen soll" aktualisiert werden muss. nicht auf die TSR zu verweisen, die sich selbst entfernen möchte, sodass zum sicheren Entladen der TSRs in der Mitte einer Kette Stubs in den meisten Fällen im Speicher belassen werden mussten, wodurch eine Fragmentierung des Speichers verursacht wurde. Dies führte zu TSR-Kooperationssystemen wie TesSeRact und AMIS. [3]
Interrupts sharing [ edit ]
Um Probleme mit vielen TSR-Programmen zu lösen, die denselben Interrupt verwenden, wird eine Methode namens genannt ] Die alternative Multiplex-Interrupt-Spezifikation (AMIS) wurde von Ralf D. Brown als Verbesserung gegenüber zuvor über INT 2Fh angebotenen Diensten vorgeschlagen. AMIS bietet Möglichkeiten zur kontrollierten Freigabe von Software-Interrupts. Es basiert auf dem Interrupt Sharing Protocol von IBM das ursprünglich für das Teilen von Hardware-Interrupts eines x86-Prozessors entwickelt wurde. AMIS-Dienste sind über Int 2Dh verfügbar. [4]
Der Vorschlag hat in seiner Zeit nie eine weitverbreitete Wirkung unter den Programmierern gefunden. Sie existierte neben mehreren anderen konkurrierenden Spezifikationen mit unterschiedlichem Anspruch. [5]
Obwohl TSR-Programme sehr nützlich oder sogar unerlässlich waren, um die Einschränkungen von DOS zu überwinden, galten sie als Unruhestifter. Viele der Programme entführten das Betriebssystem auf verschiedene dokumentierte oder nicht dokumentierte Weise und führten häufig zum Absturz der Systeme bei Aktivierung oder Deaktivierung, wenn sie mit bestimmten Anwendungsprogrammen oder anderen TSRs verwendet wurden. Wie oben erläutert, wurden einige Viren als TSRs codiert und waren absichtlich störend. Darüber hinaus musste der gesamte Programmcode in DOS-Systemen, auch solche mit großem physischem RAM, in die ersten 640 KB des RAM (den herkömmlichen Speicher) geladen werden. TSRs bildeten keine Ausnahme und nahmen aus diesen 640 KB Brocken ab, die für Anwendungsprogramme nicht verfügbar waren. Dies bedeutete, dass das Schreiben einer TSR eine Herausforderung war, die kleinstmögliche Größe zu erreichen und die Kompatibilität mit einer Vielzahl von Softwareprodukten verschiedener Hersteller zu überprüfen. Dies ist oft eine sehr frustrierende Aufgabe.
In den späten 1980er und frühen 1990er Jahren stießen viele Videospiele auf der PC-Plattform an dieses Limit und ließen immer weniger Platz für TSRs - selbst für unverzichtbare wie CD-ROM-Treiber - und ordnete die Dinge so an, dass genügend Freiraum vorhanden war RAM zum Ausführen der Spiele, während die erforderlichen TSRs vorhanden waren, wurde 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 Skripts "Startmenü", dass verschiedene Konfigurationen über eine einzige "Startdiskette" ausgewählt werden konnten. In der Mitte bis in die späten 1990er Jahre, während viele Spiele noch für DOS geschrieben wurden, wurde das 640-KB-Limit schließlich überschritten, indem Teile der Spieldaten und / oder der Programmcode über die ersten 1 MB des Speichers gesetzt wurden und der Code unter 640 KB verwendet wurde Zugriff auf den Erweiterungsspeicher (unter Verwendung von DOS-Erweiterungsmethoden), wobei Code in die untersten 1 MB RAM als Overlays ausgelagert wird. Da das Programmieren mit vielen Überlagerungen an sich schon eine Herausforderung darstellt, wurde der Erweiterungsspeicher fast immer mit einem Drittanbieter-DOS-Extender, der VCPI oder DPMI implementiert, verwendet, sobald das Programm zu groß war, um vollständig in etwa 512 KB zu passen Es ist viel einfacher und schneller, auf Speicher oberhalb der 1-MB-Grenze zuzugreifen, und es ist möglich, Code in diesem Bereich auszuführen, wenn der x86-Prozessor vom realen Modus in den geschützten Modus wechselt. Da DOS und die meisten DOS-Programme jedoch im Realmodus ausgeführt werden (VCPI oder DPMI lässt ein Programm im geschützten Modus für DOS und den Rest des Systems wie ein Realmodusprogramm aussehen, indem zwischen den beiden Modi hin und her gewechselt wird), DOS-TSRs und -Geräte Die Treiber laufen auch im Real-Modus. Daher muss der DOS-Extender jedes Mal, wenn er die Kontrolle erlangt, wieder in den Real-Modus wechseln, bis er die Kontrolle aufgibt und eine Zeitstrafe verursacht (es sei denn, er verwendet Techniken wie DPMS oder CLOAKING).
Mit dem Aufkommen von Erweiterungsspeicherkarten und insbesondere von Intel 80386-Prozessoren in der zweiten Hälfte der achtziger Jahre wurde es möglich, Speicher über 640 KB zum Laden von TSRs zu verwenden. Dies erforderte komplexe Softwarelösungen mit dem Namen Erweiterte Speichermanager . Einige Speichermanager sind QRAM und QEMM von Quarterdeck, 386 MAX von Qualitas, CEMM von Compaq und später EMM386 von Microsoft. Die Speicherbereiche, die zum Laden von TSRs über 640 KB verwendet werden können, werden als "obere Speicherblöcke" (UMBs) bezeichnet, und das Laden von Programmen in sie wird als Laden hoch bezeichnet. Später begannen Speichermanager mit Programmen, die automatisch ermitteln sollten, wie TSRs am besten zwischen niedrigem und hohem Arbeitsspeicher (Quarterdeck's Optimize oder Microsofts MemMaker) zugewiesen werden sollten, um den verfügbaren Speicherplatz in den ersten 640 KB zu maximieren.
Abnahme [ edit ]
Bei der Entwicklung von Spielen mit DOS-Extendern (ein frühes Beispiel war Doom ), die die 640-KB-Sperre umgangen, viele davon Probleme im Zusammenhang mit TSRs verschwanden, und mit der weit verbreiteten Einführung von Microsoft Windows und insbesondere von Windows 95 (gefolgt von Windows 98) - was die meisten TSRs unnötig machte und einige TSRs nicht kompatibel waren - wurde der TSR veraltet, obwohl Win16-Anwendungen TSR-ähnliche Tricks ausführen konnten B. das Patchen der Interrupt-Deskriptor-Tabelle (IDT), da Windows dies zulässt. TSRs sind nahezu verschwunden, da Multitasking-Betriebssysteme wie Windows Vista, Windows 7, Mac OS X und Linux die Möglichkeit bieten, dass mehrere Programme und Gerätetreiber gleichzeitig ausgeführt werden können, ohne dass spezielle Programmier-Tricks und die moderne Vorstellung von geschützt erforderlich sind Der Speicher macht den Kernel und seine Module ausschließlich für die Änderung einer Interrupt-Tabelle verantwortlich.
No comments:
Post a Comment