6. Rebuild-Funktion ------------------------ Wenn Sie eine neue Anwendung starten oder die aktuelle verlassen, so wird Ihr aufgebautes System von Info-Fenstern natrlich berschrieben. Ein besonderes Feature des Programms ist jedoch, da es die so berschriebene Konfiguration nach Mglichkeit vollstndig wiederherstellt, sobald Sie es anschlieend wieder aktivieren (Mentitel anklicken). Es werden alle Fenster (soweit mglich) wieder erzeugt und die im Speicher gehaltenen Datei-Inhalte in dem vorher verlassenen Zustand angezeigt. Beachten Sie also, da offene Fenster entsprechenden Speicherplatz blockieren knnen, wenn Sie sie nicht schlieen. Die Rebuild-Funktion bietet den Vorteil, die Fenster-Konfiguration in eine andere Applikation 'hinberretten' zu knnen. Dies gilt besonders fr Programme, die fast den gesamten verfgbaren Speicher fr sich reservieren, so da Accessories dann kaum noch Spielraum haben (das sind z.B. viele Textprogramme wie WORDPLUS oder TEMPUS). Mit 1st Guide knnen Sie in diesem Fall alle bentigten Fenster vorher ffnen, so da diese Programme von vornherein weniger Speicher bekommen. Nach dem Start des Programms kann dann problemlos auf die Konfiguration zugegriffen werden. Alle bisherigen Betriebssystemversionen haben die unangenehme Eigenschaft, da Accessories nicht als eigenstndige GEMDOS-Prozesse betrachtet werden. Dies hat zur Folge, da Speicher, der durch ein Accessory beim Betriebssystem angefordert wird, immer der gerade laufenden Hauptapplikation zugeordnet wird. Wenn man nun diese Hauptapplikation verlt, so wird automatisch aller von ihr (und dummerweise eben auch von benutzten Accessories) angeforderter Speicher durch das Betriebssystem freigegeben. Verlt man nun ein Programm, in welchem man mit 1st Guide Dateien geladen hat, so kann 1st Guide diese eben nicht restaurieren, da der dazu reservierte Speicherplatz ohne Rcksicht auf Verluste freigegeben wird. Um nun zu erkennen, ob ein Fenster "rebuildet" werden kann, benutzt 1st Guide eine von Atari dokumentierte Systemvariable, die auf den aktuellen GEMDOS-Proze zeigt (unter MSDOS wird dazu eine Funktion namens "get PSP" benutzt). Dieser Zeiger auf den aktuellen Proze-Descriptor wird nun bei jedem Laden einer Datei abgefragt und zu den Fensterdaten mit gesichert. Falls nun eine Rebuild-Situation eintritt, fragt 1st Guide den Zeiger auf den aktuellen Proze-Descriptor erneut ab und vergleicht diesen Wert mit dem gesicherten. Bei einer bereinstimmung kann nun das Fenster "rebuildet" werden, sonst nicht. Zustzlich wird der gesicherte Wert noch mit den Werten der Parent-Proze-Zeiger verglichen, da auch und gerade in diesem Fall ein Rebuild mglich ist. Dies ist mglich, da die Proze-Descriptoren nichts anderes als die Basepages sind, welche ber den Parent-Proze-Pointer untereinander verkettet sind, so da sich 1st Guide durch diese Proze-Liste 'durchhangeln' kann (der "Programm-Segment-Prfix" unter MSDOS bietet diese Mglichkeit nicht, hier kann nur der eigentliche Wert verglichen werden). Die hier beschriebene Vorgehensweise ist vllig legal und benutzt nur dokumentierte Features (kein Schreibzugriff auf "actpd" !), so da zuknftige Betriebssytemversionen keine Probleme bereiten sollten. Falls Accessories einmal den Status von 'richtigen' GEMDOS-Prozessen erhalten sollten (dies ist zu wnschen), funktioniert diese Methode ebenfalls und es knnen stets alle Fenster "rebuildet" werden, da das Programm dann immer seinen eigenen Proze-Descriptor "zu sehen" bekommen mte. Nachtrag: Unter MultiTOS gibt es keine Probleme, da weder Accessory- noch Applikationsfenster durch das System geschlossen werden.