    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 Anwhlen eines XControl-CPX-
    Moduls mit zwei Bomben ab. Zunchst 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 beschftigte, 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, gehrt von Accessories (unter SingleTOS) 
    allozierter Speicher immer der gerade laufenden Hauptapplikation. Im 
    Normalfall (ohne Autostart-Applikation) gehrt 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 gehrt 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 Umstnden dazu, da fr XControl wichtige Daten 
    berschrieben werden, weil der Speicher jetzt vom neuen Programm belegt 
    wird. Die Folge sind die anfangs erwhnten Abstrze.

    Die Lsung ist das vorliegende ThingWait, ein Miniprogramm, das an 
    Stelle von Thing als Autostart-Applikation angemeldet wird. Es wartet 
    zunchst ein paar Sekunden (zur Konfiguration spter), 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  
    veranlat, 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 behlt ThingWait nur das ntigste (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 Umstnden laufen auch noch 
    einige andere Accessories jetzt stabiler mit Thing zusammen.

    Wer eigene Accessories programmiert, die beim Start Speicher anfordern 
    und dazu (manchmal) lnger 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 gehrt 
    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 knnen! Der Programmname entscheidet, wieviele 
    Sekunden ThingWait den Accessories fr ihre Initialisierung gewhren 
    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 einschlielich) liegen, bei berschreitung 
    wird die jeweils nchste Grenze genommen.

    Die ntige Sekundenzahl mu jeder fr sich selbst ermitteln, da es von 
    den benutzen Accessories und der TOS-Version abhngt. Prinzipiell 
    sollten 10 Sekunden auch fr Hrteflle reichen, allerdings ist es 
    ratsam, zunchst 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 groer Sorgfalt entwickelt und eingehend getestet; 
    trotzdem kann ich nicht garantieren, da es fehlerfrei ist. Ich 
    bernehme daher keine Verantwortung fr Schden, gleich welcher Art, 
    die direkt oder indirekt durch die sach- oder unsachgeme 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) vollstndig und unverndert 
    weitergegeben werden. ThingWait darf auch im Rahmen des Original-Thing-
    Pakets verbreitet werden, sollte Arno es aufgenommen haben. In diesem 
    Fall gehrt 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-Strae 7
    64665 Alsbach-Hhnlein
    Deutschland

    InterNet: binder@rbg.informatik.th-darmstadt.de
    IRC: Gryf

    Fr Fragen, Fehlerreports, Vorschlge, etc. stehe ich gerne zur 
    Verfgung!


    Technisches
    -----------

    Da sich ThingWait mit Ptermres(128, 0) beendet, bleiben zustzlich 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 fllt:

    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, whrend 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 
    gehrt, lediglich 240 Bytes (bei grerem Default-Environment 
    entsprechend mehr) verloren, ohne da dabei der Speicher strker 
    fragmentiert ist. Ich denke, dies lt sich ohne weiteres verkraften, 
    zumal man dann wieder volle Betriebssicherheit hat.

    Wer selbst bei einem einzigen Byte weniger Speicher in Trnen 
    ausbricht, knnte, eine passende GEMDOS-Version vorausgesetzt, 
    Environment und Basepage von ThingWait per Maddalt als zustzliches 
    Alternate RAM wieder zur Verfgung stellen. Ob das so viel bringt, 
    bleibt allerdings fraglich, zumal der Aufwand doch betrchtlich wre...

