Anleitung zu ThingWait vom 28.08.1995 ------------------------------------- Was'n das? ---------- Immer wieder erlebte ich folgendes: Sobald Thing (unter SingleTOS als Autostart-Applikation angemeldet) ein Programm mit Auslagern gestartet hatte, strzte danach der Rechner beim Anw„hlen eines XControl-CPX- Moduls mit zwei Bomben ab. Zun„chst schob ich die Schuld auf Thing, da das ganze vorher noch nie aufgetreten war. Doch als ich mich dann vor kurzem etwas intensiver mit dem Problem besch„ftigte, wurde schnell klar, das Thing selbst nichts damit zu tun hat. Die Ursache liegt am Autostart-Mechanismus und an der Tatsache, daž XControl eine sehr lange Initialisierungsphase hat (vor allem, wenn man wie ich viele Module aktiv hat). Wie vielleicht bekannt ist, geh”rt von Accessories (unter SingleTOS) allozierter Speicher immer der gerade laufenden Hauptapplikation. Im Normalfall (ohne Autostart-Applikation) geh”rt also aller anfangs von XControl angeforderter Speicher dem Desktop, der ihn dann auch nie freigibt, da er nicht beendet werden kann. Mit Thing (prinzipiell auch mit anderen Programmen) als Autostart-Applikation sieht die Sache jedoch anders aus: Er wird meist gestartet, bevor XControl mit der Initialisierung komplett fertig ist, als Folge geh”rt ein Teil des XControl-Speichers (fr das GEMDOS) jetzt nicht mehr dem Desktop, sondern Thing. Wird nun von Thing ein Programm mit der Option "Thing vor Programmstart auslagern" gestartet, beendet er sich, um ThingRun zu starten. In diesem Augenblick wird aller Speicher, den XControl angefordert hatte, als Thing bereits lief, wieder freigegeben. Das fhrt dann unter ungnstigen Umst„nden dazu, daž fr XControl wichtige Daten berschrieben werden, weil der Speicher jetzt vom neuen Programm belegt wird. Die Folge sind die anfangs erw„hnten Abstrze. Die L”sung ist das vorliegende ThingWait, ein Miniprogramm, das an Stelle von Thing als Autostart-Applikation angemeldet wird. Es wartet zun„chst ein paar Sekunden (zur Konfiguration sp„ter), um Accessories wie XControl Zeit zur Initialisierung zu geben und beendet sich dann, um Thing nachzustarten. Damit beim Beenden nicht wie sonst der Speicher freigegeben wird, benutzt ThingWait dazu Ptermres, was das GEMDOS veranlažt, allen Speicher, den ThingWait (und eben auch eventuell die Accessories) alloziert hatte, komplett aus der Speicherliste auszuklinken, d.h. er kann in der Folge nicht mehr angefordert werden und ist damit praktisch "auf ewig" belegt. Vom eigenen Code beh„lt ThingWait nur das n”tigste (128 Bytes), so daž im Prinzip wirklich nur der von den Accessories eventuell belegte Speicher zurckbehalten wird. Die erfreuliche Konsequenz: XControl bombt nicht mehr wie beschrieben, und unter Umst„nden laufen auch noch einige andere Accessories jetzt stabiler mit Thing zusammen. Wer eigene Accessories programmiert, die beim Start Speicher anfordern und dazu (manchmal) l„nger brauchen, sollte die Initialisierung brigens mittels wind_update klammern, da die Autostart-Applikation nicht gestartet werden kann, wenn der Bildschirm gesperrt ist. Dadurch wird sichergestellt, daž der angeforderte Speicher dem Desktop geh”rt und nicht vorzeitig freigegeben wird. Anwendung --------- ThingWait wird, wie bereits angemerkt, an Stelle von Thing als Autostart-Applikation angemeldet. Es muž sich dazu im gleichen Verzeichnis wie THING.APP befinden oder Thing ber die Environment- Variable THINGDIR finden k”nnen! Der Programmname entscheidet, wieviele Sekunden ThingWait den Accessories fr ihre Initialisierung gew„hren soll. Dazu muž einfach irgendwo in den Programmnamen eine Zahl eingebaut werden. Beispiele: THINWT05.PRG -> Wartezeit 5 Sekunden, 10THINWT.PRG -> 10 Sekunden, THING3WT.PRG -> 3 Sekunden. Wird keine Zahl gefunden, nimmt ThingWait 10 Sekunden an. Die Zahl muž brigens zwischen 1 und 30 (jeweils einschliežlich) liegen, bei šberschreitung wird die jeweils n„chste Grenze genommen. Die n”tige Sekundenzahl muž jeder fr sich selbst ermitteln, da es von den benutzen Accessories und der TOS-Version abh„ngt. Prinzipiell sollten 10 Sekunden auch fr H„rtef„lle reichen, allerdings ist es ratsam, zun„chst kleinere Werte zu probieren, da 10 Sekunden doch recht lang sind, zumal (zumindest mir) das Booten sowieso _immer_ zu lange dauert... Rechtliches ----------- ThingWait wurde mit grožer Sorgfalt entwickelt und eingehend getestet; trotzdem kann ich nicht garantieren, daž es fehlerfrei ist. Ich bernehme daher keine Verantwortung fr Sch„den, gleich welcher Art, die direkt oder indirekt durch die sach- oder unsachgem„že Benutzung von ThingWait oder seine Untauglichkeit fr einen bestimmten Zweck entstanden sind. Die Benutzung erfolgt auf eigene Gefahr! Weitergabe ---------- ThingWait ist frei kopier- und benutzbar, es mssen jedoch immer alle Dateien (THINWAIT.APP und THINWAIT.TXT) vollst„ndig und unver„ndert weitergegeben werden. ThingWait darf auch im Rahmen des Original-Thing- Pakets verbreitet werden, sollte Arno es aufgenommen haben. In diesem Fall geh”rt THINWAIT.APP in das Verzeichnis THING und THINWAIT.TXT in das Verzeichnis DOC. Autor ----- ThingWait wurde mit Pure C 1.0 geschrieben von: Thomas Binder Johann-Valentin-May-Straže 7 64665 Alsbach-H„hnlein Deutschland InterNet: binder@rbg.informatik.th-darmstadt.de IRC: Gryf Fr Fragen, Fehlerreports, Vorschl„ge, etc. stehe ich gerne zur Verfgung! Technisches ----------- Da sich ThingWait mit Ptermres(128, 0) beendet, bleiben zus„tzlich zu dem eventuell von Accessories belegten Speicher auch diese 128 Bytes und das Environment von ThingWait resident (weniger geht nicht, da mindestens die Basepage (ohne Kommandozeile) brig bleiben muž). Die folgenden Beispieltabellen zeigen jedoch, daž es im Vergleich kaum in's Gewicht f„llt: Freier Speicher mit Thing und ThingWait bei meinen Minimalsetup mit einigen Auto-Ordner-Programmen und XControl (TOS 4.04, 4MB Speicher): Block #1: 3693828 bytes Block #2: 9232 bytes Block #3: 5792 bytes Block #4: 256 bytes Summary: 3709108 bytes in 4 blocks Setup wie oben, allerdings ohne ThingWait (also, wie anfangs beschrieben, mit abstrzendem XControl): Block #1: 3711508 bytes Block #2: 5792 bytes Block #3: 256 bytes Summary: 3717556 bytes in 3 blocks Gleicher Setup, allerdings komplett ohne Autostart-Applikation: Block #1: 3684580 bytes Block #2: 18720 bytes Block #3: 5792 bytes Block #4: 256 bytes Summary: 3709348 bytes in 4 blocks Alle Messungen erfolgten direkt vom Desktop aus, also bei den ersten beiden Tabellen nach Beendigung von Thing. Man sieht, daž mit ThingWait 240 Bytes weniger frei sind als ohne Autostart-Applikation. Diese 240 Bytes sind Basepage und Environment von ThingWait. Im Vergleich zum Setup mit Thing als Autostart-Applikation fehlen sogar 8448 Bytes. Davon sind 240 wieder Basepage und Environment von ThingWait, die restlichen 8208 wurden von XControl angefordert, w„hrend ThingWait wartete. Diese fr XControl lebenswichtigen 8208 Bytes gehen also ohne ThingWait verloren und werden berschrieben, sobald Thing ein Programm mit Auslagern nachstartet. Letztlich hat man also gegenber dem "sichersten" Setup ohne jegliche Autostart-Applikation, bei der aller Accessory-Speicher dem Desktop geh”rt, lediglich 240 Bytes (bei gr”žerem Default-Environment entsprechend mehr) verloren, ohne daž dabei der Speicher st„rker fragmentiert ist. Ich denke, dies l„žt sich ohne weiteres verkraften, zumal man dann wieder volle Betriebssicherheit hat. Wer selbst bei einem einzigen Byte weniger Speicher in Tr„nen ausbricht, k”nnte, eine passende GEMDOS-Version vorausgesetzt, Environment und Basepage von ThingWait per Maddalt als zus„tzliches Alternate RAM wieder zur Verfgung stellen. Ob das so viel bringt, bleibt allerdings fraglich, zumal der Aufwand doch betr„chtlich w„re...