4. Kapitel: Literatur

1.PC-INTERN 4, Systemprogrammierung
Autor: Michael Tischer
Verlag: Data Becker

2.Effektives Programmieren mit Turbo Pascal
Autor: Rainer Kolbeck
Verlag: Markt & Technik

3. PC Underground
Autoren: Boris Bertelsons & Mathias Rasch
Verlag: Data Becker

4. DOS5, die entgültige Referenz
Autor: Arne Schäpers
Verlag: Addison & Wesley

5. PC Technik Guide
Autoren: Wilfred Lindo & Michael Starogardzki

6. VGA- und Super-VGA-Programmierung
Autor: Matthias Uphoff
Verlag: Addison Wesley

7. Borland Turbo Pascal Handbuch
Verlag: Borland

Zurück

5. Anmerkungen/Probleme bei der Erstellung

Das Erstellen von funktionstüchtigen und absturzsicheren TSR-Programmen ist relativ komplex, da neben Systemkenntniss auch ein hohes Maß an Programmier- disziplin unverzichtbar ist. Im folgenden Abschnitt möchten wir dies anhand von Problemen, die beim Erstellen des Programmes aufgetreten sind, erklären.

5.1 Die Interrupt-Deklaration einer Prozedur

Für eine Interrupt-Service-Routine ist ein üblicher Prozedurrahmen nicht geeignet, da sie vom Programm, im Gegensatz zu üblichen Prozeduren, nie direkt aufgerufen wird. Die Interrupt-Deklaration bewegt den Compiler zu einer anderen Behandlung der Prozedur beim Compilieren. Der erzeugte Prozedur-Rahmen ist ein ganz anderer, und die Prozedur kann nicht direkt aufgerufen werden, um Schwierigkeiten zu vermeiden. Da im Prozedurkopf bereits alle Register auf dem Stack gesichert und sie am Prozedurende durch das Rückholen vom Stack restauriert werden, muß diese Sicherung und Restaurierung nicht vom Programmierer übernommen werden. Übernimmt man diese Aufgaben in einer interrupt-deklarierten Prozedur dennoch, ist eine fehlerfreie Ausführung nicht mehr gewährleistet.

Zurück

5.2 Der eigene Stack

Bevor man in einer installierten Interrupt-Service-Routine eine größere Prozedur aufruft, die, wie in unserem Beispiel die Prozedur „action“ oder „screenwork“, wichtige Aufgaben zur Steuerung übernimmt, ist es zwingend notwendig den eigenen Daten- und Stackbereich zu initialisieren und danach zu restaurieren.

Zunächst muß das Stacksegment sowie der Stackpointer des unterbrochenen Programms gesichert werden. Dazu muß der Inhalt der Prozessor-Register SS (Stacksegment) und SP (Stackpointer) gesichert werden. Anschließend wird der eigene Stack, der Stack des Turbo -Programms also, aktiviert. Nun kann der Aufruf einer „Hauptprozedur“ erfolgen. Danach muß lediglich das Stacksegment und der Stackpointer des unterbrochenen Programms wieder restauriert und aktiviert werden.

Unserer Erfahrung nach sollte das Sichern und Umschalten, sowie das Restaurieren des Stacks immer vollzogen werden, wenn man mit mehr als 30Bytes lokaler Daten arbeitet. Außerdem kommt nahezu kein leistungsfähiges TSR-Programm ohne wichtige Prozeduren aus, die ein Umschalten des Stacks unvermeidbar machen.

Zurück

5.3 Das Ausführen anderer Programme

Ein weiteres Problem ergab sich beim Ausführen anderer Programme während der Laufzeit von DOS-TOOL V1.0. Da die Realisierung über die Turbo-Pascal-Prozedur EXEC, die ein Programm ausführt, ohne das laufende zu beenden, Probleme bereitete, war ein Lösung ge fragt, die adäquaten Ersatz lieferte.

Dazu wird einfach eine Zeichenkette, die den auszuführenden Befehl repräsentiert, direkt in den Tastaturspeicher geschrieben. Durch ein folgendes Return-Signal wird sozusagen ein gewöhnlicher Aufruf simuliert. Das nächste Problem hängt mit der Überlegung zusammen, daß bei der Ausführung eines Programms die Funktion von DOS-TOOL eingeschränkt werden soll. Dazu muß bei einer abgeschlossenen Tastatureingabe lediglich die Variable „active“ auf wahr und die Variable „mouseon“ auf falsch gesetzt werden, denn dann wird weder Bedienbildschirm aufgebaut, noch werden Mausabfragen realisiert.

Die Lösung liefert die permanente Abfrage des Tastaturports über die Interrupt-Service-Routine des Tastaturinterrupts $09. Kommt dabei am Tastaturport ein Return an, werden die Variablen wie gewünscht verändert. Der Befehl und somit das Programm wird dann ungestört ausgeführt, obgleich DOS-TOOL natürlich noch im Hintergrund aktiv ist und nach Beendigung anderer Programme wieder voll aktiviert wird.

Zurück

5.4 Eine Protokolldatei

Ein weiteres Ziel unserer Projektarbeit in Verbindung mit DOS-TOOL war die Realisierung einer Funktion, die sämtliche Eingaben des Benutzers in einer Datei auslagert und somit die Benutzung des Computers protokolliert werden kann, was in vielerlei Hinsicht nützlich wäre. Diese Idee scheiterte einerseits an rein programmiertechnischen Problemen, mehr jedoch an mangelnder Zeit, die für die Realisierung von Alternativen nötig gewesen wäre.

Am Anfang stand folgende Idee: Unser Programm fängt jedes vom Benutzer getätigte Return ab und schreibt daraufhin die aktuelle Bildschirmzeile in eine Datei.

Das Problem: DOS als Singletask-System steht der Definition von TSR-Programmen diametral entgegen. Singletask bedeutet, daß nur ein Programm allein auf die Systemressourcen wie RAM-Speicher, Bildschrim, Festplatte usw. zugreift. Wenn jedoch neben dem Programm im Vordergrund noch ein TSR-Programm im Hintergrund aktiv ist muß sich das TSR-Programm mit dem BIOS, dem DOS und dem unterbrochenen Programm auseinandersetzen.

Auf unser Ziel bezogen bedeutet das: Bevor in die Datei geschrieben wird, sollte zumindest darauf geachtet werden, daß nicht gerade Disketten- oder Festplatten-zugriffe stattfinden, denn diese Abläufe gehören zu zeitkritischen Aktionen. Nicht beachtete Zugriffe auf diese Geräte können ernsthafte Störungen im System zur Folge haben, wenn man mit seinem TSR-Programm „dazwischenfunkt“. Das Problem ist sehr leicht zu beheben, indem man eine Watch-ISR für den Bios-Interrupt $13, der die Zugriffe auf Diskette und Festplatte steuert, installiert. Eine Boolean-Variable könnte dann anzeigen, ob dieser Interrupt gerade aktiv ist oder nicht, und somit anzeigen, ob die Aktion des eigenen Programms ausgeführt werden darf oder ob noch gewartet werden muß. Sicherheitshalber könnte man solche Watch-ISR`s auch für den Interrupt $10 (Bildschirm) und $16 (Tastatur) einbauen.

Eine sichere Lösung für unsere Idee gibt es wahrscheinlich nicht, da mit der Bestätigung einer Eingabe durch Return höchstwahrscheinlich immer einer der kritischen Interrupts beschäftigt ist und eine Verzögerung das System extrem verlangsamen würde. Versuche, die aktuelle Befehlszeile unter Benutzung einer anderen Tastenkombination als Indikator in eine Datei zu schreiben, zeigten teilweise Erfolge.

Eine Alternative, bei der bei jedem Tastendruck in die Datei geschrieben wird, was letztendlich auch zum Ziel führen würde, scheiterte an Zeitmangel. Die Idee, sofort in eine Datei zu schreiben, ist mit Sicherheit auch nicht die beste, da permanente Zugrif fe auf die Festplatte extrem verlangsamend und störend für das System wären. Die bessere Idee wäre die Informationen direkt in ein freies Stück Speicher zu schreiben, was viel schneller, jedoch komplizierter wäre. Außerdem müsste man diese Informationen au ch irgendwann auf der Festplatte sichern.

ENDE

Zurück