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 geschieht nach dem Drcken von Strg-Alt-Entf (Ctrl-Alt-Del).
Anwendungen werden nicht ordnungsgem„á geschlossen, und die WPS
wird auch nicht gesichert.
- WinShutdownSystem ist ein API, das 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
der Arbeitsoberfl„che 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: Bei &xwp; benutzen der "Erweiterte Systemabschluá" und "WPS
neu starten" 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
&xwp;-Ersatzklassen
abh„ngig. Bewuát habe ich den &xshutdown;-Code nicht in einer separaten
.EXE-Datei mitgeliefert: zum einen erfordert &xshutdown; Zugriff auf WPS-interne
Daten, die nur im SOM-Kontext erreichbar sind; zum zweiten will ich die Leute
davor bewahren, &xshutdown; ohne installierte &xwp;-Klassen zu starten,
da dies die WPS besch„digen k”nnte. Genauer gesagt ben”tigt
&xshutdown; die Klasse XFldObject und den &xwp;-Worker-Thread, die zusammen
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 wache Objekte nur sehr selten 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 nachdem 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 "&xwp;-Status" im Objekt "&xwp;-Konfiguration"
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 physischen 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 &xwp;-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; den
Haupt-"Systemabschluá-Thread"
mit der Nachrichtenschlange fr das Status-Fenster, und den "Update-Thread",
der die &os2;-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á das Fenster 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 neu starten", ausgew„hlt
haben, ruft der Systemabschluá-Thread einfach nur DosExit(EXIT_PROCESS,
0) auf. Da &xwp; 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 per Strg-Alt-Entf mehr m”glich sein.