• Abstrakte Objekte haben f�r gew”hnlich ein h”herwertiges Wort von 0x0002 und ihr niederwertiges Wort ist in der Sektion PM_Abstract:Objects der Datei OS2.INI mit den Daten des Objekts aufgef�hrt.

  F�r abstrakte Objekte wird immer ein Handle angelegt, da sie keinen Dateinamen besitzen und das Handle der einzige Weg ist, um auf sie zuzugreifen, sofern ihnen nicht auch eine Objekt-ID zugewiesen wurde.

• Im Gegensatz dazu haben Dateisystemobjekte (Dateien und Ordner) nicht immer ein Handle zugeordnet. Wurde eines zugewiesen, dann haben Dateisystemobjekte ein h”herwertiges Wort von 0x0003. Das niederwertige Wort stammt aus der Datei-Handle-Datenbank in der Sektion PM_Workplace:HandlesX der OS2SYS.INI.

  Beachten Sie, daá es zwei Sektionen namens PM_Workplace:HandlesX gibt (wobei X eine 0 oder 1 ist). Die WPS h„lt die Liste der Dateisystem-Handles die ganze Zeit im Speicher und schreibt sie nur von Zeit zu Zeit in die OS2SYS.INI. Dabei �berpr�ft sie zuvor den Schl�ssel PM_Workplace:ActiveHandles um herauszufinden, welche der zwei Sektionen zur Zeit aktiv ist, schreibt die Handles zur anderen Sektion und modifiziert diesen Schl�ssel so, das er anschlieáend zur anderen Sektion zeigt. Das ist notwendig, da die Eintr„ge in &os2;-INI-Dateien nicht mehr als 64 KB an Daten enthalten d�rfen. Deshalb muá die WPS mehrere Bl”cke benutzen, um die ganze Handle-Tabelle speichern zu k”nnen.

In der Theorie sollte die WPS ein Handle f�r ein Dateisystem-Objekt nur anlegen, wenn dieses wirklich gebraucht wird, z.B. wenn auf das Objekt wirklich irgendwo verwiesen wurde.

Handles des Dateisystems k”nnen jedoch auch Probleme verursachen. Je mehr Handles existieren, desto langsamer wird die WPS im allgemeinen. Was am wichtigsten ist: die Gesamtzahl der Handles ist begrenzt. Falls zu viele Dateisystem-Handles vorhanden sind, kann die WPS instabil werden.

Unter anderem werden Datei-Handles in den folgenden Situationen erzeugt:

1. Bei Programmobjekten und Referenzen. Das ist w�nschenswert, da dadurch Programmobjekte und Referenzen immer noch auf das korrekte Zielobjekt zeigen k”nnen, wenn sich das Zielobjekt nicht mehr an der urspr�nglichen Stelle befindet.

   Wenn Sie beispielsweise im Einstellungsnotizbuch eines Programmobjektes einen Pfad zu einer ausf�hrbaren Datei eingeben, fordert das Programmobjekt ein Handle an, weswegen es ein neues erhalten sollte, falls noch keines existiert. Das gleiche gilt, wenn man eine Referenz eines Objektes anlegt.

2. Bei anderen Teilen der WPS (und &xwp;), um Objektreferenzen abzulegen. &xwp; benutzt z.B. Objekt-Handles, um sich die Objektdruckkn”pfe des &xcenter; zu merken.

3. Wenn bei einem Objekt eine Objekt-ID vergeben wird (also eine dieser Zeichenketten in eckigen Klammern, z.B. <WP_DESKTOP>). Objekt-IDs werden in der Sektion PM_Workplace:Location der OS2.INI zusammen mit dem Objekt-Handle abgelegt und k”nnen nur aufgel”st werden, wenn das Handle g�ltig ist.

   Das Hauptproblem an dieser Implementation ist, daá die WPS die Arbeitsoberfl„che nicht mehr findet, sobald die Datei-Handles-Tabelle besch„digt ist, weil sie die Objekt-ID <WP_DESKTOP> benutzt, um sie beim Hochfahren zu lokalisieren. Wenn Sie den Dialog "Arbeitsoberfl„che konnte nicht gefunden werden" erhalten, ist in 95% der F„lle die Datei-Handles-Tabelle besch„digt.

4. Bei Anwendungsprogrammen, die die Win*-APIs benutzen, um WPS-Objekte anzulegen oder mit diesen zu arbeiten. Das ist normalerweise tolerierbar, wenn es nur einige Dateien betrifft. Leider ben”tigen einige dieser APIs (solche wie WinMoveObject) Objekt-Handles als Eingabe.

5. Bei jedem Ordner der jemals ge”ffnet wurde. Das ist auch tolerierbar, weil die WPS ein Ordner-Handle dazu benutzt, seine Fensterposition in der OS2.INI festzuhalten, so daá die Position des Ordners nicht verloren geht, wenn dieser verschoben wird.

6. Automatisch f�r jeden Stammordner im Pfad der Datei, wenn ein neues Handle f�r diese Datei erstellt wurde. Der Grund liegt in der Implementierung der Handle-Datenbank, welche nur den Kurznamen von jedem Dateisystemobjekt und eine Referenz mit den Kurznamen zu seinen "Eltern" ablegt. Das ist dadurch sehr effizient, weil ein Ordner, der mit vielen Unterobjekten verschoben wird, nur einen einzigen Eintrag in der Datenbank aktualisieren muá. Die Unterobjekte haben nur ein Stamm-Handle abgelegt, welches weiterhin funktioniert.

7. Bei jeder Datendatei, die durch eine Programmobjektzuordnung ge”ffnet wird. Das kommt daher, weil die WPS die Umgebungsvariable WP_OBJHANDLE zum Handle der Datendatei setzt, die ge”ffnet wurde. Einige Programme sind darauf angewiesen, es hat jedoch den ungewollten Effekt, das jedesmal ein Handle angelegt wird, wenn Sie auf eine Datendatei doppelklicken, auch wenn die Anwendung dieses Handle nicht ben”tigt.

   &xwp; erlaubt durch seine erweiterten Dateizuordnungen, dieses Verhalten abzuschalten.

8. Die WPS legt leider auch Handles f�r jedes Objekt an, welches durch die automatische Aktualisierung des Ordners aktualisiert wird. Das geschieht, wenn der Ordner ge”ffnet ist und man darin irgendetwas von der Befehlszeile aus tut (oder wenn andere Anwendungen etwas mit Dateien in diesem Ordner machen). Dann wird f�r jede Datei, die ge„ndert wird, ein neues Handle erzeugt.

   Ein einfacher Testfall daf�r ist, eine ZIP-Datei in einem offenen Ordner zu entpacken. Das wird viele Dateisystem-Handles erzeugen, die wahrscheinlich nie wieder benutzt werden. Als Ergebnis dieses Verhaltens wird eine groáe Anzahl von Dateisystem-Handles erzeugt.

   Nochmals, da diese Objekt-Handles niemals entfernt werden, verbleiben diese �berfl�ssigen Handles f�r immer im System.

   Dieses Problem wird durch &xwp;s automatische Aktualisierung von Ordnern behoben.