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: 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:

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