home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Vectronix 2
/
VECTRONIX2.iso
/
FILES_01
/
THIN100D.LZH
/
THING.GER
/
THINWAIT
/
THINWAIT.TXT
< prev
Wrap
Text File
|
1995-08-28
|
9KB
|
181 lines
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, stürzte 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 (für 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 führt dann unter
ungünstigen Umständen dazu, da₧ für XControl wichtige Daten
überschrieben werden, weil der Speicher jetzt vom neuen Programm belegt
wird. Die Folge sind die anfangs erwähnten Abstürze.
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 zurückbehalten 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 für 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 für sich selbst ermitteln, da es von
den benutzen Accessories und der TOS-Version abhängt. Prinzipiell
sollten 10 Sekunden auch für 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 für Schäden, gleich welcher Art,
die direkt oder indirekt durch die sach- oder unsachgemä₧e Benutzung
von ThingWait oder seine Untauglichkeit für einen bestimmten Zweck
entstanden sind. Die Benutzung erfolgt auf eigene Gefahr!
Weitergabe
----------
ThingWait ist frei kopier- und benutzbar, es müssen 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
Für Fragen, Fehlerreports, Vorschläge, etc. stehe ich gerne zur
Verfügung!
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 abstürzendem 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 für XControl lebenswichtigen 8208 Bytes gehen also ohne
ThingWait verloren und werden überschrieben, sobald Thing ein Programm
mit Auslagern nachstartet.
Letztlich hat man also gegenüber 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 Verfügung stellen. Ob das so viel bringt,
bleibt allerdings fraglich, zumal der Aufwand doch beträchtlich wäre...