home *** CD-ROM | disk | FTP | other *** search
/ TOS Silver 2000 / TOS Silver 2000.iso / Tools / THING.127 / THINWAIT / THINWAIT.TXT < prev   
Encoding:
Text File  |  1995-08-28  |  8.5 KB  |  181 lines
  1.     Anleitung zu ThingWait vom 28.08.1995
  2.     -------------------------------------
  3.  
  4.  
  5.     Was'n das?
  6.     ----------
  7.  
  8.     Immer wieder erlebte ich folgendes: Sobald Thing (unter SingleTOS als 
  9.     Autostart-Applikation angemeldet) ein Programm mit Auslagern gestartet 
  10.     hatte, stürzte danach der Rechner beim Anwählen eines XControl-CPX-
  11.     Moduls mit zwei Bomben ab. Zunächst schob ich die Schuld auf Thing, da 
  12.     das ganze vorher noch nie aufgetreten war. Doch als ich mich dann vor 
  13.     kurzem etwas intensiver mit dem Problem beschäftigte, wurde schnell 
  14.     klar, das Thing selbst nichts damit zu tun hat. Die Ursache liegt am 
  15.     Autostart-Mechanismus und an der Tatsache, daß XControl eine sehr lange 
  16.     Initialisierungsphase hat (vor allem, wenn man wie ich viele Module 
  17.     aktiv hat).
  18.  
  19.     Wie vielleicht bekannt ist, gehört von Accessories (unter SingleTOS) 
  20.     allozierter Speicher immer der gerade laufenden Hauptapplikation. Im 
  21.     Normalfall (ohne Autostart-Applikation) gehört also aller anfangs von 
  22.     XControl angeforderter Speicher dem Desktop, der ihn dann auch nie 
  23.     freigibt, da er nicht beendet werden kann. Mit Thing (prinzipiell auch 
  24.     mit anderen Programmen) als Autostart-Applikation sieht die Sache 
  25.     jedoch anders aus: Er wird meist gestartet, bevor XControl mit der 
  26.     Initialisierung komplett fertig ist, als Folge gehört ein Teil des 
  27.     XControl-Speichers (für das GEMDOS) jetzt nicht mehr dem Desktop, 
  28.     sondern Thing.
  29.  
  30.     Wird nun von Thing ein Programm mit der Option "Thing vor Programmstart 
  31.     auslagern" gestartet, beendet er sich, um ThingRun zu starten. In 
  32.     diesem Augenblick wird aller Speicher, den XControl angefordert hatte, 
  33.     als Thing bereits lief, wieder freigegeben. Das führt dann unter 
  34.     ungünstigen Umständen dazu, daß für XControl wichtige Daten 
  35.     überschrieben werden, weil der Speicher jetzt vom neuen Programm belegt 
  36.     wird. Die Folge sind die anfangs erwähnten Abstürze.
  37.  
  38.     Die Lösung ist das vorliegende ThingWait, ein Miniprogramm, das an 
  39.     Stelle von Thing als Autostart-Applikation angemeldet wird. Es wartet 
  40.     zunächst ein paar Sekunden (zur Konfiguration später), um Accessories 
  41.     wie XControl Zeit zur Initialisierung zu geben und beendet sich dann, 
  42.     um Thing nachzustarten. Damit beim Beenden nicht wie sonst der Speicher 
  43.     freigegeben wird, benutzt ThingWait dazu Ptermres, was das GEMDOS  
  44.     veranlaßt, allen Speicher, den ThingWait (und eben auch eventuell die 
  45.     Accessories) alloziert hatte, komplett aus der Speicherliste 
  46.     auszuklinken, d.h. er kann in der Folge nicht mehr angefordert werden 
  47.     und ist damit praktisch "auf ewig" belegt.
  48.  
  49.     Vom eigenen Code behält ThingWait nur das nötigste (128 Bytes), so daß 
  50.     im Prinzip wirklich nur der von den Accessories eventuell belegte 
  51.     Speicher zurückbehalten wird. Die erfreuliche Konsequenz: XControl 
  52.     bombt nicht mehr wie beschrieben, und unter Umständen laufen auch noch 
  53.     einige andere Accessories jetzt stabiler mit Thing zusammen.
  54.  
  55.     Wer eigene Accessories programmiert, die beim Start Speicher anfordern 
  56.     und dazu (manchmal) länger brauchen, sollte die Initialisierung 
  57.     übrigens mittels wind_update klammern, da die Autostart-Applikation 
  58.     nicht gestartet werden kann, wenn der Bildschirm gesperrt ist. Dadurch 
  59.     wird sichergestellt, daß der angeforderte Speicher dem Desktop gehört 
  60.     und nicht vorzeitig freigegeben wird.
  61.  
  62.  
  63.     Anwendung
  64.     ---------
  65.  
  66.     ThingWait wird, wie bereits angemerkt, an Stelle von Thing als 
  67.     Autostart-Applikation angemeldet. Es muß sich dazu im gleichen 
  68.     Verzeichnis wie THING.APP befinden oder Thing über die Environment-
  69.     Variable THINGDIR finden können! Der Programmname entscheidet, wieviele 
  70.     Sekunden ThingWait den Accessories für ihre Initialisierung gewähren 
  71.     soll. Dazu muß einfach irgendwo in den Programmnamen eine Zahl 
  72.     eingebaut werden. Beispiele: THINWT05.PRG -> Wartezeit 5 Sekunden, 
  73.     10THINWT.PRG -> 10 Sekunden, THING3WT.PRG -> 3 Sekunden. Wird keine 
  74.     Zahl gefunden, nimmt ThingWait 10 Sekunden an. Die Zahl muß übrigens 
  75.     zwischen 1 und 30 (jeweils einschließlich) liegen, bei Überschreitung 
  76.     wird die jeweils nächste Grenze genommen.
  77.  
  78.     Die nötige Sekundenzahl muß jeder für sich selbst ermitteln, da es von 
  79.     den benutzen Accessories und der TOS-Version abhängt. Prinzipiell 
  80.     sollten 10 Sekunden auch für Härtefälle reichen, allerdings ist es 
  81.     ratsam, zunächst kleinere Werte zu probieren, da 10 Sekunden doch recht 
  82.     lang sind, zumal (zumindest mir) das Booten sowieso _immer_ zu lange 
  83.     dauert...
  84.  
  85.  
  86.     Rechtliches
  87.     -----------
  88.  
  89.     ThingWait wurde mit großer Sorgfalt entwickelt und eingehend getestet; 
  90.     trotzdem kann ich nicht garantieren, daß es fehlerfrei ist. Ich 
  91.     übernehme daher keine Verantwortung für Schäden, gleich welcher Art, 
  92.     die direkt oder indirekt durch die sach- oder unsachgemäße Benutzung 
  93.     von ThingWait oder seine Untauglichkeit für einen bestimmten Zweck 
  94.     entstanden sind. Die Benutzung erfolgt auf eigene Gefahr!
  95.  
  96.  
  97.     Weitergabe
  98.     ----------
  99.  
  100.     ThingWait ist frei kopier- und benutzbar, es müssen jedoch immer alle 
  101.     Dateien (THINWAIT.APP und THINWAIT.TXT) vollständig und unverändert 
  102.     weitergegeben werden. ThingWait darf auch im Rahmen des Original-Thing-
  103.     Pakets verbreitet werden, sollte Arno es aufgenommen haben. In diesem 
  104.     Fall gehört THINWAIT.APP in das Verzeichnis THING und THINWAIT.TXT in 
  105.     das Verzeichnis DOC.
  106.  
  107.  
  108.     Autor
  109.     -----
  110.  
  111.     ThingWait wurde mit Pure C 1.0 geschrieben von:
  112.  
  113.     Thomas Binder
  114.     Johann-Valentin-May-Straße 7
  115.     64665 Alsbach-Hähnlein
  116.     Deutschland
  117.  
  118.     InterNet: binder@rbg.informatik.th-darmstadt.de
  119.     IRC: Gryf
  120.  
  121.     Für Fragen, Fehlerreports, Vorschläge, etc. stehe ich gerne zur 
  122.     Verfügung!
  123.  
  124.  
  125.     Technisches
  126.     -----------
  127.  
  128.     Da sich ThingWait mit Ptermres(128, 0) beendet, bleiben zusätzlich zu 
  129.     dem eventuell von Accessories belegten Speicher auch diese 128 Bytes 
  130.     und das Environment von ThingWait resident (weniger geht nicht, da 
  131.     mindestens die Basepage (ohne Kommandozeile) übrig bleiben muß). Die 
  132.     folgenden Beispieltabellen zeigen jedoch, daß es im Vergleich kaum in's 
  133.     Gewicht fällt:
  134.  
  135.     Freier Speicher mit Thing und ThingWait bei meinen Minimalsetup mit 
  136.     einigen Auto-Ordner-Programmen und XControl (TOS 4.04, 4MB Speicher):
  137.     Block #1: 3693828 bytes
  138.     Block #2: 9232 bytes
  139.     Block #3: 5792 bytes
  140.     Block #4: 256 bytes
  141.     Summary: 3709108 bytes in 4 blocks
  142.  
  143.     Setup wie oben, allerdings ohne ThingWait (also, wie anfangs 
  144.     beschrieben, mit abstürzendem XControl):
  145.     Block #1: 3711508 bytes
  146.     Block #2: 5792 bytes
  147.     Block #3: 256 bytes
  148.     Summary: 3717556 bytes in 3 blocks
  149.  
  150.     Gleicher Setup, allerdings komplett ohne Autostart-Applikation:
  151.     Block #1: 3684580 bytes
  152.     Block #2: 18720 bytes
  153.     Block #3: 5792 bytes
  154.     Block #4: 256 bytes
  155.     Summary: 3709348 bytes in 4 blocks
  156.  
  157.     Alle Messungen erfolgten direkt vom Desktop aus, also bei den ersten 
  158.     beiden Tabellen nach Beendigung von Thing. Man sieht, daß mit ThingWait 
  159.     240 Bytes weniger frei sind als ohne Autostart-Applikation. Diese 240 
  160.     Bytes sind Basepage und Environment von ThingWait. Im Vergleich zum 
  161.     Setup mit Thing als Autostart-Applikation fehlen sogar 8448 Bytes. 
  162.     Davon sind 240 wieder Basepage und Environment von ThingWait, die 
  163.     restlichen 8208 wurden von XControl angefordert, während ThingWait 
  164.     wartete. Diese für XControl lebenswichtigen 8208 Bytes gehen also ohne 
  165.     ThingWait verloren und werden überschrieben, sobald Thing ein Programm 
  166.     mit Auslagern nachstartet.
  167.  
  168.     Letztlich hat man also gegenüber dem "sichersten" Setup ohne jegliche 
  169.     Autostart-Applikation, bei der aller Accessory-Speicher dem Desktop 
  170.     gehört, lediglich 240 Bytes (bei größerem Default-Environment 
  171.     entsprechend mehr) verloren, ohne daß dabei der Speicher stärker 
  172.     fragmentiert ist. Ich denke, dies läßt sich ohne weiteres verkraften, 
  173.     zumal man dann wieder volle Betriebssicherheit hat.
  174.  
  175.     Wer selbst bei einem einzigen Byte weniger Speicher in Tränen 
  176.     ausbricht, könnte, eine passende GEMDOS-Version vorausgesetzt, 
  177.     Environment und Basepage von ThingWait per Maddalt als zusätzliches 
  178.     Alternate RAM wieder zur Verfügung stellen. Ob das so viel bringt, 
  179.     bleibt allerdings fraglich, zumal der Aufwand doch beträchtlich wäre...
  180.  
  181.