DE69224007T2

DE69224007T2 - Wiederherstellungsprozessfunktion für das OS/2-Betriebssystem

Info

Publication number: DE69224007T2
Application number: DE69224007T
Authority: DE
Inventors: Kinya Aoshima; Joseph A Meilak
Original assignee: Toshiba Corp; Toshiba America Information Systems Inc
Current assignee: Toshiba Corp; Toshiba America Information Systems Inc
Priority date: 1991-05-29
Filing date: 1992-05-29
Publication date: 1998-07-02
Anticipated expiration: 2012-05-30
Also published as: US5339426A; DE69224007D1; JP3437587B2; JPH05189075A; US5297282A; EP0516159B1; EP0516159A3; EP0516159A2

Description

Die vorliegende Erfindung bezieht sich allgemein auf ein Wiederaufnahmeverarbeitungssteuersystem zur Verwendung in einem Computersystem und insbesondere auf ein Verfahren zum Sichern des Status bzw. Betriebszustands eines Computersystems, das unter dem OS/2-Betriebssystem arbeitet, als Antwort auf ein Energieabschalt-Signal, Abschalten der Energiezufuhr zum Computersystem, und zum anschließenden Wiederzuführen von Energie zu dem Computersystem, so daß das Computersystem zu seinem ursprünglichen Zustand zurückkehrt.
In einem herkömmlichen Computersystem, wie z.B. einem "IBM-kompatiblen" Mikrocomputer auf der Basis eines 80x86- Mikroprozessors oder eines äquivalenten, werden die Inhalte von Registern und Speicherstellen, die dem zugrundeliegenden Mikroprozessor zugeordnet sind, im allgemeinen verloren, wenn die Energiezufuhr zum System abgeschaltet wird. Wenn danach die Energiezufuhr zum Computersystem wieder eingeschaltet wird, führt das System Initialisierungsschritte aus, um das System in einen Anfangszustand zu versetzen. In diesem Fall müssen jegliches Computerprogramm und begleitende bzw. zugehörige Daten wieder geladen werden, die innerhalb des Systems vorhanden waren, bevor die Energie abgeschaltet wurde.
In den letzten Jahren wurde bestimmten Computersystemen - insbesondere der Toshiba-Baureihe von Laptop-Mikrocomputern - eine "Wiederaufnahme"-Funktionalität (engl. resume functionality) hinzugefügt, um dem Computersystem zu erlauben, seine Betriebszustände zu sichern, bevor Energie abgeschaltet wird, und eine Verarbeitung an der gleichen Stelle wiederauf zunehmen, wenn anschließend Energie wieder eingeschaltet wird. Diese Funktionalität wird erreicht, indem eine Energieversorgung zum dynamischen Niederenergiespeicher (engl. low power dynamic memory) des Computers aufrechterhalten wird, während eine derartige Energiezufuhr zu den Vorrichtungen abgeschaltet wird, die eine größere Energiemenge erfordern, wie z.B. die Anzeige und die Plattenlaufwerke. Diese Funktionalität zur Erhaltung bzw. Sicherung des Energieverbrauchs erlaubt Computersystemen, die nur eine begrenzte Energieversorgung besitzen, wie z.B. batteriebetriebenen Laptop-Computern, den aktuellen Zustand des Computersystems beizubehalten, während der Betrag eines notwendigen Energieverbrauchs minimiert ist.
Zum Beispiel erlaubt das auf der Toshiba-Baureihe von Laptop-Computern beruhende eingebaute Wiederaufnahme-Merkmal (worauf als AutoResume auf diesen Maschinen verwiesen wird) dem Benutzer, den Computer auszuschalten (wobei so Batterieenergie gespart wird), ohne Daten zu verlieren. Diese Funktionalität ist in die Basis-Ein/Ausgabe-System(BIOS)-Routinen eingebaut, die man im Festwert- bzw. Nur- Lesespeicher (ROM) des Computers findet. Die Wiederaufnahmefunktion wird durch Sichern aller notwendigen Registerinformationen in einen Direktzugriffsspeicher (RAM) und Beibehalten der Energiezufuhr zu diesem Speicher erreicht, während die Energiezufuhr zu den anderen Computervorrichtungen gesperrt wird. Wenn die normale Energiezufuhr wieder eingeschaltet wird, wird die gesicherte Information an die Register zurückgegeben, und die Maschine wird in ihren vorherigen Zustand zurückgeführt.
Dieses Merkmal ist nützlich, falls der Benutzer die Maschine absichtlich abschaltet, um die Batterielebensdauer zu verlängern; aber ein zusätzlicher Vorteil ergibt sich, wenn die Batterieenergie einen kritisch niedrigen Pegel erreicht. An dieser Stelle wird die Maschine den Benutzer (z.B. durch Piepsen) warnen, daß die Batterien beinahe leer sind. Falls der Benutzer die Maschine nicht innerhalb eines gegebenen Zeitumfangs (ungefähr fünf Minuten) abschaltet, wird der Computer automatisch in einen "Wiederaufnahmemodus bzw. -betrieb" übergehen und sich selbst abschalten. Wenn eine normale Energiezufuhr wieder eingeschaltet wird, wird das BIOS den Computer ohne Datenverlust und ohne jegliche Unterbrechung in der Ausführung des vorher laufenden Programms wieder in seinen ursprünglichen Zustand versetzen.
Unglücklicherweise unterstützt der Wiederaufnahme- Verarbeitungs-BIOS-Code, der gegenwärtig in derartigen Laptops eingebaut ist, die Wiederaufnahmefunktion nur unter dem MS-DOS-Betriebssystem. Wenn es unter einem anderen Betriebssystem läuft, wie z.B. OS/2, das ein von Microsoft Corporation in Redmond, Washington, erhältliches Betriebssystem für einen Multitask-Betrieb ist, sichert die gegenwärtige BIOS-Wiederaufnahmefunktion bestimmte Register und andere Daten, die durch OS/2 genutzt werden, nicht richtig, und die Operation der Wiederaufnahmefunktion scheitert daher. Dies beruht zum Teil auf der Tatsache, daß das OS/2- Betriebssystem entworfen wurde, um auf einem Computersystem zu arbeiten, das einen 80286-Mikroprozessor für mehrere Betriebsarten oder einen mit dem 80286 abwärts kompatiblen Mikroprozessor, wie z.B. den 80386, 80486 etc., nutzt. Andererseits wurde das MS-DOS-Betriebssystem entworfen, um auf einem nur einen Modus bzw. Betrieb nutzenden 8086/8088- Mikroprozessor zu arbeiten.
Um das bestehende, in solchen Computern vorliegende Wiederaufnahmeverarbeitungs-BIOS zu nutzen, muß folglich ein "Wrapper bzw. Umschlag" (engl. wrapper) um das BIOS erzeugt werden, um den Computer in einen Zustand zu versetzen, in dem das BIOS seine Wiederaufnahmeverarbeitungsfunktionen ausführen kann. Die vorliegende Erfindung ist geeignet, eine solche Funktionalität zu leisten.
EP-A-0 404 016 offenbart einen eine Wiederaufnahmefunktion aufweisenden und auf einer internen Batterie betreibbaren Computer, der mit einer Schaltung zum Prüfen der Ausgangsspannung der Batterie und einem Controller bzw. einer Steuereinheit ausgestattet ist. Wenn die Ausgangsspannung der internen Batterie während einer Datenverarbeitung gleich oder geringer als ein vorbestimmter Wert wird, wird eine Wiederaufnahmeverarbeitung zum Datenschutz ohne Rücksicht darauf ausgeführt, ob ein Wiederaufnahmebetrieb auf EIN oder AUS geschaltet ist, und der Inhalt der im Gange befindlichen Datenverarbeitung wird gesichert. Wenn die Ausgangsspannung der internen Batterie wieder auf einen Pegel eingestellt ist, der größer als der vorbestimmte Wert ist, wird auf der Basis des gesicherten Inhalts die Datenverarbeitung wiederaufgenommen.
Demgemäß besteht eine Aufgabe der vorliegenden Erfindung darin, eine Wiederaufnahmeverarbeitungsfunktion zur Verwendung mit einem fortgeschrittenen Betriebssystem, wie z.B. OS/2, zu schaffen.
Eine weitere Aufgabe der vorliegenden Erfindung ist, eine Wiederaufnahmeverarbeitungsfunktion zur Verwendung mit OS/2 in Verbindung mit einer vorhandenen Wiederaufnahmeverarbeitungsroutine, wie z.B. der eine Wiederaufnahmeverarbeitungs-BIOS-Routine in MS-DOS, zu schaffen.
Noch eine weitere Aufgabe der vorliegenden Erfindung ist, eine Wiederaufnahmeverarbeitungsfunktion zu schaffen, die als ein "Umschlag" um eine vorhandene Wiederaufnahmeverarbeitungsroutine dient.
Noch eine andere Aufgabe der vorliegenden Erfindung besteht darin, eine Wiederaufnahmeverarbeitungsfunktion zu schaffen, die Daten sichert, die die Betriebszustände des Betriebssystems angeben, bevor eine vorhandene Wiederaufnahmeverarbeitungsroutine aufgerufen wird.
Noch eine weitere Aufgabe der vorliegenden Erfindung besteht darin, eine Wiederaufnahmeverarbeitungsfunktion zu schaffen, die Daten zurückspeichert bzw. wiederherstellt, die die Betriebszustände des Betriebssystems angeben, nachdem eine vorhandene Wiederaufnahmeverarbeitungsroutine ausgeführt worden ist.
Noch eine andere Aufgabe der vorliegenden Erfindung ist, eine Wiederaufnahmeverarbeitungsfunktion zu schaffen, die arbeiten kann, während sowohl ein Plattenlaufwerk als auch ein paralleler Printerport aktiv sind.
Gemäß der vorliegenden Erfindung wird ein Verfahren nach Anspruch 1 geschaffen. Demgemäß wird ein Wiederaufnahmeverarbeitungstreiber für ein fortgeschrittenes Betriebssystem, wie z.B. OS/2, geschaffen, der die Betriebszustände des fortgeschrittenen Betriebssystems angebende Daten in einen Systemspeicher sichert und dann eine vorher vorhandene Wiederaufnahmeverarbeitungsroutine aufruft, die für ein vorher vorhandenes Betriebssystem, wie MS-DOS, entworfen wurde. Die vorher vorhandene Wiederaufnahmeverarbeitungsroutine führt eine zusätzliche Verarbeitung durch, um mit dem vorher vorhandenen Betriebssystem verbundene Betriebszustandsdaten in einen Systemspeicher zu sichern, und führt dann eine gesteuerte Abschalt-Sequenz aus und schaltet die Energiezufuhr zu allen Elementen des Computers, mit Ausnahme des Computerspeichers, ab. Danach führt die vorhandene Wiederaufnahmeverarbeitungsroutine eine Verarbeitung durch, um die mit dem vorher vorhandenen Betriebssystem verbundenen Betriebszustandsdaten vom Systemspeicher zurückzuspeichern bzw. wiederherzustellen, und übergibt dann die Steuerung an den Wiederaufnahmeverarbeitungstreiber der vorliegenden Erfindung. Der Wiederaufnahmeverarbeitungstreiber stellt die die Betriebszustände des fortgeschrittenen Betriebssystems angebenden Daten vom Systemspeicher wieder her, und dann geht die Steuerung an das Computerprogramm über, welches ausgeführt wurde, bevor der Wiederaufnahmeverarbeitungstreiber initiiert wurde.
Diese Erfindung kann aus der folgenden ausführlichen Beschreibung vollständiger verstanden werden, wenn sie in Verbindung mit den beigefügten Zeichnungen vorgenommen wird, in denen:
Fig. 1 ein Blockdiagramm ist, das die verschiedenen Komponenten eines Computersystems zeigt, mit dem der OS/2- Wiederaufnahmevorrichtungstreiber der vorliegenden Erfindung in einer bevorzugten Ausführungsform arbeiten kann;
Fig. 2 ein Flußdiagramm ist, das sieben (7) allgemeine Schritte zeigt, die die vorliegende Erfindung in einer bevorzugten Ausführungsform ausführt;
Fig. 3 ist ein Blockdiagramm, das den Prozeß eines "Einsteigens" (engl. hooking) des nicht-maskierbaren Unterbrechung-(NMI)-Vektors des Realbetriebs gemäß der vorliegenden Erfindung darstellt;
Fig. 4 ein Blockdiagramm ist, das den Prozeß eines "Einsteigens" in den NMI-Vektor des geschützten Betriebs gemäß der vorliegenden Erfindung darstellt;
Fig. 5 ein Flußdiagramm ist, das die verschiedenen Schritte zeigt, die notwendig sind, um den OS/2-Wiederaufnahmevorrichtungstreiber, einschließlich eines Installierens eines Zeitgeber-Steuerprogramms (engl. timer handler), gemäß einer bevorzugten Ausführungsform der vorliegenden Erfindung zu installieren;
Fig. 6 ein Flußdiagramm ist, das die verschiedenen Schritte, die durch das Zeitgeber-Steuerprogramm von Fig. 5 ausgeführt werden, welches notwendig ist, um in die NMI- Vektoren des Realbetriebs und des geschützten Betriebs "einzusteigen", die in Fig. 3 und 4 dargestellt sind, in einer bevorzugten Ausführungsform der vorliegenden Erfindung darstellt; und
Fig. 7A und 7B Flußdiagramme sind, die die verschiedenen Schritte darstellen, welche ausgeführt werden, wenn der Wiederaufnahmetreiber der vorliegenden Erfindung aufgerufen wird.
Um die folgende ausführliche Beschreibung richtig zu beurteilen, werden nun die folgenden Ausdrücke definiert.
A-20-GATTER: Ein Gatter innerhalb der Tastatursteuereinheit, das eine Adreßleitung 20 freigibt oder sperrt. Die Adreßleitung 20 kann unter MS-DOS je nachdem freigegeben oder gesperrt werden, ob ein Programm einen Zugriff auf ein zusätzliches 64K-Speichersegment oberhalb 1 Mbyte benötigt. OS/2 benötigt jedoch gewöhnlich diese Adreßleitung freigegeben, weil Basisvorrichtungstreiber oberhalb des 1-MByte-Segments liegen.
COM-TREIBER: Ein COM-Treiber ist ein Porttreiber für eine asynchrone Nachrichtenübertragung.
CPU: Die zentrale Verarbeitungseinheit (engl. central processing unit) ist ein Mikroprozessor, der die zentrale Steuerschaltung im Computersystem bildet. Zum Zwecke der vorliegenden Erfindung weist die CPU einen Mikroprozessor auf, der in fortgeschrittenen Betriebsarten arbeiten kann, wie z.B. einem geschützten Betrieb, und der ein fortgeschrittenes Betriebssystem, wie z.B. OS/2, laufenlassen kann.
DESKRIPTORTABELLE: Eine Deskriptortabelle ist eine Tabelle, die Selektoren auf physikalische Speicheradressen abbildet. Solche Tabellen werden von fortgeschrittenen Mikroprozessoren verwendet, wie z.B. dem Intel 80286, um Segmente eines Speichers für eine Verwendung des Computerprogramms zu definieren. Es gibt zwei Typen von Tabellen, die für die vorliegende Erfindung von Bedeutung sind: die lokale Deskriptortabelle (LDT) und die globale Deskriptortabelle (GDT). Eine LDT existiert für jeden aktiven Prozeß und erlaubt einen Zugriff auf einen Speicher, der durch diesen Prozeß besetzt oder gemeinsam genutzt wird. Die GDT erlaubt einen Zugriff auf einen Speicher, der durch das Betriebssystem und die Vorrichtungstreiber genutzt wird.
EINSTIEG oder EINSTEIGEN in eine Unterbrechung: Einsteigen in eine Unterbrechung bezieht sich auf den Vorgang eines Umleitens der CPU, um auf ein neues Unterbrechungs-Steuerprogramm zuzugreifen. Der tatsächliche "Einstieg" muß durchgeführt werden, bevor die Unterbrechung auftritt. Dies wird typischerweise vorgenommen, indem die Adresse des neuen Steuerprogramms an der geeigneten Stelle in einer Unterbrechungsvektortabelle plaziert wird. Dies ist jedoch mit der NMI-Unterbrechung der Intel-80286-kompatiblen Mikroprozessor- Baureihe nicht immer möglich, bei der der Betriebssystemkern die Unterbrechungsvektortabelle dauernd überwacht und die Adresse des ursprünglichen Steuerprogramms wiederherstellt, falls irgendein anderes Programm sie ändert. Um in die NMI-Unterbrechung einzusteigen, plaziert daher die vorliegende Erfindung eine "Sprung"-Mikroprozessoranweisung am Beginn des ursprünglichen Steuerprogramms, das eine Ausführung an den Wiederaufnahmeverarbeitungstreiber der vorliegenden Erfindung weitergibt.
I/O-KANALPRÜFUNG oder PARITÄTSFEHLER: Dies ist ein durch eine Erweiterungskarte verursachter schwerer Systemfehler, wobei ein I/O-Paritätsfehler in der Hardware festgestellt wird.
NMI: Eine nicht-maskierbare Unterbrechung (engl. non-maskable interrupt) ist eine, die durch die CPU nicht ignoriert werden kann, obwohl sie extern gegen die CPU abgeschirmt bzw. ausgeblendet (engl. masked off) sein kann. Auf dem Laptop-Computer Toshiba T3100SX gibt es z.B. zwei Wege, auf denen eine NMI erzeugt werden kann: (1) durch einen I/O-Kanalprüfungsfehler oder (2) durch eine Energieabschalt-Anforderung, wie sie ge mäß der vorliegenden Erfindung beschrieben ist.
PIC: Eine programmierbare Unterbrechungs-Steuereinheit (engl. programmable interrupt controller) ist eine Schaltung, die steuert, welche Unterbrechungen zu irgendeiner gegebenen Zeit freigegeben/gesperrt werden.
WIEDERAUFNAHME oder WIEDERAUFNEHMEN: Wiederaufnehmen ist der Vorgang eines Abschaltens der Energiezufuhr zum Computer (außer für den Speicher) und ihres Wiedereinschaltens zu einem späteren Zeitpunkt, während der Softwarezustand der Maschine bewahrt wird.
Ring: Der Ring ist die Privileg-Ebene, die durch die 80286-kompatible Baureihe von Mikroprozessoren erkannt wird, unter denen ein Ausführungsprogramm arbeiten kann. Ein OS/2-Code kann bei einer von drei Ebenen ablaufen: 0, 2 und 3. Ebene 1 wird nicht genutzt. Die aktuelle Privileg-Ebene bestimmt, auf welche Anweisungen und Speichersegmente zugegriffen werden kann.
SELEKTOR: Ein Selektor ist ein Wert, der im geschützten Betrieb eines fortgeschrittenen Mikroprozessors, wie z.B. der 80286-kompatiblen Mikroprozessor- Baureihe, verwendet wird, der in ein Segmentregister geladen werden kann, um auf ein physikalisches Speichersegment Bezug zu nehmen. Der Selektor wird als ein Index in eine Deskriptortabelle (entweder die LDT oder die GDT) verwendet.
VERTEILT: Ein verteilter (engl. tiled) Speicheradreßwert ist in sowohl einem Realbetrieb (als ein Segment) als auch in einem geschützten Betrieb (als ein Selektor) gültig. Der Systemlader ist ein Beispiel eines Codesegments, das verteilt ist.
In einer bevorzugten Ausführungsform beinhaltet die Implementierung der vorliegenden Erfindung ein (1) Erzeugen eines Wiederaufnahmetreibers, der unter dem Betriebssystem OS/2 Version 1.2 arbeiten kann, um in den NMI-Unterbrechungsvektor einzusteigen und auch als ein Umschlag um den Wiederaufnahme-BIOS-Code zu dienen, (2) Modifizieren des Systemladers, um einen Einstieg in die nicht-maskierbare Unterbrechung (NMI) im Realbetrieb einzufügen, wodurch es mit der vorliegenden Erfindung möglich wird, unter einer DOS-Kompatibilitätsbox von OS/2 zu arbeiten, (3) Modifizieren des Systeminitialisierungsprozesses, um die Wiederaufnahmetreiber-Ladeanweisung in der Datei "CONFIG.SYS" zu plazieren, wenn sie auf einer geeigneten Maschine installiert wird, und (4) Modifizieren des Plattentreibers, um dem Wiederaufnahme-BIOS zu signalisieren, wann eine Plattenaktivität abgeklungen ist bzw. geendet (engl. subsided) hat, so daß die Energie ohne Verlieren von Plattenpuffern oder Daten abgeschaltet werden kann. Wie in der ausführlichen Diskussion im folgenden erläutert wird, werden all diese Komponenten geschrieben oder modifiziert werden müssen, um die Wiederaufnahmefunktion unter der OS/2-Version 1.2 vollständig zu unterstützen; der Fachmann wird jedoch ohne weiteres verstehen, daß die beschriebenen Modifikationen und Zusätze nur eine Implementierung der vorliegenden beanspruchten Erfindung definieren und daß andere offensichtliche Variationen aus der Diskussion einleuchtend sein werden.
Wie der Fachmann für Computerprogrammierung auch ohne weiteres versteht, können die obigen Komponenten durch Schreiben oder Modifizieren von Computerprogrammen implementiert werden, die in einer von verschiedenen Computersprachen geschrieben sind. In der bevorzugten Ausführungsform wird eine 80x86-kompatible Assemblersprache (Maschinensprache) verwendet, um die vorliegende Erfindung zu implementieren, weil die vorliegende Erfindung als ein Vorrichtungstreiber implementiert wird. Implementiert man z.B. den Wiederaufnahmetreiber, wäre es jedoch denkbar, daß jede andere geeignete Sprache ebenfalls verwendet werden könnte. Im Rahmen dieser ausführlichen Beschreibung wird angenommen, daß, wenn nicht anders erwähnt, eine Assemblersprache verwendet wird.
Der Microsoft Macro-Assembler Version 5.10 und das segmentiert ausführbare Binderprogramm von Microsoft, Version 5.03, (beide von Microsoft Corporation in Redmond, Washington, erhältlich) können auch verwendet werden, um den Vorrichtungstreiber und einen anderen Quellencode der vorliegenden Erfindung zu assemblieren und zu verbinden, obwohl auch andere ähnliche Produkte verwendet werden könnten.
Außerdem werden die obigen Komponenten ohne weiteres durch die Verwendung des binären Anpassungsbausatzes (BAK) (engl. Binary Adaptation Kit) und verwandter Softwaretools und Handbücher geprüft und modifiziert, die von Microsoft Corporation in Redmond, Washington, den Autoren des Betriebssystems OS/2, erhältlich sind. Der BAK enthält den binären Anpassungsführer (BAG), der eine Dokumentation darüber liefert, wie die Modifikationen und der Zusatz zu implementieren sind, die in dieser Spezifikation beschrieben sind. Zusätzlich zu dieser Dokumentation könnten sich weitere Bücher als nützlich erweisen, wenn man die vorliegende Erfindung implementiert, wie z.B. das Buch "Advanced OS/2 Programming" von Ray Duncan, das von Microsoft Press in Redmond, Washington, erhältlich ist.
Wenn man eine Implementierung der vorliegenden Erfindung austestet, kann schließlich das von Microsoft auch erhältliche Kern-Diagnose- bzw. -Testhilfeprogramm verwendet werden, um Fehler innerhalb des Treibers zu lokalisieren. Man denke jedoch immer daran, daß man unter Verwendung dieses Testhilfeprogramms nicht in den NMI-Unterbrechungsvektor des Realbetriebs einsteigen kann, weil es selbst in diesen Vektor einsteigt. Daher muß ein Austesten der NMI- Verarbeitung des Realbetriebs durch eine Sichtprüfung des Codes oder durch strategisches Plazieren von Halt-Anweisungen im Code vorgenommen werden, um zu sehen, ob der Ausführungsweg einen bestimmten Weg kreuzt.
Um den Wiederaufnahmetreiber der vorliegenden Erfindung vollständig zu testen, muß in sowohl dem geschützten Betrieb als auch dem Realbetrieb ein I/O-Kanalprüffehler erzeugt werden. Weil dies etwas ist, das mit Software nicht herstellbar ist und normalerweise mit Hardware nicht herstellbar ist, kann ein Erweiterungsgehäuse verwendet werden, um diese Funktion auszuführen. In der bevorzugten Ausführungsform kann das Toshiba-Erweiterungsgehäuse mit einer Erweiterungskarte mit einem auf die Al-Leitung gelöteten Draht verwendet werden und mit dem Erweiterungsverbinder des Computers (Element 119 in Fig. 1) verbunden werden. Um eine I/O-NMI nach Wunsch zu erzeugen, kann der Al-Draht kurz geerdet werden, was sofort eine I/O-Kanalprüfung-NMI erzeugen wird.
Fig. 1 ist ein Blockdiagramm, das einem Mikrocomputer entspricht, mit dem die vorliegende Erfindung in einer bevorzugten Ausführungsform arbeiten kann. Der in Fig. 1 dargestellte spezifische Mikrocomputer kann irgendeiner einer Anzahl von Mikrocomputern sein, die eine "intelligente" Energieversorgung besitzen und OS/2 laufenlassen können, wie z.B. die "Laptop"-Computer T3100SX oder T2000SX von Toshiba. Obgleich die in dieser Figur dargestellte spezifische Konfiguration von Computer zu Computer verschieden sein kann, werden die relevanten Teile des Computersystems, die für die Operation der vorliegenden Erfindung notwendig sind (einschließlich der "intelligenten" Energieversorgung), im wesentlichen die gleichen bleiben, und daher versteht es sich, daß Fig. 1 nur zu Veranschaulichungszwecken eingeschlossen ist.
Bezugnehmend auf Fig. 1, ist ein Systembus 100 mit Systemkomponenten 101 bis 125 verbunden. Eine zentrale Verarbeitungseinheit (CPU) 101, die in einer bevorzugten Ausführungsform aus einem Intel-80286-kompatiblen Mikroprozessor bestehen kann, der das Betriebssystem OS/2 Version 1.2 laufenlassen kann, steuert das Arbeiten des gesamten Computersystems von Fig. 1. In der bevorzugten Ausführungsform führt die CPU 101 die in den Flußdiagrammen der Fig. 5, 6, 7A und 7B skizzierten Funktionen aus, die im folgenden ausführlich beschrieben werden. Außerdem dient die CPU 101 als eine Host-CPU bezüglich einer CPU 117A zur Energiesteuerung, die das Herz der Energiequellenschaltung 117 bildet, welche ebenfalls unten ausführlich beschrieben wird.
Ein Nur-Lesespeicher (ROM) 102 speichert feste Computerprogramme und begleitende bzw. zugehörige Daten, einschließlich des ROM-Basis-Ein/Ausgabe-Systems (BIOS) (das nicht explizit dargestellt ist). In einer bevorzugten Ausführungsform speichert das ROM-BIOS ein Wiederaufnahmeverarbeitungsprogramm, das mit dem Realbetrieb der CPU 101 arbeiten kann. Zum Beispiel verwendet der von Toshiba Corporation erhältliche Laptop-Computer T3100SX den 80386SX- Mikroprozessor als CPU 101 und besitzt ein Wiederaufnahmeverarbeitungsprogramm innerhalb seines ROM 12, das ausgelegt ist, um zu arbeiten, wenn der 80386SX-Mikroprozesor in seinem Realbetrieb ist.
Ein Direktzugriffsspeicher (RAM) 103 speichert modifizierbare Programme und Daten, die durch die CPU 101 verarbeitet werden sollen. Außerdem speichert der RAM 103 ein Wiederaufnahmebetrieb-Flag, das einem ausführenden Programm anzeigt, ob eine Wiederaufnahmeverarbeitung verwendet werden soll. Dieses Flag wird im folgenden ausführlich erläutert.
Eine Direktspeicherzugriff-(DMA)-Steuereinheit 104 steuert direkte Speicherzugriffe zwischen verschiedenen Komponenten des Mikrocomputersystems. Eine programmierbare Unterbrechungs-Steuereinheit (PIC) 105 steuert, welche Mikroprozessorunterbrechungen zu irgendeiner gegebenen Zeit freigegeben werden und durch ein auf der CPU 101 ausführendes Computerprogramm modifiziert werden können. Ein programmierbarer Intervallzeitgeber (PIT) 106 kann durch ein ausführendes Computerprogramm eingestellt werden und zählt ein bestimmtes Zeitintervall herunter. Eine Echtzeituhr (RTC) 107 hält und liefert die aktuelle Tageszeit an die CPU 101 und hat eine fest zugeordnete Energieversorgung 107A (z.B. eine Batterie), um sie betriebsfähig zu halten, wenn die Energieversorgung zum Mikroprozessorsystem abgestellt wird.
Ein Erweiterungs-RAM 108 mit einer relativ großen Speicherkapazität kann in einen zweckbestimmten Kartenschlitz des Hauptkörpers des Mikrocomputers eingeführt werden und wird mit einer Sicherungsenergieversorgung VBK versorgt. Wiederaufnahmefunktionsdaten können in einem Sicherungs-RAM 109 gespeichert werden, der auch mit einer Sicherungsenergie VBK versorgt wird.
Ein Festplattenstapel kann in einem zweckbestimmten Gehäuseteil des Hauptkörpers des Mikrocomputersystems herausnehmbar eingesetzt werden und umfaßt in einer bevorzugten Ausführungsform ein Festplattenlaufwerk (HDD) 110B mit 3,5 Zoll und eine Festplattensteuereinheit (HDC) 110A zum Steuern eines Zugriffs auf das Laufwerk. Die folgenden Steuereinheiten steuern einen Zugriff auf ihre jeweiligen Gegenstücke und verbinden diese mit dem Bus 100: eine Diskettensteuereinheit (FDC) 111A verbindet ein Diskettenlaufwerk (FDD) 111B und/oder ein wahlweises externes Diskettenlaufwerk (externes FDD) 111C; eine Druckersteuereinheit (PRT- CONT) 112A verbindet einen wahlfreien Drucker 112B; eine universelle asynchrone Parallel-Seriell-Schnittstelle (UART) 113A verbindet eine wahlweise RS-232C-Schnittstelleneinheit 113B; eine Tastatursteuereinheit (KBC) 114A verbindet eine Tastatur 114B; und eine Anzeigesteuereinheit (DISP-CONT) 115A verbindet eine Gasplasmaanzeige (PDP) 115B und eine wahlfreie Kathodenstrahlröhre (CRT) 115D.
Mit DISP-CONT 115A ist ein Bildspeicher bzw. Bild-RAM (VRAM) 115C zum Speichern von Anzeigebuddaten verbunden. Der VRAM 115C wird mit einer Sicherungsenergieversorgung VBK versorgt.
Eine Energiequellen-Steuerschnittstelle (PS-IF) 116 verbindet eine Energiequellenschaltung 117 durch den Systembus 100 mit der CPU 101. Wenn die Energiesteuerung-CPU (PC-CPU) 117A durch eine Aktivierung bzw. Betätigung eines Schalters SW eine Anzeige vom Benutzer des Mikrocomputersystems empfängt, veranlaßt die Energiesteuerung-CPU 117S die Energiequellenschaltung 117, durch PS-IF 116 ein nicht- maskierbares Unterbrechungs-(NMI)-Signal an die CPU 101 zu senden. Außerdem kann ein NMI-Signal durch eine Energiequellenschaltung 117 erzeugt werden, wenn die durch die Hauptbatterie (M-BATT) 117B gelieferte Energie (wird unten diskutiert) unter einen kritisch niedrigen Pegel fällt.
Ein AC-Adapter 118 richtet eine handelsüblich erhältliche Wechselstrom-(AC)-Energiequelle gleich und glättet sie, um eine Gleichstrom-Energiequelle einer bestimmten Spannung zu erhalten. Der AC-Adapter 118 ist mit der Energiequellenschaltung 117 verbunden, die Energie an die jeweiligen Komponenten des Mikrocomputersystems liefert.
Eine in einer bevorzugten Ausführungsform aus einer herausnehmbaren wiederaufladbaren Batterie bestehende Hauptbatterie (M-BATT) 117B ist mit der Energiequellenschaltung 117 verbunden. Eine Nebenbattene (S-BATT) 117C, die in einer bevorzugten Ausführungsform aus einer an der Innenseite des Computerkörpers angebrachten wiederaufladbaren Batterie besteht, arbeitet als eine sekundäre Batterie und ist mit der Energiequellenschaltung 117 verbunden.
Schließlich ist mit dem Bus 100 ein Erweiterungsverbinder 119 verbunden, um eine Verbindung von externen Schaltungsanordnungen und Komponenten zu ermöglichen.
In Fig. 2 ist ein Flußdiagramm dargestellt, daß den Gesamtablauf der Wiederaufnahmeverarbeitungsfunktion der vorliegenden Erfindung darstellt. Während des Betriebsablaufs der vorliegenden Erfindung in einer bevorzugten Ausführungsform treten konkret sieben (7) allgemeine Schritte auf, die in Fig. 2 als Schritte 201 bis 207 dargestellt sind. Diese sieben Schritte werden unten allgemein und später mit Verweis auf Fig. 7A und 7B in weiteren Einzelheiten beschrieben.
Zuerst verweist Schritt 201 mit dem Titel "Aktive Aufgabe, wenn Wiederaufnahme-NMI auftritt" auf den Zustand, in dem das Computersystem arbeitet, wenn ein Signal, um eine Wiederaufnahmeverarbeitung zu beginnen, empfangen wird. Im einzelnen kann ein Computerprogramm gerade unter einem der Vielzahl von Betriebsarten der Host-CPU (Element 101 in Fig. 1) arbeiten, wenn durch die CPU ein Abschalt-Signal empfangen wird. Das Abschalt-Signal wird durch die Energiequellenschaltung (Element 117 in Fig. 1) erzeugt, wenn der Benutzer des Computersystems den geeigneten Energieschalter (Element SW in Fig. 1) aktiviert bzw. betätigt. Das Abschalt-Signal nimmt die Form einer nicht-maskierbaren Unterbrechung (NMI) ein, die auf der CPU erzeugt wird.
Schritt 202 mit dem Titel "Wiederaufnahmetreiber (RESUME$)" nimmt auf den Wiederaufnahmeverarbeitungstreiber Bezug, der ausgeführt wird, nachdem die NMI durch die CPU festgestellt ist. In einer bevorzugten Ausführungsform nimmt der Wiederaufnahmetreiber die Form eines installierbaren Vorrichtungstreibers ein, der geladen wird, wenn der Computer zuerst initialisiert wird. Genauer gesagt, wird der Dateiname des Treibers in die Konfigurationsdatei "CONFIG.SYS" mit der "DEVICE="-Anweisung plaziert und wird geladen, wenn das Computersystem zu Anfang urgeladen bzw. gebootet wird. Es ist wichtig, zu beachten, daß der Wiederaufnahmeverarbeitungstreiber der vorliegenden Erfindung möglicherweise genauso gut auch als Teil der OS/2-"Basistreiber" (z.B. Teil von BASEDD01) oder als Teil der OS/2- OEMHLP-Treiber implementiert werden könnte. Um den Umfang eines Neuentwurfs des aktuellen OS/2-Systems zu minimieren, und weil der Wiederaufnahmeverarbeitungstreiber der vorliegenden Erfindung so konstruiert ist, um mit einem bestimmten Maschinentyp genutzt zu werden, nimmt jedoch der Wiederaufnahmeverarbeitungstreiber der vorliegenden Erfindung gemäß der bevorzugten Ausführungsform die Form eines installierbaren Vorrichtungstreibers ein. Der Fachmann wird jedoch die verschiedenen Wege erkennen, auf denen die vorliegende Erfindung implementiert werden könnte.
Wieder auf Schritt 202 Bezug nehmend, wird der Wiederaufnahmeverarbeitungstreiber der vorliegenden Erfindung ausgeführt, nachdem die NMI durch die CPU festgestellt ist und bestimmt ist, daß die NMI ein Ergebnis davon ist, daß der Schalter zum Abschalten gedrückt wurde. An dieser Stelle führt der Wiederaufnahmetreiber verschiedene Schritte aus, um bestimmte Typen von Daten, die mit OS/2 verbunden sind, in geeignete Bereiche im Speicher des Computersystems richtig zu sichern. Nachdem dies durchgeführt ist, überträgt dann der Wiederaufnahmetreiber die Steuerung an einen vorher vorhandenen ROM-BIOS-Wiederaufnahmecode, der weitere Wiederaufnahmeverarbeitungsfunktionen ausführt und dann die Energiezufuhr zu den verschiedenen Komponenten des Computersystems, mit Ausnahme des Speichers, physikalisch abschaltet. Der Wiederaufnahmetreiber der vorliegenden Erfindung, der in Schritt 202 dargestellt ist, dient somit als "Umschlag" um das vorher vorhandene ROM-BIOS, das gegenwärtig in verschiedenen Computersystemen gefunden wird, wie z.B. Laptops von Toshiba. Das heißt, der Wiederaufnahmetreiber sichert die Register und Daten, die dem OS/2- Betriebssystem und/oder den fortgeschrittenen Mikroprozessor eigen sind, auf dem OS/2 arbeitet, und versetzt das Computersystem in einen Zustand, in dem die Standard-ROM- BIOS-Wiederaufnahmeverarbeitungsroutine ihre Funktionalität richtig ausführen und danach Energie zu den verschiedenen Komponenten abstellen kann.
Schritt 203 von Fig. 2 mit dem Titel "ROM-BIOS-Wiederaufnahmecode" nimmt auf die ROM-BIOS-Wiederaufnahmecoderoutinen Bezug, die ausgeführt werden, nachdem der Wiederaufnahmetreiber der vorliegenden Erfindung ausgeführt ist, wie vorher beschrieben wurde. In der bevorzugten Ausführungsform ist der ROM-BIOS-Wiederaufnahmecode so gestaltet, daß er alle notwendigen Register und Daten sichert, die mit der CPU (Element 101 von Fig. 1) des Computersystems verbunden sind, wenn sie im "Realbetrieb" arbeitet. Daher versetzt, bevor der Wiederaufnahmetreiber in Schritt 202 die Steuerung an den ROM-BIOS-Wiederaufnahmecode von Schritt 203 überträgt, der Wiederaufnahmetreiber der vorliegenden Erfindung die CPU in den Realbetrieb, falls sie nicht schon in diesem Modus arbeitet. Der Prozeß wird später in weiteren Einzelheiten beschrieben.
Nachdem der ROM-BIOS-Wiederaufnahmecode alle notwendigen Schritte ausführt, um die Register und Daten zu sichern, die mit dem Realbetrieb verbunden sind, trifft man auf Schritt 204 mit dem Titel "Computer schaltet ab und schaltet gegebenenfalls ein". In der bevorzugten Ausführungsform besteht dieser Schritt aus einem "Wegnehmen" (engl. removing) von Energie von allen Komponenten des Computersystems, mit Ausnahme natürlich des Systemspeichers, der die vorher gesicherten Register und Daten speichert, die mit dem Zustand des Computersystems verbunden sind. Unter der Leitung der CPU wird durch die Energiequellenschaltung (Element 117 in Fig. 1) Energie "weggenommen" bzw. abgestellt. Wenn der Benutzer zu einer späteren Zeit den Energieschalter (Element SW in Fig. 1) niederdrückt, wird die Energiequellenschaltung wieder Energie an die verschiedenen Komponenten des Computersystems liefern, und dann wird die Steuerung auf Schritt 205 übertragen.
Schritt 205 mit dem Titel "ROM-BIOS-Wiederaufnahmecode" führt die entgegengesetzte Funktion wie Schritt 203 aus und nimmt auf die gleichen ROM-BIOS-Wiederaufnahmeroutinen von Schritt 203 Bezug, die ausgeführt wurden, als in Schritt 204 Energie "weggenommen" wurde. Der Schritt 205 besteht aus einem Zurückspeichern bzw. Wiederherstellen der vorher gesicherten Register und Daten, die mit dem Realbetrieb des Mikroprozessors verbunden sind, und dann einem Rückübertragen der Steuerung an den Wiederaufnahmetreiber in Schritt 206. Wie vorher erläutert wurde, besteht der ROM-BIOS-Code von Schritt 205 aus einem Code, der vorher in Toshiba- Computern gefunden wurde, wie z.B. dem Laptop-Computer T3100SX.
Schritt 206 mit dem Titel "Wiederaufnahmetreiber (RESUME$)" führt die entgegengesetzte Funktion wie Schritt 202 aus und wird durch den gleichen Treiber wie in Schritt 202 ausgeführt. Schritt 206 besteht aus einem Wiederherstellen der vorher gesicherten Register und Daten, die mit OS/2 und den betreffenden fortgeschrittenen Betriebsarten des 80286-kompatiblen Mikroprozessors verbunden sind. Nach dem Schritt 206 abgeschlossen ist, wird dann die Steuerung an Schritt 207 mit dem Titel "Aktive Aufgabe, als Wiederaufnahme-NMI auftrat" weitergeleitet, der auf das Programm Bezug nimmt, welches gerade ausgeführt wurde, als der Energieschalter ursprünglich niedergedrückt wurde, um den Wiederaufnahmeprozeß in Schritt 201 zu beginnen. An dieser Stelle wird das vorher ablaufende Programm wieder aufgenommen.
Um die Wiederaufnahmefunktionalität der vorliegenden Erfindung zu unterstützen, muß, wie vorher beschrieben wurde, die vorliegende Erfindung notwendigerweise in die nicht-maskierbare Unterbrechung (NMI) (Unterbrechung 2) "einsteigen", um auf den Wiederaufnahmevorrichtungstreiber zu zeigen, um festzustellen, wann der Benutzer des Computersystems den Energieschalter (Element SW in Fig. 1) gedrückt hat. Dies ist jedoch mit dem NMI-Unterbrechung- Steuerprogramm nicht möglich, weil der Systemkern die Unterbrechungsvektortabelle dauernd überwacht und die ursprüngliche Adresse des Steuerprogramms wiederherstellt, falls irgendein anderes Programm sie ändert. Um diese Beschränkung zu umgehen, muß der Wiederaufnahmetreiber der vorliegenden Erfindung notwendigerweise über den OS/2-Lader und Kerncode "schreiben bzw. korrigieren" (engl. patch), um in die NMI-Unterbrechung für den Realbetrieb und den 80286- geschützten Betrieb einzusteigen. Diese Vorgehensweise wird zwar normalerweise als kein gutes Verfahren betrachtet, sie muß aber in einer bevorzugten Ausführungsform ausgeführt werden, weil es unmöglich ist, die Vektortabellen direkt zu modifizieren. Die mit einem "Einsteigen" (z.B. Korrigieren) der NMI-Unterbrechungen verbundenen Einzelheiten werden bezüglich der Fig. 3 und 4 unten beschrieben. Falls es in einer späteren OS/2-Version möglich wird, die Unterbrechungsvektoreinträge direkt zu modifizieren, wird dann der hierin beschriebene Korrekturprozeß natürlich unnötig, und eine direkte Modifikation der Vektoreinträge kann vorgenommen werden.
Der Initialisierungscode für den Wiederaufnahmetreiber der vorliegenden Erfindung ist für ein "Einsteigen" in die NMI-Vektoren des Realbetriebs und geschützten Betriebs verantwortlich. Der NMI-Vektor des Realbetriebs befindet sich innerhalb der Unterbrechungsvektortabelle (IVT), und der NMI-Vektor des geschützten Betriebs befindet sich innerhalb der Unterbrechungsdeskriptortabelle (IDT). Wie oben beschrieben wurde, überwacht der OS/2-Kern diese Tabelle routinemäßig und überschreibt jegliche neuen Werte, die innerhalb der Tabelle plaziert sind, nachdem er geladen ist. Daher besteht, wie vorher beschrieben wurde, statt die Stelle der Unterbrechungs-Steuerprogramme direkt zu ändern, wie in der IVT und IDT spezifiziert, eine alternative Lösung darin, die ursprünglichen Vektoren intakt zu lassen und statt dessen die ersten Schritte jedes Steuerprogramms zu modifizieren, um eine Maschinensprachanweisung für einen weiten Sprung zum Wiederaufnahmetreiber der vorliegenden Erfindung auszuführen. Dieses Verfahren geht davon aus, daß wir nie zum ursprünglichen Steuerprogramm zurückspringen müssen, weil es diesen Code tatsächlich überschreibt. Dies ist akzeptabel, weil der Wiederaufnahmetreiber der vorliegenden Erfindung alle Aspekte irgendeines NMI-Auftretens behandeln wird. Es folgt eine Beschreibung der Schritte, die notwendig sind, um sowohl in die NMI-Unterbrechungsvektoren des Realbetriebs als auch des geschützten Betriebs einzusteigen. Eine ausführlichere Beschreibung, die diese Prozesse in Zusammenhang mit der gesamten Wiederaufnahmetreiber- Initialisierung und Ausführungssequenz setzt, wird später gegeben.
In Fig. 3 ist ein Diagramm dargestellt, das die Schritte veranschaulicht, die notwendig sind, um in den NMI-Vektor des Realbetriebs "einzusteigen". Grundsätzlich muß der OS/2-Systemlader 300 modifiziert werden, um die folgenden Funktionen auszuführen. Zuerst muß der Lader den vorhandenen NMI-Vektor sichern, der auf das Standard-Wiederaufnahme-ROM-BIOS zeigt. Weil der tatsächliche NMI-Vektor in der IVT (Element 301) nicht modifiziert werden kann, da der OS/2-Kern jegliche vorgenommenen Änderungen überwacht, sollte der erste Schritt des ursprünglichen Steuerprogramms geändert werden, um zu einer dem Wiederaufnahmetreiber der vorliegenden Erfindung entsprechenden entfernten Adresse zu springen. Weil jedoch das ursprüngliche Steuerprogramm im ROM-BIOS liegt (und daher nicht modifiziert werden kann), besteht die nächstbeste Lösung darin, den IVT-Eintrag für die Realbetrieb-NMI im Lader selbst zu modifizieren. Dies wird den Kern dazu verleiten anzunehmen, daß dieser neue Vektor der richtige Vektor ist. Unglücklicherweise gibt es zur Ladezeit keine Möglichkeit zu bestimmen, wo der Wiederaufnahmetreiber schließlich in den Speicher plaziert wird, und so wird der IVT-NMI-Vektor (Element 301) einfach auf ein Leer- bzw. Blind-Steuerprogramm innerhalb des Laders selbst gerichtet, wie in Fig. 3 dargestellt ist. Das Blind- Steuerprogramm wird aus fünf (5) NOP-(Nicht-Operation)- Anweisungen bestehen, gefolgt von einem weiten Sprung zum BIOS-NMI-Steuerprogramm, wie in den Elementen 302A und 304 von Fig. 3 dargestellt ist.
Ob das Host-Computersystem die Wiederaufnahmefunktionalität der vorliegenden Erfindung unterstützt oder nicht, der NMI-Vektor des Realbetriebs wird so auf die im Lader erzeugte Blind-Steuerprogrammroutine zeigen. Falls anschließend bestimmt wird, daß der Computer die vorliegende Erfindung nicht unterstützt, wird der Wiederaufnahmetreiber der vorliegenden Erfindung nicht laden, und die fünf NOP- Anweisungen bleiben bestehen. Wenn eine Wiederaufnahme-NMI stattfindet, wird danach der Computer zum Blind-Steuerprogramm springen, die fünf NOP-Operationen ausführen und dann zu den ursprünglichen ROM-BIOS-Wiederaufnahmeroutinen springen.
Falls jedoch das Computersystem den OS/2-Wiederaufnahmetreiber der vorliegenden Erfindung unterstützt, wird der Wiederaufnahmetreiber in den Speicher geladen, und die fünf NOP-Anweisungen werden umgeschrieben bzw. korrigiert (engl. patched over), um eine Sprunganweisung zum Wiederaufnahmetreiber der vorliegenden Erfindung auszuführen, wie durch die Elemente 302B und 303 dargestellt ist. Wenn eine Wiederaufnahme-NMI auftritt, wird danach der Computer zum Blind-Steuerprogramm springen und wird dann gemäß der korrigierten Sprunganweisung sofort zum Wiederaufnahmetreiber der vorliegenden Erfindung springen.
Um in den NMI-Unterbrechungsvektor des geschützten Betriebs einzusteigen, müssen zusätzliche Schritte unternommen werden, welche zu den Schritten analog sind, die notwendig sind, um in den NMI-Unterbrechungsvektor des Realbetriebs einzusteigen. Fig. 4 liefert eine visuelle Darstellung der Schritte, die notwendig sind, um in den NMI-Unterbrechungsvektor des geschützten Betriebs einzusteigen. Zuerst muß die Adresse des ursprünglichen NMI-Steuerprogramms des geschützten Betriebs innerhalb des Kerns (Element 407 in Fig. 4) aus der (im Element 401 in Fig. 4 gelegenen) Unterbrechungsdeskriptortabelle (IDT) erhalten werden. Weil diese Adresse auf ein Codesegment verweist, ist ein Schreibzugriff in dieses Segment beschränkt.
Um diese Beschränkung zu umgehen, muß daher der von der IDT erhaltene Codeselektor verwendet werden, um in die globale Deskriptortabelle (GDT) (Codedeskriptor 402) zu indizieren, um die phyiskalische Speicheradresse des ursprünglichen Steuerprogramms zu erhalten. Ist dies einmal getan, kann die physikalische Adresse über eine auswählbare "Dev_Help"-Funktion (z.B. "DevHlp_PhysToVirt") in eine virtuelle Adresse umgewandelt werden, wobei alle derartigen "Dev_Help"-Funktionen die Schnittstelle zwischen den Vorrichtungstreibern und dem OS/2-Kern berücksichtigen. Standardmäßig gibt "DevHelp_PhysToVirt" einen Selektor zurück, der auf einen Datendeskriptor (Element 403) verweist. Die "Dev_Help"-Funktionen und eine zugeordnete Dokumentation zum Ausnutzen dieser Funktionen sind in der zu OS/2 gehörigen Entwicklungssoftware enthalten, die von Microsoft Corporation in Redmond, Washington, erhältlich ist, und ihre Verfügbarkeit kann mit den geeigneten "INCLUDE"-Befehlen in den Wiederaufnahmetreibercode aufgenommen ("INCLUDED") werden.
Weil der Selektor auf einen Datendeskriptor verweist, ist es nun möglich, die ersten Anweisungen des ursprünglichen NMI-Steuerprogramms (Element 407) zu überschreiben. Eine Anweisung für einen weiten Sprung wird unter Verwendung des Codeselektors des geschützten Betriebs des Wiederaufnahmetreibers und des Offset der NMI-Steuerprogrammroutine als das Ziel des Sprungs korrigiert (Element 405) (wobei so zu Element 406 in Fig. 4 gesprungen wird). Im Gegensatz zum "Einsteigen" des NMI-Vektors des Realbetriebs korrigieren wir in diesem Fall tatsächlich über einen bestehenden Code (keine NOP-Anweisungen) (Element 404), und somit wird das ursprüngliche Steuerprogramm des geschützten Betriebs niemals verwendet werden können. Dies ist akzeptabel, weil die alleinige Funktion, die das ursprüngliche Steuerprogramm ausführte, darin bestand, einen Registerspeicherauszug (engl. register dump) und eine Unterbrechungsnachricht (engl. trap message) anzuzeigen und dann das System anzuhalten, wenn eine NMI auftrat.
Zusätzlich zu den Modifikationen zum OS/2-Systemlader, wie oben beschrieben, muß der OS/2-Laufwerktreiber modifiziert werden, um die Wiederaufnahmefunktionalität der vorliegenden Erfindung vollständig zu unterstützen. Dies ist notwendig, weil die im ROM-BIOS gefundenen Standard-Wiederaufnahmeroutinen erwarten, daß bestimmte Register durch das Platten-BIOS modifiziert werden. Unter dem geschützten Betrieb der OS/2 Version 1.2 wird jedoch der Platten-BIOS- Code nicht verwendet. Demgemäß müssen Modifikationen am Plattentreiber vorgenommen werden, um die unten beschriebenen Schritte auszuführen. Die Modifikationen am Plattentreiber gemäß der unten beschriebenen bevorzugten Ausführungsform sind vom Umfang relativ einfach, und der Fachmann wird diese Modifikationen am OS/2-Plattentreibercode vornehmen können.
Zur Initialisierungszeit bestimmt der Plattentreiber gemäß der bevorzugten Ausführungsform der vorliegenden Erfindung, ob er auf einem Computersystem, wie z.B. dem Laptop-Computer Toshiba T3100SX, läuft, das die Wiederaufnahmefunktionalität der vorliegenden Erfindung unterstützen kann. Falls es imstande ist, die vorliegende Erfindung zu unterstützen, wird ein Wiederaufnahme-Flag gesetzt, und die folgenden Schritte werden ohne Rücksicht darauf ausgeführt, ob der Wiederaufnahmetreiber der vorliegenden Erfindung tatsächlich geladen ist. Falls aus irgendeinem Grund der Wiederaufnahmetreiber tatsächlich nicht geladen ist, werden keine nachteiligen Nebeneffekte auftreten, wie später in weiteren Einzelheiten erläutert wird.
Zuerst wird vor jedem Plattenzugriff ein anderes Flag gesetzt, und es wird gelöscht, wenn der Plattenzugriff abgeschlossen ist. Folglich wird das Wiederaufnahme-BIOS durch Prüfen dieses Flags bestimmen können, ob das Festplattenlaufwerk (HDD) gegenwärtig aktiv ist oder nicht. Falls das HDD gegenwärtig aktiv ist, wird das Wiederaufnahme-BIOS ein Bit im Energie-NMI-Maskenregister setzen und herausspringen, wodurch die Steuerung an den Wiederaufnahmetreiber der vorliegenden Erfindung (der auch herausspringt) zurückgegeben wird. Nach Beenden eines etwaigen Plattenzugriffs und vor einem Prüfen der Anforderung- Warteschlange setzt der Plattentreiber ein Bit im Energie- NMI-Register. Falls das entsprechende Maskenregisterbit durch das Wiederaufnahme-BIOS gesetzt worden ist, wird eine andere NMI erzeugt. Diesmal wird jedoch das Wiederaufnahme- BIOS feststellen, daß das HDD inaktiv ist, und wird den normalen Code der Wiederaufnahme-BIOS-Routine ausführen und die Maschine abschalten können. Wenn anschließend die Energie wieder eingeschaltet wird, wird der Plattentreiber aufnehmen, wo er ausstieg (d.h. Prüfen, um zu sehen, ob irgendwelche Anforderungen in der Warteschlange vorliegen).
Schließlich ist die letzte OS/2-Komponente, die modifiziert werden muß, um die vorliegende Erfindung zu implementieren, der Initialisierungscode des OS/2-Systems. In einer bevorzugten Ausführungsform besteht der Wiederaufnahmetreiber der vorliegenden Erfindung aus einem installierbaren Vorrichtungstreiber. In der bevorzugten Ausführungsform wird dieser installierbare Vorrichtungstreiber "RESUME.SYS" genannt, obwohl natürlich jeder andere Name ebensogut verwendet werden könnte. Überdies kann die Wiederaufnahmefunktionalität der vorliegenden Erfindung nur auf einem Computersystem, wie z.B. dem Toshiba T3100SX, arbeiten, das eine intelligente Energieversorgung enthält und unter der OS/2- Version 1.2 arbeiten kann. Daher muß der Installationscode so modifiziert werden, daß der Wiederaufnahmetreiber nur installiert wird, wenn eine geeignete Maschine festgestellt wird. Um einen notwendigen Eingriff durch den Benutzer, um den Wiederaufnahmetreiber zu installieren, zu minimieren, ist die Modifikation am Installationscode in der bevorzugten Ausführungsform so entworfen, daß sie für den Benutzer transparent ist. Diese Modifikation wird im folgenden beschrieben.
Um den Wiederaufnahmetreibercode auf die Distributionsdisketten zu plazieren, die in das relevante Computersystem aufzunehmen sind, müssen die mit der OS/2-Entwicklung verbundenen Befehlsdateien BUILD.CMD und MKOS2.CMD modifiziert werden. BUILD.CMD muß modifiziert werden, um (1) zum Wiederaufnahme-Unterverzeichnis zu gehen und den Wiederaufnahmetreibercode zu assemblieren und zu verbinden und (2) die endgültige RESUME.SYS-Datei unter dem binären DISK-2-Unterverzeichnis zu stapeln (DISK 2 wird gewählt, weil dieses dasjenige ist, in dem sich die anderen installierbaren Treiber unter der OS/2-Version 1.2 befinden. Natürlich könnte jede andere Platte ebensogut verwendet werden). MKOS2.CMD ist für ein Erzeugen der OS/2-Installationsdisketten verantwortlich und muß modifiziert werden, um den Wiederaufnahmetreiber (z.B. RESUME.SYS) auf die Installation DISK 2 zu kopieren.
Die Datei SYSINST.MS hält eine komplette Liste aller Dateien, die von den Installationsdisketten auf das Festplattenlaufwerk des Benutzers unter dem geeigneten Unterverzeichnis kopiert (oder entpackt) werden. Diese Datei wird zur Initialisierungszeit durch das OS/2-Installationsprogramm verwendet (SYSINT2.EXE unter der OS/2-Version 1.2). Der binäre Dateiname des Wiederaufnahmetreibers wird in der Liste für DISK 2 aufgelistet.
Schließlich muß SYSINT2.EXE modifiziert werden, um (1) zu bestimmen, ob ein geeigneter Computer verwendet wird (z.B. Toshiba T3100SX), und falls dies der Fall ist, (2) die Datei CONFIG.SYS des Benutzers zu editieren, um den Wiederaufnahmetreiber zu laden. Die OEMHELP-Funktion 81 (hex) (z.B. Lade- bzw. Hol-Maschinentyp und -Betriebsart) kann verwendet werden, um die Maschine zu identifizieren, die installiert wird. SYSINST2.EXE muß ferner modifiziert werden, um die folgende Befehiszeile in der Datei CONFIG.SYS zu plazieren, falls die Maschine den Wiederaufnahmetreiber unterstützen kann:
DEVICE = C:\OS2\RESUME.SYS
Der tatsächliche Wiederaufnahmetreiber der vorliegenden Erfindung gemäß der bevorzugten Ausführungsform führt selbst teilweise eine Initialisierung durch, um in die NMI Vektoren des Realbetriebs und geschützten Betriebs "einzusteigen", wie vorher beschrieben wurde, und bildet die Zieladresse, die ausgeführt wird, nachdem eine NMI empfangen ist. Fig. 5, 6 und 7A-7B stellen Flußdiagramme dar, welche die Schritte beschreiben, die ausgeführt werden, wenn der Wiederaufnahmetreiber zuerst initialisiert wird und anschließend auf ein Auftreten einer NMI hin ausgeführt wird. Diese Figuren werden im folgenden nacheinander beschrieben.
In Fig. 5 sind Schritte 501-509 dargestellt, die die Initialisierungsschritte umfassen, welche zuerst ausgeführt werden, wenn der Wiederaufnahmetreiber geladen wird. Schritt 501 bezieht sich auf den Prozeß zum Laden des Wiederaufnahmetreibers (RESUME.SYS in der bevorzugten Ausführungsform), der durch den Lader des OS/2-Vorrichtungstreibers während des Systemanlaufs ausgeführt wird. Die Zeile "DEVICE = C:\OS2\RESUME.SYS" wird von der Datei CONFIG.SYS gelesen, und der Wiederaufnahmecode und die Daten werden in den Speicher geladen. Eine Ausführung wird zu einer Anfangsroutine mit einem Anforderungspaket eines Initialisierungsbefehls übertragen. Die Ausführung wird dann an eine Treiber-Initialisierungsprozedur weitergeleitet, um die Initialisierung des Wiederaufnahmetreibers abzuschließen.
Die Initialisierungsroutine des Wiederaufnahmetreibers führt verschiedene Funktionen aus. Zuerst bestimmt Schritt 502, ob das Host-Computersystem ein Typ eines Computersystems ist, der die Wiederaufnahmefunktion der vorliegenden Erfindung unterstützt. Diese Bestimmung kann vorgenommen werden, indem die geeigneten Speicherstellen gelesen werden, welche Codes enthalten, die spezifizieren, welcher Typ eines Computersystems vorliegt (z.B. ROM-BIOS-Adresse F000:FFFA für die Toshiba-Linie von Computern), und indem die geeigneten Speicherstellen gelesen werden, die angeben, ob die standardmäßige ROM-BIOS-Wiederaufnahmefunktion unterstützt wird (z.B. ROM-BIOS-Adresse F000:E024 und folgende, auf Toshiba-Computern). Insbesondere muß das Computersystem unter dem OS/2-Betriebssystem arbeiten können (z.B. ein Computersystem mit einem 80286-kompatiblen Mikroprozessor - CPU 101 in Fig. 1), eine intelligente Energieversorgungsschaltung (Element 117 in Fig. 1) haben und eine vorhandene Wiederaufnahmeverarbeitungsfunktionalität mit ihrem ROM-BIOS aufweisen. In einer bevorzugten Ausführungsform erfüllen die Laptop-Computer, entweder Toshiba T3100SX oder T2000SX, diese Kriterien, und daher macht Schritt 502 einen speziellen Verweis auf diese Maschinen. Jedes andere, unter OS/2 arbeitende Computersystem mit einer intelligenten Energieversorgung kann jedoch ebensogut verwendet werden, um die vorliegende Erfindung zu implementieren, und der T3100SX und der T2000SX sind nur zu Veranschaulichungszwekken erwähnt.
Falls kein geeignetes Computersystem festgestellt wird, wie in Schritt 508, wird dem Benutzer eine Fehlermeldung der Treiberinstallation angezeigt, und der Initialisierungsprozeß wird beendet (Schritt 509).
Falls andererseits ein geeignetes Computersystem festgestellt wird, wird OEMHELP angehängt, um das Merkmal "automatische Anzeige aus" (das über einen hex-88-IOCtl- Aufruf an OEMHELP aufgerufen werden kann) zu unterstützen, wie in Schritt 503 angegeben ist. In einer bevorzugten Ausführungsform kann dies erreicht werden, indem die Offsets des OEMHELP-Dateinamen (z.B. OEMHELP$) und die begleitenden bzw. zugehörigen OEMHELP-Daten (z.B. sowohl die Codeeintragstelle als auch das Datensegment des Realbetriebs und geschützten Betriebs) in die BX- bzw. DI-Register übertragen und danach an OEMHELP angehängt werden&sub1; indem ein geeignetes "Dev_Help" (z.B. DevHelp_attached) aufgerufen wird. Danach können Daten eines auswählbaren Anforderungspakets OEMHELP-Eingabe/Ausgabesteuerung (IOCtl) in die für das Anf orderungspaket reservierten Speicherstellen geladen werden, wodurch die Notwendigkeit, diese Information zu jeder Unterbrechungszeit neu zu laden, eliminiert ist. Solche Daten enthalten die Paketlänge, den Paketbefehl, die GIO- Kategorie, die GIO-Funktion etc.
Nachdem Schritt 503 ausgeführt ist, trifft man auf Schritt 504, wie in Fig. 5 dargestellt ist. Der Schritt 504 besteht aus einem Erzeugen von Speichersegmentselektoren der globalen Deskriptortabelle (GDT) gemäß der standardmäßigen 80286-kompatiblen Mikroprozessorarchitektur, welche auf die GDT selbst zeigen, sowie auch einem Erzeugen eines Blindselektors mit einer Beschränkung von 64K. Der GDT- Selektor wird durch den Wiederaufnahmetreiber der vorliegenden Erfindung verwendet, um auf Deskriptoren in der GDT zuzugreifen. Schließlich wird der Blindselektor verwendet, wenn zum Realbetrieb geschaltet wird, wie später beschrieben wird.
Zuerst werden zwei Selektoren unter Verwendung einer geeigneten Funktion (z.B. "DevHelp_AllocGDTSelector") der "Dev_Help"-Funktionen erzeugt. Danach läßt man den ersten Selektor auf die GDT zeigen, indem die geeignete Adresse in die AX- und BX-Register geladen wird, 0 (für eine 64K-Beschränkung) in das CX-Register geladen wird, der geeignete Selektor ausgewählt und eine geeignete Funktion (z.B. "DevHelp_PhysToGDTSelector") von "Dev_Help" aufgerufen wird. Schließlich wird der zweite Selektor ähnlich eingestellt, um auf ein Blindsegment mit einer 64K-Beschränkung zu zeigen.
Nachdem die beiden Selektoren erzeugt sind, wie oben beschrieben wurde, werden die Daten des geschützten Betriebs, Codeselektoren sowie der Datensegmentwert des Realbetriebs an der Spitze des Codesegments gesichert, wie in Schritt 505 dargestellt ist. Diese Information muß im Codesegment des Treibers infolge der Tatsache gehalten werden, daß, wenn eine NMI auftritt und eine Ausführung an den Wiederaufnahmetreiber übergeht, das DS-Register noch auf das Datensegment der Aufgabe zeigen wird, die unterbrochen wur de. Im einzelnen werden die folgenden Schritte ausgeführt, um die obigen Daten in das Codesegment zu sichern: (1) Die physikalische Adresse der Spitze der GDT wird wiedergewonnen und durch die "Dev_Help"-Funktionen (z.B. DevHelp_PhysToVirt) in eine virtuelle Adresse umgewandelt, (2) der Deskriptortyp wird eher auf CODE als auf den Standard-DATA-Typ der "DevHelp_PhysToVirt"-Funktion eingestellt, (3) die Attribute des Deskriptors werden so eingestellt, daß sie ausführbar, lesbar und übereinstimmend sind und auf sie zugegriffen werden kann, (4) Umwandeln der physikalischen CS-(Codesegment)-Adresse in eine virtuelle Adresse mit z.B. der "DevHelp_PhysToVirt"-Funktion, so daß ein DATA-Selektor erzeugt wird, und (5) Kopieren des Datensegments des Realbetriebs, des Datenselektors des geschützten Betriebs und des Codeselektors des geschützten Betriebs in vorher reservierte Speicherstellen innerhalb des CODE- Segments des Wiederaufnahmetreibers (z.B. an der Spitze des CODE-Segments). An dieser Stelle wird die virtuelle Adresse der GDT über eine geeignete "Dev_Help"-Funktion (z.B. DevHelp_UnPhysToVirt) in eine physikalische Adresse zurückverwandelt.
Nachdem Schritt 505 ausgeführt worden ist, wird, wie in Schritt 506 dargestellt ist, ein Zeitgeber-Steuerprogramm installiert. Dieses Zeitgeber-Steuerprogramm ist notwendig, weil bestimmte "Dev_Help"-Routinen zur INIT-Zeit nicht laufen können. Um diese Beschränkung zu umgehen, wird ein Zeitgeber-Steuerprogramm installiert, das den notwendigen Code hat, um in die NMI-Vektoren des geschützten Betriebs und Realbetriebs einzusteigen, wie vorher beschrieben wurde. Das Zeitgeber-Steuerprogramm läuft bei einer "Ring-0"- Privileg-Ebene des Mikroprozessors und hat daher die höchsten Privilegien.
Um das Zeitgeber-Steuerprogramm zu installieren, wird der Offset in die tatsächliche Zeitgeber-Steuerprogrammroutine (die weiter unten beschrieben wird) im Register AX plaziert, und eine Verzögerung (z.B. 1/3 einer Sekunde) wird im Register BX eingerichtet. Eine geeignete "Dev_Help"-Funktion (z.B. DevHelp_TickCount) wird dann aufgerufen, um das Zeitgeber-Steuerprogramm zu installieren. Danach wird das Zeitgeber-Steuerprogramm beim geeigneten Zeitgeber ausgeführt, wie nachstehend ausführlich mit Verweis auf Fig. 6 diskutiert wird.
Nachdem das Zeitgeber-Steuerprogramm in Schritt 506 installiert ist, trifft man auf Schritt 507. Zuerst wird OS/2 darüber informiert, welcher Teil des Wiederaufnahmetreibercodes der vorliegenden Erfindung nach einer Initialisierung gelöscht werden kann. Dies wird durch Laden von Adressen, die den letzten Adressen innerhalb des Codesegments und Datensegments entsprechen, welche nach einer Initialisierung gehalten werden, in geeignete Speicherstellen erreicht, die dann als ein Zeiger auf die Enden der geeigneten Segmente verwendet werden. Als nächstes können ein geeigneter Treibername und eine Copyright-Nachricht angezeigt werden, die den Namen des Treibers und eine damit verbundene Copyright- Information angeben. Dies ist natürlich wahlfrei, wird aber in einer bevorzugten Ausführungsform vorgenommen, um den Urheberrechtsschutz der Wiederaufnahmetreibersoftware anzugeben.
Nachdem 507 ausgeführt worden ist, ist der Initialisierungsprozeß abgeschlossen, und demgemäß trifft man auf Schritt 509. Jegliche verbleibende Systeminitialisierung kann an dieser Stelle durch OS/2 durchgeführt werden, und schließlich wird in die standardmäßige OS/2-Umgebung gesprungen, was dem Benutzer erlaubt, normale Operationen bezüglich der Computersoftware durchzuführen. Wenn jedoch durch die intelligente Energieversorgung (Element 117 in Fig. 1) eine Abschaltanforderung in Form einer NMI empfangen wird, wird der Wiederaufnahmetreiber der vorliegenden Erfindung ausgeführt. Die Operation der Haupt-Wiederaufnahmetreiberroutine wird weiter unten bezüglich Fig. 7A und 7B in weiteren Einzelheiten beschrieben.
In Fig. 6 ist die Zeitgeber-Steuerprogrammroutine zum Einsteigen in die Vektoren des Realbetriebs und geschützten Betriebs dargestellt. Diese Zeitgeber-Steuerprogrammroutine wird zu Anfang durch den Initialisierungsprozeß installiert, wie oben bezüglich des Schritts 506 von Fig. 5 beschrieben wurde. Zur geeigneten Zeit wird die Zeitgeber- Steuerprogrammroutine ausgeführt, wie im folgenden be schrieben wird.
Zuerst stellt Schritt 601 von Fig. 6 den Zeitpunkt dar, zu dem das Zeitgeber-Steuerprogramm zuerst aufgerufen wird. Dies geschieht, nachdem das Zeitgeber-Steuerprogramm vorher installiert worden ist. Wie oben besonders erwähnt wurde, wird in der bevorzugten Ausführungsform das Zeitgeber- Steuerprogramm beim "Ring 0" ausgeführt, was der höchsten Privileg-Ebene des 80286-kompatiblen Mikroprozessors entspricht.
Schritt 602 entspricht dem Prozeß eines Deinstallierens des Zeitgeber-Steuerprogramms, nachdem in die Zeitgeber- Steuerprogrammroutine gesprungen wurde. Der Deinstallationsprozeß kann durch Laden der Distanz- bzw. Offset-Adresse des Zeitgeber-Steuerprogramms im AX-Register und Aufrufen einer geeigneten "Dev_Help"-Funktion (Z.B. DevHelp_ResetTimer) durchgeführt werden, um den Zeitgeber zu deinstallieren.
Danach trifft man auf Schritt 603, der ein "Einsteigen" in den NMI-Vektor des Realbetriebs zur Folge hat, um auf den Wiederaufnahmetreiber der vorliegenden Erfindung zu zeigen (siehe vorherige Diskussion bezüglich Fig. 3). Zuerst wird der virtuelle Zeiger auf die bei Adresse 0:0 gelegene Vektortabelle des Realbetriebs durch Verwenden einer geeigneten "Dev_Help"-Funktion (Z.B. DevHelp_PhysToVirt) erhalten. Als nächstes wird die Adresse des im vorher beschriebenen modifizierten OS/2-Lader (OS2LDR) erzeugten Blind-NMI-Steuerprogramms in der Vektortabelle des Realbetriebs (INT 2 Vektor) erhalten. Danach werden die fünf (5), ursprünglich im Blind-NMI-Steuerprogramm plazierten NOP- Operationen durch einen weiten Sprung zum Wiederaufnahmetreiber der vorliegenden Erfindung ersetzt. Zum Beispiel wird der Befehl für einen weiten Sprung (EA hex) in der ersten NOP-Stelle plaziert, und der Offset und das Segment des Wiederaufnahmetreibers werden an den folgenden Stellen plaziert. Danach wird die virtuelle Adresse der Tabelle des Vektors des Realbetriebs zu einer physikalischen Adresse mit z.B. der "DevHelp_UnPhysToVirt" der "Dev_ Help"-Funktionen zurück umgewandelt.
Zusätzlich zum NMI-Vektor des Realbetriebs muß auch in den NMI-Vektor des geschützten Betriebs "eingestiegen" werden (siehe vorherige Diskussion bezüglich Fig. 4), wie in Schritt 604 von Fig. 6 angegeben ist. Zuerst wird die virtuelle Adresse der Unterbrechung-Deskriptortabelle (IDT) durch die Verwendung einer geeigneten "Dev_Help"-Funktion (z.B. DevHelp_PhysToVirt) erhalten. Als nächstes wird der innerhalb der IDT gespeicherte ursprüngliche NMI-Vektor erhalten und in einer vorher reservierten Speicherstelle gespeichert. Weil die Adresse des ursprünglichen NMI-Vektors in den OS/2-Kern (ein CODE-Segment) zeigt, ist ein Schreibzugriff auf das Segment eingeschränkt. Folglich kann der aus der IDT erhaltene Codeselektor verwendet werden, um in die globale Deskriptortabelle (GDT) zu indexieren, um die physikalische Speicheradresse des ursprünglichen Steuerprogramms zu erhalten. Dieser Wert wird über eine geeignete "Dev_Help"-Funktion (z.B. DevHelp_PhysToVirt) in eine virtuelle Adresse umgewandelt, die standardmäßig einen Selektor zurückgibt, der auf einen DATA-Deskriptor verweist. Daher ist es möglich, die ersten Anweisungen des ursprünglichen Steuerprogramms zu überschreiben, um effektiv in den NMI-Vektor "einzusteigen".
Der vorher gesicherte Offset, der auf den ursprünglichen NMI-Vektor zeigt, kann danach verwendet werden, um den Offset in das verwiesene DATA-Segment (mit Parallelbezeich nungen des CODE-Segments des NMI-Steuerprogramms) zu bestimmen. Unter Verwendung der resultierenden virtuellen Adresse kann ein Sprung zur entfernten Adresse des Vorrichtungstreibers der vorliegenden Erfindung in den Beginn des ursprünglichen NMI-Steuerprogramms des geschützten Betriebs korrigiert bzw. geschrieben werden. Zum Beispiel kann die Anweisung für einen weiten Sprung (EA hex) in die erste Stelle korrigiert werden, und die Adresse des Vorrichtungstreibers (Offset und Selektor) kann in die folgenden Speicherstellen geschrieben werden.
Nachdem in den Schritten 603 und 604 in die NMI-Vektoren für sowohl den Realbetrieb als auch den geschützten Betrieb "eingestiegen" worden ist, trifft man auf Schritt 605, und das Zeitgeber-Steuerprogramm wird verlassen. Ist dieser Schritt einmal abgeschlossen worden, ist der OS/2- Wiederaufnahmetreiber der vorliegenden Erfindung installiert worden und kann verwendet werden, wenn der Benutzer des Computersystems den Energieschalter drückt, wodurch eine NMI an die CPU gesendet wird. Die folgende Erläuterung beschreibt ausführlich die verschiedenen Schritte, welche die Hauptroutine des Wiederaufnahmetreibers bilden. Demgemäß werden diese Schritte während einer tatsächlichen OS/2- Wiederaufnahmeverarbeitung durchgeführt, und bevor die im ROM-BIOS befindlichen Standard-Wiederaufnahmeroutinen ausgeführt werden.
Fig. 7A und 7B sind Flußdiagramme, welche die Wiederaufnahmetreiberfunktionalität der vorliegenden Erfindung in einer bevorzugten Ausführungsform darstellen. Die durch diese Flußdiagramme dargestellte Routine bildet die Zielroutine des weiten Sprungs, die tatsächlich in die ursprünglichen NMI-Steuerprogramme korrigiert bzw. geschrieben wird, wie vorher beschrieben wurde. Die durch Fig. 7A und 7B dargestellten Routinen wirken tatsächlich wie ein "Umschlag" um den BIOS-Code. Im Fall einer Wiederaufnahme- NMI führt der Wiederaufnahmetreiber eine Vorverarbeitung vor einem Übertragen einer Steuerung an das BIOS durch, und er führt nach Abschluß der BIOS-Wiederaufnahmefunktion eine Nachverarbeitung durch, nachdem die Energie wieder eingeschaltet ist. Das Computersystem wird tatsächlich in der Mitte des Wiederaufnahme-BIOS-Codes abgeschaltet.
In dem Fall einer I/O-Kanalprüfungsfehler-NMI (Paritätsfehler), die in der bevorzugten Ausführungsform der einzige andere Typ einer NMI ist, der neben einer Wiederaufnahme-NMI auftreten kann, führt der Wiederaufnahmetreiber der vorliegenden Erfindung eine Vorverarbeitung durch und überträgt die Steuerung an das BIOS, das das System anhält. An dieser Stelle wird die Maschine angehalten, und der Benutzer muß den Reset- bzw. Rücksetz-Knopf drücken, um das System neu zu booten. Der durch den Wiederaufnahmetreiber verfolgte tatsächliche Ausführungspfad ist ungeachtet der Ursache der NMI der gleiche.
Falls eine CMOS-Speicherstelle eingestellt ist, die angibt, daß eine Wiederaufnahmeverarbeitung aktiviert ist, werden dann die in Fig. 7A und 7B skizzierten Schritte ausgeführt, nachdem die NMI detektiert ist. Wenn zuerst in den Wiederaufnahmetreiber eingesprungen wird (Schritt 701 in Fig. 7A), sperrt der Treiber zuerst alle Unterbrechungen (z.B. mit der CLI-Assemblersprache-Anweisung), wie in Schritt 702 angegeben ist. Dies ist in OS/2 notwendig, weil INT 2 (z.B. NMI) ein Fang-Gatter und kein INT-Gatter ist.
Als nächstes werden gemäß einer guten Programmiertechnik in einer Assembiersprache alle Register und Flags auf dem Stapel mit den PUSH-artigen Befehlen gesichert, wie in Schritt 702 weiter angegeben ist. Danach wird das DS- Register auf den geeigneten Wert eingestellt (entweder ein Segment oder ein Selektor, je nach CPU-Betriebsart), und der Wiederaufnahmetreiber sichert dann die aktuelle programmierbare Unterbrechung-Steuereinheit-(PIC)-Maske und sperrt dann in Schritt 703 die PIC.
An dieser Stelle wird in Schritt 704 bestimmt, ob die CPU im Realbetrieb oder geschützten Betrieb arbeitet. Dies kann durch Prüfen des geeigneten Bits des Maschinen-Statuswortes (z.B. mit der SMSW-Anweisung) einfach erreicht werden. Falls die CPU im Realbetrieb ist, springt dann die Ausführung zu Schritt 708 hinunter, der unten beschrieben wird.
Die Verarbeitung, die stattfindet, wenn eine NMI im geschützten Betrieb festgestellt wird, ist infolge der Tatsache, daß der Operationsmodus der CPU gewechselt werden muß, bevor in den Wiederaufnahme-BIOS-Code eingesprungen wird, komplizierter als das Szenario des Realbetriebs.
In bevorzugten Ausführungsformen gibt es zwei Verfahren zum Schalten vom 80286-geschützten Betrieb zum Realbetrieb. Zuerst kann das "CPU-Rücksetz-Verfahren" durch Erzeugen eines Dreifach-Fehlers verwendet werden. Dieses Verfahren hat die Eigenschaft, mit der 80286-CPU kompatibel zu sein. Das andere Verfahren ist der 80386-CPU-Moduswechsel unter Verwendung von 80386-Anweisungen. Dies ist insofern ein eleganteres Verfahren, als im Gegensatz zum "CPU-Rücksetz- Verfahren" die CPU (und alle ihre Register) nicht zurückgesetzt werden, wenn zum Realbetrieb geschaltet wird. Weil sich das Verfahren einer 80386-CPU-Moduswechselanweisung für eine sauberere Gestaltung eignet, wird dieses Verfahren in der bevorzugten Ausführungsform verwendet. Das "CPU- Rücksetz-Verfahren" kann jedoch verwendet werden, falls die Host-CPU ein 80286-Mikroprozessor anstelle eines 80386- kompatiblen Mikroprozessors ist.
Falls die CPU im 80386-geschützten Betrieb arbeitet, werden dann die Schritte 705-707 ausgeführt, um die CPU richtig im Realbetrieb zu plazieren. Auf einigen Maschinen mit bestimmten seltsamen Eigenarten (engl. quirks) in ihrem BIOS müssen jedoch zuerst Anfangsschritte unternommen werden.
Falls z.B. der Wiederaufnahmetreiber der vorliegenden Erfindung auf einem Laptop-Computer Toshiba T3100SX arbeitet, müssen wegen Unzulänglichkeiten des BIOS zuerst die folgenden Schritte ausgeführt werden: (1) Der Monitorprozessor (MP) und task-geschaltete (TS) Bits des MSW müssen gelöscht werden, um zu verhindern, daß "Coprozessor nicht vorhanden, Ausnahmen" (engl. coprocessor not present, exceptions) auftritt, (2) das Task-Zustandsregister (TSR) wird gesichert, und die Aufgabe bzw. Task wird mit "nicht besetzt" markiert, so daß der BIOS-Code nicht hängenbleiben wird, während er darauf wartet, daß sie endet, und (3) das Register für die lokale Deskriptortabelle (LDT-Register) muß in eine vorher reservierte Speicherstelle gesichert werden, weil das BIOS dies anscheinend nicht tut. Diese und andere Unzulänglichkeiten des BIOS-Codes, die auf dem T3100SX vorhanden sind, können auf anderen Maschinen vorhanden oder auch nicht vorhanden sein. Falls auf anderen Maschinen andere derartige Unzulänglichkeiten entdeckt werden, müssen dann notwendigerweise Maßnahmen, wie z.B. die oben unternommenen, ergriffen werden.
Falls die CPU im geschützten Betrieb arbeitet, müssen dann die folgenden Schritte 705-707 unternommen werden, um sie in den Realbetrieb zu schalten. Zuerst wird in Schritt 705 ein Flag gesetzt, das darstellt, daß der CPU-Betrieb gerade vom geschützten Betrieb in den Realbetrieb geschaltet wird. Dies wird verwendet, wenn anschließend die Energiezufuhr wiederhergestellt wird, um anzuzeigen, daß der Betrieb vom Realbetrieb zum geschützten Betrieb zurückge schaltet werden muß. Im Schritt 705 werden auch die mit dem geschützten Betrieb verbundenen Register, nämlich SS und SP, in vorher reservierte Speicherstellen gesichert.
In Schritt 706 werden die SS- und SP-Register modifiziert, um auf den lokalen Stapel im Datensegment des Wiederaufnahmetreibers zu zeigen. Schließlich wird in Schritt 707 die CPU in den Realbetrieb geschaltet. Die Schritte, die notwendig sind, um den Wechsel in der bevorzugten Ausführungform auszuführen, werden im folgenden beschrieben.
Die beschriebenen Schritte folgen den Schritten, die im Intel 80386DX-Programmier-Handbuch auf Seite 14-4 skizziert sind, das von Intel Corporation erhältlich ist.
Zuerst wird die Codesegmentbeschränkung des Wiederaufnahmetreibers so korrigiert, daß sie 64K beträgt, während die aktuelle Codesegmentbeschränkung gesichert wird. Dann wird ein weiter Sprung zur nächsten Anweisung durchgeführt, um das CS-Register mit der neuen Segmentbeschränkung zu laden. Dies kann in der bevorzugten Ausführungsform simuliert werden, indem das CS-Register auf den Stapel geschoben wird, die Distanzadresse bzw. der Offset der nächsten Anweisung auf den Stapel geschoben wird und dann die RETF- Anweisung ausgeführt wird. Weil die RETF-Anweisung die "Rücksprung"-Adresse vom Stapel zieht, wird die nächste Anweisung ausgeführt, nachdem der "Rücksprung" ausgeführt ist.
Als nächstes werden die Segmentregister mit einem Blind-Selektorwert geladen, der vorher zur Initialisierungszeit eingestellt wurde. An dieser Stelle sind sowohl Unterbrechungen als auch NMIS gesperrt worden (wobei Unterbrechungen vorher gesperrt wurden und aufgrund der vorliegenden Routine gesperrte NMIS wie eine NMI behandelt werden).
Unter Verwendung spezieller 80386-Anweisungen (vorausgesetzt, die CPU ist 80386-kompatibel), kann das Freigabe- (PE)-Bit des geschützten Betriebs im Steuerregister 0 (CR0) gelöscht werden, was somit die CPU in den Realbetrieb bringt. Die Makro-Assembler-80386-Anweisungen/Makros von Microsoft, die in der bevorzugten Ausführungsform verwendet werden, sind die folgenden:
MOV EAX, CR0
AND EAX, NOT 1
MOV CR0, EAX
Andere ähnliche Anweisungen können jedoch auf nicht-80386- kompatiblen Maschinen verwendet werden, um den gleichen Effekt zu erzielen.
Nachdem das PE-Bit gelöscht ist, muß sofort ein weiter Sprung (natürlich unter Verwendung einer Realbetrieb-Adressierung) zur nächsten Anweisung ausgeführt werden, um die Anweisung-Warteschlange zu räumen und den geeigneten Wert in das CS-Register zu geben.
Als nächstes muß die IDT mit der Basis und Beschränkung der Unterbrechungsvektortabelle für den Realbetrieb (IVT) geladen werden. Schließlich werden die Segmentregister DS, ES und SS mit der Realbetrieb-Adresse des Datensegments des Treibers geladen. An dieser Stelle werden Unterbrechungen nicht erneut freigegeben, weil sie gesperrt bleiben müssen, bis der Wiederaufnahmetreiber zum unterbrochenen Prozeß zurückkehrt.
Wenn Schritt 708 erreicht ist, entweder nach Schritt 704, falls die CPU ursprünglich im Realbetrieb war, oder nach den Schritten 705-707, falls die CPU ursprünglich im geschützten Betrieb war, muß gemäß der bevorzugten Ausführungsform das Richtung-Flag mit der CLD-Anweisung gelöscht werden, falls auf einem Toshiba-Computer gearbeitet wird. Auf anderen Maschinen mag jedoch diese Anweisung nicht notwendig sein.
Schritt 709 beinhaltet eine Bestimmung, ob das Diskettenlaufwerk aktiv ist. Diese Bestimmung sollte in einer bevorzugten Ausführungsform vorgenommen werden, um vor dem gefährlichen Zustand zu schützen, in dem das Diskettenlaufwerk aktiv ist, wenn die Wiederaufnahme-Funktionalität auftritt und der Benutzer die Diskette im Diskettenlaufwerk wechselt, bevor die Energie anschließend wieder eingeschaltet ist. Falls dies geschehen sollte, würde der Computer nicht erkennen, daß die Diskette gewechselt wurde, und könnte fortfahren, eine Schreiboperation auf der neuen Diskette auf der Basis der Inhalte der alten Diskette auszuführen. Dies könnte offensichtlich verhängnisvolle Effekte haben.
Daher prüft in Schritt 709 der Wiederaufnahmetreiber, um zu sehen, ob das Diskettenlaufwerk aktiv ist, durch Prüfen des Diskettenmotor-Statusports (Bit 5 von Port 0E5 hex). Falls der Diskettenmotor aktiv ist, wird dann das Diskettenlaufwerk in Schritt 710 zurückgesetzt (auf Toshiba-Computern wird das Wiederaufnahme-BIOS versagen, falls das Diskettenlaufwerk aktiv ist). Falls das Diskettenlaufwerk nicht aktiv ist, werden dann andernfalls die Systemflags auf den Stapel geschoben, um wiederhergestellt zu werden, wenn man auf die IRET-Anweisung im Wiederaufnahme- BIOS trifft, nachdem Energie wieder eingeschaltet wurde. An dieser Stelle trifft man auf Schritt 711, und der Wiederaufnahmetreiber kann in den ursprünglichen BIOS-Wiederaufnahmecode springen, indem die vorher gesicherte Adresse dieses Codes verwendet wird. Der ursprüngliche BIOS-Wiederaufnahmecode führt seine standardmäßige Wiederaufnahmeverarbeitungsfunktion durch, und die intelligente Energieversorgung (Element 117 in Fig. 1) schaltet schließlich den Computer in Schritt 712 ab.
Zu irgendeiner Zeit, nachdem der Computer in Schritt 712 abgeschaltet wurde, kann der Benutzer des Computersystems der intelligenten Energieversorgung signalisieren, daß der Computer wieder eingeschaltet werden soll, wie in Schritt 713 von Fig. 7B angegeben ist. Der Benutzer kann dies durch Drücken des gleichen Energieschalters (Element SW in Fig. 1) anzeigen, der verwendet wurde, um das System abzuschalten. Wenn dieser Schalter gedrückt wird, nimmt der Computer eine Ausführung des BIOS-Wiederaufnahmecodes wieder auf, wo er ihn verließ. Der BIOS-Wiederaufnahmecode führt seine jeweilige Verarbeitung durch, um die Realbetrieb-Register und -Daten wiederherzustellen, und gibt dann die Steuerung an den Wiederaufnahmetreiber der vorliegenden Erfindung an dem Zeitpunkt zurück, nach dem der Wiederaufnahmetreiber das BIOS aufgerufen hatte.
Nachdem der BIOS-Wiederaufnahmecode die Steuerung an den Wiederaufnahmetreiber Zurückgibt, führt der Wiederaufnahmetreiber Schritt 714 aus. Schritt 714 beinhaltet ein Sperren der Unterbrechungen (z.B. mit der CLI-Anweisung), weil gemäß der bevorzugten Ausführungsform das Wiederaufnahme-BIOS sie wieder eingeschaltet hat. Außerdem beinhaltet Schritt 714 ein Freigeben der PIC-Maske in ihren Zustand, der gesichert wurde, als die PIC vorher gesperrt wurde.
Die Einstellungen des CMOS-Echtzeittaktgebers müssen speziell für OS/2 durch den Wiederaufnahmetreiber zurückgesetzt werden, wie durch Schritt 715 dargestellt ist, weil der BIOS-Code diese Funktion nicht ausführt. Auf dem T3100SX-Computer z.B.: (1) die Zeitbasisfrequenz wird auf 32,768 kHz eingestellt, (2) die Ratenauswahlbits werden so eingestellt, daß die Unterbrechungsrate je 31,25 ms beträgt, und (3) periodische Unterbrechungen, Update-Beendet- Unterbrechungen (engl. update-ended interrupts) und eine 24-Stunden-Modus-Interpretation werden eingeschaltet. In diesem Fall würden geeignete Anweisungen ausgeführt werden, um diese Effekte zu erzielen.
Zusätzlich zu den obigen Schritten, die bei Rückkehr vom Wiederaufnahme-BIOS ausgeführt werden müssen, muß die Adreßleitung 20 (A20) in Schritt 716 freigegeben werden, weil der BIOS-Code sie in der bevorzugten Ausführungsform sperrt. Im allgemeinen ist im Realbetrieb Gatter A20 gesperrt. OS/2 von Toshiba arbeitet jedoch mit ihm freigegeben. Kehrt man somit vom BIOS zurück, muß das Gatter A20 freigegeben werden, so daß OS2/2 eine normale Ausführung fortsetzen kann. Das Gatter A20 kann durch Verwenden der Tastatur-Steuereinheit (KBC) (Element 114A in Fig. 1) freigegeben werden. In einer bevorzugten Ausführungsform weist der KBC einen Intel-8042-Chip auf. Weil der 8042 im Vergleich zu einer 80386-CPU der bevorzugten Ausführungsform ein derartig langsamer Chip ist, ist ein Arbeiten mit dem KBC eine schwierige bzw. mühsame Aufgabe. Im einzelnen kann das Gatter A20 freigegeben werden durch: (1) Warten darauf, daß der Eingabepuffer der Tastatur-Steuereinheit (KBC- Eingabepuffer) leer wird, (2) Anfordern, an den Ausgabeport zu schreiben, (3) Warten darauf, daß der KBC den Befehl verarbeitet, (4) Senden eines Bytes mit an den Ausgabeport des KBC gesetztem Bit 1 und (5) Warten darauf, daß das A20- Gatter "herunterfährt (engl. settle down)", indem ein Befehl "Null-Puls-Ausgabeport" an den KBC gesendet wird, bis nachdem das Gatter A20 freigegeben worden ist. Fur Einzelheiten der vorausgehenden Beschreibung kann das IBM AT Technische Handbuch (erhältlich von International Business Machines), S. 1-51, 1-53 und 1-55, konsultiert werden.
Schritt 717 bestimmt auf der Basis des vorher gesicherten Statusflags, ob das Diskettenlaufwerk aktiv war, als die Wiederaufnahmefunktion initiiert wurde. Falls das Plattenlaufwerk aktiv war, setzt dann Schritt 718 wieder das Diskettenlaufwerk zurück, so daß der OS/2-Plattentreiber erkennt, daß etwas (z.B. der Wiederaufnahmeprozeß) stattgefunden hat, und dem Benutzer ein Alarmkasten angezeigt wird, der diesbezüglich mitteilt, "Diskettenlaufwerk nicht bereit" (z.B. Vorrichtung A:). Falls das Diskettenlaufwerk vorher nicht aktiv war, wird dann dieser Rücksetz-Schritt umgangen.
Zu Schritt 719 von Fig. 7B fortfahrend, wird eine Bestimmung vorgenommen, ob die CPU ursprünglich im geschützten Betrieb war. Dies wird durch Prüfen des vorher gesicherten Flags ausgeführt, das angibt, daß der ursprüngliche CPU-Betrieb gewechselt wurde. Falls die CPU tatsächlich ursprünglich im geschützten Betrieb war, wird dann Schritt 720 ausgeführt. Das Moduswechselflag, das angibt, daß der Betrieb gewechselt wurde, wird gelöscht. Danach werden der vorher gesicherte IDT-Registerwert und GDT-Registerwert wiederhergestellt (z.B. mit den LIDT- und LGDT-Anweisungen). Außerdem werden die Code- und Datenselektoren des geschützten Betriebs abgerufen bzw. wiedergewonnen, die MP- und TS-Bits werden wiederhergestellt, das PE-Bit wird in einer Speicherstelle eines Maschinenstatuswortes gesetzt, und dieser Wert wird in das tatsächliche Maschinenstatuswort gespeichert, wodurch die CPU in den geschützten Betrieb geschaltet wird. Schließlich wird das CS-Register mit einem geeigneten Wert für den geschützten Betrieb geladen, indem der Codeselektor für den geschützten Betrieb und der Offset der folgenden Anweisung auf den Stapel geschoben und eine RET-Anweisung ausgeführt wird.
Schritt 721 wird durchgeführt, indem der vorher gesicherte Stapelselektor und Zeiger sowie die DS- und ES- Register für den geschützten Betrieb wiederhergestellt werden. Als nächstes stellt Schritt 722 CR0, TSS und LDT wieder her. Schritt 722 lädt das vorher gesicherte Task- Register (TR) der aktuellen Aufgabe bzw. Task und stellt das Task-LDT-Register wieder her (weil das Wiederaufnahme- BIOS es nicht sichert). Die vorher gesicherte Codesegmentbeschränkung wird dann in den Codedeskriptor des Treibers korrigiert bzw. geschrieben.
Ob die CPU zum geschützten Betrieb zurückgeschaltet wurde oder nicht, Schritt 723 wird ausgeführt. Der Schritt 723 berücksichtigt, daß ein Drucken auf dem parallelen Druckerport nach einer Wiederaufnahme weitergeht. Normalerweise überspringt OS/2 die Druckerhardware-Unterbrechung, oder die Druckerunterbrechung tritt nach einer Wiederaufnahme überhaupt nicht mehr auf. Um dies zu umgehen, wird an die Druckervorrichtung (IRQ7) ein EOI-Befehl gesendet, und IRQ7 wird freigegeben. Danach wird das Freigabesignal hoch gesetzt, es tritt eine Verzögerung auf, und das Freigabesignal wird niedrig gesetzt.
Schritt 724 umfaßt einen Aufruf einer OEMHELP-Funktion IOCTL 88 (hex), um den automatischen Anzeige-Abschaltzähler zurückzusetzen, der in einer bevorzugten Ausführungsform auf Toshiba-Computern sowie auf bestimmten anderen Computern gefunden wird. Das automatische Anzeige-Aus-Merkmal schaltet normalerweise die Anzeige des Computers nach einer voreingestellten Zeitspanne einer Tastatur- und/oder Maus- Inaktivität automatisch aus. Falls eine Abschalt-Anforderung detektiert wird, wenn der Wiederaufnahmebetrieb freigegeben ist, würde die Inaktivitätsperiode des Zeitgebers nicht zuruckgesetzt werden, wenn die Energie anschließend wieder eingeschaltet wird. Deshalb könnte sich die Anzeige nach nur einer kurzen Zeit ausschalten, wenn der Computer wieder angefahren wird, ein unerwünschter Zustand. In einer bevorzugten Ausführungsform der vorliegenden Erfindung wird der automatische Anzeige-Abschaitzähler mit der IOCTL-88- (hex)-OEMHELP-Funktion bei Schritt 724 zurückgesetzt, nachdem die Energie wieder eingeschaltet ist. Auf diese Weise wird nach einer Wiederaufnahme der Anzeige-Aus-Zähler zurückgesetzt. Der Schritt 724 kann ausgeführt werden, indem auf ein geeignetes IOCtl-Paket mit ES:BX gezeigt und indem die OEMHELP-Funktion aufgerufen wird.
Der nach dieser Stelle ausgeführte nächste Schritt ist Schritt 725 von Fig. 7B. Dieser Schritt weist ein Wiederherstellen der vorher gesicherten Systemflags und -register auf, die auf den Stapel geschoben wurden, bevor die Energie abgeschaltet wurde. Nachdem Schritt 725 ausgeführt wurde, ist der Wiederaufnahmeprozeß komplett, und der Schritt 726 gibt an, daß der Wiederaufnahmetreiber die Steuerung durch Verwenden der IRET-Anweisung an die aktive Task von OS/2 zurückgibt.
Wie aus dieser ausführlichen Beschreibung ersichtlich ist, wurde eine bevorzugte Ausführungsform zum Implementieren der vorliegenden Erfindung auf einem Laptop-Computer von Toshiba, wie z.B. dem T3100SX oder T2000SX, beschrieben. Der Fachmann für Computerprogrammierung und/oder - hardwaredesign erkennt jedoch, daß die vorliegende Erfindung genauso einfach auf jedem beliebigen Computersystem mit einem fortgeschrittenen Mikroprozessor, einer intelligenten Energieversorgungsschaltung und einer vorher vorhandenen Wiederaufnahmeverarbeitungsfunktion für den grundlegenden "Real"-Betrieb des Mikroprozessors implementiert werden könnte. Außerdem ist das spezielle Anordnen der verschiedenen, vorher beschriebenen Schritte weitgehend beliebig und kann, sofern nicht anders angegeben, auf vielerlei Arten ausgeführt sein. Obgleich die bevorzugte Ausführungsform der vorliegenden Erfindung entworfen wurde, um unter OS/2 zu arbeiten, könnte schließlich ein Wiederaufnahmetreiber zur Verwendung mit irgendeinem anderen fortgeschrittenen Betriebssystem, wie z.B. UNIX etc., und irgendeinem anderen fortgeschrittenen Mikroprozessor, wie z.B. dem Motorola 680x0 etc., entworfen werden, indem einfach die geeigneten Arten von mit dem Betriebssystem und/oder Mikroprozessor verbundenen Daten modifiziert werden, die in den verschiedenen Schritten der vorliegenden Erfindung gespeichert und wiedergewonnen werden.

Claims

1. Verfahren zur Verwendung in einem Computersystem mit einer CPU, die in einem geschützten Betrieb und in einem Realbetrieb arbeiten kann, wobei das Verfahren zum Sichern von Information, die den Zustand der CPU vor einem Abschalten des Computer-Systems anzeigt, dadurch gekennzeichnet ist, daß ein Wiederaufnahme-Verarbeitungstreiber zur Durchführung der folgenden Schritte initialisiert wird:

(1) Empfangen (201) eines Abschalt-Detektionssignais, das anzeigt, daß Information des Computer- Systems gesichert werden muß;

(2) Sichern (505) von das Betriebssystem betreffender Information des geschützten Betriebs als Antwort auf Schritt (1);

(3) Schalten der CPU vom geschützten Betrieb in den Realbetrieb als Antwort auf Schritt (2); und

(4) Sichern (505) von die CPU des Computer-Systems betreffender Information des Realbetriebes als Antwort auf Schritt (3).

2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, daß es weiterhin einschließt:

(5) Empfangen (713) eines Einschalt-Signals zum Anzeigen, daß Information des Computer-Systems wiederhergestellt werden muß;

(6) Wiederherstellen (715) von Information des Realbetriebes als Antwort auf Schritt (5);

(7) Schalten (720) der CPU vom Realbetrieb in den geschützten Betrieb als Antwort auf Schritt (6); und

(8) Wiederherstellen (721, 722) von Information des geschützten Betriebes als Antwort auf Schritt (7).

3. Verfahren nach Anspruch 1 oder 2, weiterhin dadurch gekennzeichnet, daß die CPU unter dem OS2-Betriebssystem arbeitet.

4. Verfahren nach Anspruch 1, weiterhin dadurch gekennzeichnet, daß das Abschalt-Detektionssignal ein nicht-maskierbares Unterbrechungs-(NMI)-Signal ist.

5. Verfahren nach Anspruch 4, weiterhin dadurch gekennzeichnet, daß der Schritt der Initialisierung die Schritte einschließt:

(i) Laden (202) eines Wiederaufnahme-Verarbeitungstreibers, um die Schritte (1) - (4) auszuführen, und

(ii) Einsteigen ("hooking"; 603, 604) in einen Vektor, der einer nicht-maskierbaren Unterbrechung (NMI) zugeordnet ist, um die Schritte (1) - (4) als Antwort auf die NMI auszuführen.

6. Verfahren der Wiederaufnahmeverarbeitung nach Anspruch 5, indem der Schritt (ii) die Schritte einschließt:

(A) Einsteigen ("hooking"; 603) in einen Vektor des Realbetriebes, der einer NMI zugeordnet ist, um die Schritte (1) - (4) als Antwort auf die NMI auszuführen, die in der CPU auftritt, wenn die CPU im Realbetrieb arbeitet, und

(B) Einsteigen ("hooking"; 604) in einen Vektor des geschützten Betriebs, der einer NMI zugeordnet ist, um die Schritte (1) - (4) als Antwort auf die NMI auszuführen, die in der CPU auftritt, wenn die CPU im geschützten Betrieb arbeitet.