XShutdown hat mich viele Stunden angestrengten Denkens gekostet, weil es wirklich
nirgendwo dokumentiert ist, was w„hrend des normalen Systemabschlusses geschieht.
Normalerweise kennt OS/2 zwei verschieden Systemabschluá-APIs:
- DosShutdown schlieát nur alle ge”ffneten Dateien, schreibt
die Dateisystem-Puffer zurck und l”st alle Dateisysteme; das passiert nach dem
Drcken von Strg-Alt-Entf (Ctrl-Alt-Del). Anwendungen werden nicht
ordnungsgem„á geschlossen,
und die WPS wird auch nicht gesichert.
- WinShutdownSystem ist eine API, die zum Presentation Manager
geh”rt und alle Fenster schlieát, die WPS sichert und schlieálich DosShutdown
aufruft. Dies ist die normale Systemabschluá-Prozedur: Sie wird ausgefhrt,
wenn Sie "Systemabschluá" aus dem Kontextmen des Desktops oder die entsprechenden
Symbole aus der Klickstartleiste oder dem WarpCenter ausw„hlen.
Das Problem ist, daá es keine Funktion "zwischen" diesen beiden gibt. Wenn Sie
DosShutdown aufrufen, wird die WPS nicht gesichert,
und bei WinShutdownSystem
legt der normale Systemabschluá los, ohne daá man irgendeine M”glichkeit h„tte,
noch einzugreifen.
Das bedeutete, daá ich quasi ein komplett neues WinShutdownSystem programmieren
muáte, das hier jetzt erkl„rt wird. Dies war ziemlich schwierig, da IBM kaum irgendetwas
darber erkl„rt, was wirklich w„hrend WinShutdownSystem passiert.
Hinweis: In XFolder benutzen der "Erweiterte Systemabschluá" und "WPS
neustarten" denselben Code; der einzige Unterschied sind die Aktionen, die nach dem
Schlieáen aller Fenster ausgefhrt werden. Deshalb werde ich den Begriff "XShutdown"
in den folgenden Erkl„rungen fr beide benutzen, wenn nicht anders angegeben.
XShutdown ist in die WPS integriert und ist sehr stark von
den XFolder-Ersatzklassen abh„ngig. Bewuát habe ich den XShutdown-Code
nicht einer separaten .EXE-Datei mitgeliefert: zum einen braucht XShutdown Zugriff
auf WPS-interne Daten, die nur durch SOM erreichbar sind; zum zweiten will
ich die Leute davor bewahren, XShutdown ohne installierte XFolder-Klassen
zu starten, da dies die WPS besch„digen k”nnte. Genauer gesagt ben”tigt XShutdown
die Klasse XFldObject und den XFolder-Worker-Thread, die die WPS-internen Daten
zug„nglich machen.
Um zu verstehen, was XShutdown tut, muá man wissen, wie die
WPS ihre Objekte intern verwaltet. Jedes einzelne Objekt, das
zu einem Zeitpunkt fr die WPS relevant wird, sei es durch Bev”lkern eines Ordners,
durch Abfragen der Einstellungen oder durch Starten eines Programmes oder
durch was auch immer, wird -- in WPS Terminologie -- vom System "aufgeweckt"
("awakened"); das bedeutet, daá es als SOM-Objekt im Speicher existiert.
Die WPS schl„fert nur selten wache Objekte wieder ein, was die Freigabe
des damit verbundenen Speichers und einer Sicherung der Daten des Objekts auf
Festplatte zur Folge h„tte.
Das hat zwei Konsequenzen:
- Es gibt immer mehr "wache" Objekte auf Ihren System, als Sie in diesem
Moment annehmen wrden, da die meisten von ihnen gerade nicht sichtbar sind.
Sogar wenn Sie einen Ordner geschlossen haben, bleiben die Objekte darin wach;
das beschleunigt das Bev”lkern des Ordners, wenn er zum zweiten Mal ge”ffnet
wird. Das fhrt dazu, daá die WPS mit jedem Ordner, der ge”ffnet wird,
immer mehr und mehr Speicher belegt. (Wenn Sie von XShutdown eine Logdatei
erstellen lassen, k”nnen Sie sehen, wie viele wache Objekte von XShutdown
gesichert werden; normalerweise sind das einige hundert Objekte, auch wenn
XShutdown nicht alle Objekte sichert, sondern nur die Ableitungen von WPFolder
und WPAbstract. Unter dem Reiter "Interna" im Einstellungsnotizbuch des
Arbeitsoberfl„che k”nnen Sie sehen, wie viele Objekte derzeit wach sind.)
- Eine Žnderung der Objekt-Daten aktualisiert manchmal nur das SOM-Objekt im
Speicher, wird aber nicht auf Festplatte oder in OS2.INI / OS2SYS.INI gespeichert.
Darum ger„t die WPS manchmal ins Schleudern, wenn Sie gr”áere Žnderungen durchgefhrt
haben, wie das Bewegen eines Ordners, der viele abstrakte Objekte enth„lt, und
danach nicht richtig herunterfahren: die physikalischen Daten auf der Festplatte
und die WPS-Eintr„ge unterscheiden sich dann.
Dafr braucht XShutdown die Klasse XFldObject, die WPObject ersetzt.
Jedes mal, wenn ein Objekt aufgeweckt wird, ruft die WPS diverse Methoden auf
(darunter wpInitData und wpObjectReady).
XFldObject ersetzt diese und bergibt die Speicheradresse des Objekts an den
Worker-Thread, der dann die XFolder-interne Liste aller momentan wachen
Objekte aktualisiert. Soweit ich weiá, gibt es keinen anderen Weg herauszufinden,
welche Objekte gerade wach sind; auf jeden Fall gibt es auch keine dokumentierte
API, die diese Objekte auflisten k”nnte.
Wenn XShutdown nun aufgerufen und best„tigt wird, startet es
als erstes fr die folgende Systemabschluá-Prozedur zwei neue Threads, die
parallel zu den regul„ren WPS-Threads laufen; der
Haupt-"Systemabschluá-Thread" mit der Nachrichtenschlange fr
das Status-Fenster, und der "Update-Thread",
der die OS/2-Fensterliste berwacht und Nachrichten an den Hauptthread
absetzt, wenn das Status-Fenster aktualisiert werden muá.
Daher ist das Schlieáen aller momentan ge”ffneten Fenster ein kompliziertes
Zusammenspiel dieser beiden Threads:
Der Systemabschluá-Thread schlieát ein Fenster und geht dann so lange in
den Leerlauf, bis der Update-Thread eine Žnderung in der Fensterliste meldet
(was bedeutet, daá erfolgreich geschlossen wurde) und den
Systemabschluá-Thread benachrichtigt, der dann wiederum das n„chste Fenster schlieát,
bis kein Fenster mehr brig ist.
Nachdem alle Fenster geschlossen worden sind, beendet sich der Update-Thread.
Jetzt geht der Systemabschluá-Thread die Liste aller momentan wachen
Objekt durch (s.o.) und zwingt sie durch den Aufruf der
wpSaveImmediate-Methode, ihre Daten in die INI-Dateien oder auf
Festplatte zu schreiben.
Dies geschieht nur fr die Ableitungen von WPAbstract und WPFolder, weil
nach meiner Erfahrung alle anderen Klassen ihre Daten direkt speichern.
(Ich habe einmal versucht, alle Ableitungen von WPFileSystem zu sichern,
und dies verursachte jede Menge Erweiterter Attribute fr jede
einzelne Datei, die jemals von der WPS geweckt wurde. Abgesehen davon dauert
der Systemabschluá dann ewig lange.)
Zuletzt, je nach dem welche Aktion gewnscht wird, fhrt der
Systemabschluá-Thread folgendes aus:
- Wenn Sie "WPS neustarten", ausgew„hlt haben,
ruft der Systemabschluá-Thread einfach nur DosExit(EXIT_PROCESS, 0)
auf. Da XFolder Teil des Workplace-Prozesses ist und die gesamte WPS in diesem
einen Prozeá l„uft (der zweiten Instanz von PMSHELL.EXE),
beendet dies die komplette Workplace Shell. Der Shell-Prozeá (die erste
Instanz von PMSHELL.EXE) startet dann die WPS automatisch neu.
- Wenn Sie "Systemabschluá" und "Rechner neu starten"
ausgew„hlt haben, speichert XShutdown auch die INI-Dateien.
Das ist n”tig, weil DosShutdown, das anschlieáend aufgerufen wird,
diese nicht sichert.
(Wahrscheinlich deshalb, weil die APIs fr INI-Dateien zum Presentation Manager
geh”ren.) Da die INI-APIs es verbieten, einfach die User- und
System-Profile zu schlieáen (was die Daten aller anderen Profile auf Festplatte sichern
wrde), kopiert XFolder sie in zwei tempor„re Dateien, l”scht die
Originale, und benennt dann die tempor„ren um.
Nach DosShutdown ("L”se Dateisysteme...") wird das System mit
einem Aufruf des Ger„tetreibers DOS.SYS neu gestartet.
Diese Funktion ist in EDM/2 Band 5, Ausgabe 9
beschrieben.
- Wenn Sie "Systemabschluá" OHNE "Rechner neu starten"
ausgew„hlt haben, schaltet XShutdown nach DosShutdown
die Fensterliste ab und blockiert das System einfach durch einen Aufruf von
DosEnterCritSec und einer unendlichen Schleife. Da alle Dateisysteme
geschlossen sind, sollte keine andere Aktion auáer dem Ausschalten oder Neustarten
des Rechners mehr m”glich sein.