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:

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:

  1. 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.)
  2. 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: