zurück : weiter : inhalt =
 

4.6 *** Thing-Erweiterung

Diese ist nicht eigentlich Bestandteil des QDOS, soll aber kurz angerissen werden, weil sie einrseits das Sytem selbst ergänzt, und sie andererseits so weitgehende Anwendung erfahren hat, daß ihr Vorhandensein zum Quasi-Standard wurde.

Eine inhaltschwerere Bezeichnung konnte nicht gewählt werden. Alles und Nichts zugleich, sollen die Dinger auch weiter "Thing" genannt bleiben. Vorläufig(?) noch ein Haufen nutzlosen Codes, verzeichnet in Bereichen, die über die letzte der in-"offiziellen" verketteten Listen in

SV.THGL auf $B8(sb)
aufzuspüren sind (auch SV.THING oder SYS.THGL benannt).

Mit solcherlei Wissen ausgestattet soll diese Einrichtung nun näher betrachtet werden. Grundlage ist das Dokument hierzu von QJump und eine "halboffizielle" frei verfügbare (englischsprachige) Beschreibung (undatiert, Stand 1993(?)
 
 

4.6.1 ** Konzeption

Things sind Hilfsmittel mit freiem Verwendungszweck. Jeder Programmteil mag sich ihrer Unterstützung bedienen, sie entfernen und auch einrichten, wobei der aktuelle Job dann sein Besitzer wird. Grundsätzlich kann ein Thing vom Besitzer beliebigen Nutzern zur Verfügung gestellt werden. Selbst wird es in der genannten Liste SV.THGL verzeichnet. Besagte Nutzer werden in weiteren Tabellen notiert, die jedem einzelnen Thing als "usage list" zugeeignet sind. Zu Nutzung, Einrichtung oder Aufgabe wird im Thing-System das unbedingt Nötige bereits zur Verfügung gestellt.

Das Thing übernimmt erst einmal nur den Schutz beliebiger Datenstrukturen. Es sorgt dafür, daß der Zugriff aus dem Betriebssystem oder Programmen zerstörungsfrei erfolgt. Dann auch, daß reservierte Speicherbereiche bei Aufgabe ordentlich an das System zurückgegeben und die zugehörigen Tabellen bereinigt werden. Auch für die Sicherheit von Operationen aus einem Thing heraus ist gesorgt. Es wurden Regeln aufgestellt, die für die einwandfreie Arbeit dieser Schutzfunktionen einzuhalten sind.
 

4.6.1.1 * Organisation

Jedes Thing muß einen sonst unbenutzten Namen tragen.

Es ist ein Verkettungsblock im Common Heap erforderlich, der "link block", wo spezifische Daten eingetragen werden. Eine Tabelle, kurz "linkage" genannt, enthält Angaben zur Organisation und Vectoren auf Programme für besondere Verrrichtungen, die ähnlich den Trap-Aufrufen arbeiten. Schließlich wird ihm ein eigener Speicherbereich seiner Aufgabe entsprechend als "usage block" zugeteilt.

Der Besitzer eines Thing kann die Benutzung für einen einzigen oder für beliebig viele Nutzer zulassen. Der Code selbst und der besetzte Speicher bleiben davon unberührt. Sofern kein Zugriff angemeldet ist, und nur dann, kann ein beliebiges Programm es aus dem Speicher nehmen. Vor allen anderen Maßnahmen ist das Thing aus der Liste zu streichen. Nun erst können die zugehörigen Speicherbereiche dem Heap gefahrlos wieder zurückgegeben werden. Hierfür ist im Linkblock des Thing ggf. eine "remove" Routine anzugeben, von wo aus das Nötige organisiert wird.

Schließlich gibt es noch das erzwungene Entfernen, wofür im Linkblock auch eine "forced free" Routine zusätzlich eingetragen werden kann. Der Block selbst wird automatisch an den Heap zurückgegeben. Zugleich mit der Auflösung des Besitzerjobs werden auch seine Things weggenommen. Alle Jobs, die es gerade benutzen, werden ebenfalls entfernt.

Nur dann sind keine besonderen Vorkehrungen erforderlich, wenn sein Code im entsprechend verlängerten Linkblock enthalten ist. Ansonsten ist eine "remove"-Routine passend zu installieren, von wo aus die Heap-Zuweisung rückgängig gemacht und auch weitere ordnende Operationen durchgeführt werden können. Auch die "forced free"-Routine muß passend angegeben werden.

Wenn ein Thing selbst als Job eingerichtet wurde, kann es auf zweierlei Weise entfernt werden: Einmal als Thing, das den Job mitzunehmen hat, dann als Job, welcher seinerseits das Thing wegnehmen muß. Dafür ist eine Stelle vorzusehen, die gegenseitige Benachrichtigung beider Seiten erlaubt.

Das Thing muß aus der Systemliste genommen werden, der Job absoluten Vorrang erhalten und eine Suspendierung ist ggf. aufzuheben. Die innere Verkettung ist dargestellt dadurch, daß der Job Besitzer des Thing-Linkblockes ist. Sind diese Voraussetzungen gesichert, kann die gegenseitige Auflösung durchgeführt werden. Das muß im User-Mode geschehen.

Der Fall eines Angriffs auf den Speicherblock eines Thing durch Fremdeinwirkung, an den eigentlichen Wegen vorbei, ohne Aufruf der "remove"-Routinen, ist nicht abgesichert.
 

4.6.1.2 * Anwendung

Zunächst ein paar Worte zu dem, was wir von den Dingerchen erwarten dürfen.

Ausführbarer Programmcode, Systemerweiterungen in User- oder Supervisor-Mode, oder von mehreren Stellen benutzte Daten in freiem Format sind als Thing tauglich. Auch eine Sammlung allgemein benötigter Hilfsprogramme, "runtimes" oder andere "utilities", wäre dort unterzubringen. Und es könnten ihnen alle Aufgaben eines Device Handlers oder von Teilen eines Solchen übertragen werden.

Hardware-Things ohne irgendwelche aktiven Codeteile lassen sich einrichten. Dabei ist dann nur zu beachten, daß beim Entfernen jede Verbindung zu dieser Hardware aufgegeben wird, sie also zuvor zweckmäßig in einen sicheren Zustand gebracht worden sein muß (sic! - SER/PAR im SMSQ). Maßnahmen dieser Art sind z.B. Gegenstand der optionalen Routinen im Linkblock. Schließlich gibt es als einen procedural aufzubauenden Programmbereich noch die Spielart der Erweiterung-Things. Es sollen damit nach Vorbild der "Sprache" C Parameter transportiert und von Sprache wie System der Umgebung unabhängige Proceduren geschaffen werden können.

Für Funktionen, wie sie etwa durch die Konventionen des Basic beschrieben werden, auch Speicherzuweisungen etwa für Parameter variabler Länge, ist dort kein Platz.
 

4.6.1.3 * Aufbau

In der E-Software (SMSQ/E u.dgl), nicht im QDOS, gibt es ein paar Manager-Traps für das Thing-System. Wenn nun darauf Bezug genommen wird, ersetze man sie für das QDOS in Gedanken durch die Trap-Emulation, die weiter unten (4.6.2.2) beschrieben ist.

Als Grundstruktur wird ein Verkettungsblock (link block, auch thing linkage) eingerichtet, dessen Basisadresse beim Einfügen mit SMS.LTNG (1/38) in die Liste von SV.THGL auf $B8(sb) aufgenommen wird.
 
sms.ltng (1/38) besetzt die ersten vier Posten:
TH.NXTTH   0   Ptr auf nächsten Thing Linkblock
TH.USAGE   4   Ptr auf Verwendungsliste
TH.FRFRE   8   "force remove" Routine
TH.FRZAP 12   zur Entfernung des Besitzers 
Der thing header beschreibt und bestimmt die Anwendung:
TH.THING 16   Ptr auf das Thing selbst
TH.USE 20   Null oder Einleiten der Benutzung
TH.FREE 24   Null oder Freigabe
TH.FFREE 28   Null oder "force free" Routine
TH.REMOV 32   Null oder geordnetes Entfernen
TH.NSHAR 36 .b Marke für ungeteilte Nutzung
TH.VERID 38   Versions-Identifikation
TH.NAME 42 .w/.b  Standardstring für den Namen
 
Header für alle Typen:
THH.FLAG  0   "THG%" als Marke für einen Standard Header
THH.TYPE  4    Thing Typ:
    -1 Der Thing-Code selber
    0 Hilfsprogramme in freiem Format 
    1 Als Job ausführbarer Code
    2 Freies Format für geteilte Nutzung
    3 Erweiterungscode, Processor im User Mode
    4 Dto., Supervisor Mode
  Bit 24 Das Thing enthält weitere Things
 
Header einer Thing-Liste:
THH.NEXT   8   Null oder Offset zum nächsten Thing dieser Liste
THH.EXID 12   Zusätzliche Identifizierung
 
Header eines Job-Thing:
THH.HDRS   8   Offset zum Anfang des Job-Headers
THH.HDRL 12   Dessen Größe
THH.DATA 16   Größe des Datenspeichers
THH.STRT 20   Null für Start beim Job-Header, 
sonst absolute Aufrufadresse
 
Header eines Erweiterungs-Thing - "extension thing":
THH.NEXT     s.o.
THH.EXID     s.o. 
THH.PDEF 16   Null oder Offset zu Parameterdefinitionen
THH.PDES 20   Offset zur Beschreibung
THH.CODE 24   Einsprung, Aufruf muß mit RTS abgeschlossen werden.
 

4.6.2 ** Installation

Das Hotkey-System ab Ausgabe 2.03 enthält ein besonderes "Thing", mit dem die Trap#1-Aufrufe der ursprünglichen Thing-Installation nachgebildet werden. Dies erlaubt überhaupt erst  deren Verwendung im QDOS, wo Trap#1-Aufrufe nicht als Systemerweiterung so einfach nachgesetzt werden können.
 

4.6.2.1 * Thing Vectoren

THING Thing
Dies ist das o.g. Thing zur Trap-Nachbildung. Es heißt "THING" und hat als Einziges den Typen -1, womit es vor dem Zugriff durch das Thing-System selbst geschützt ist, also auch nicht entfernt werden kann.
Seine Definition:
THH.FLAG    dc.l "THG%" das Ding ist ein Thing
THH.TYPE    dc.l -1, kein Zugriff erlaubt
THH.ENTRY   dc.l th.entry Vector als absolute Adresse
THH.EXEC    dc.l th.exec dto.
Anstelle der SMS2-Trap #1 müssen im Qdos die betreffenden Routinen TH.ENTRY und TH.EXEC im User Mode über obige Vectoren aufgesucht werden.
Ihr Zweck ist mit TH.ENTRY der generelle Aufruf eines Thing ähnlich einem Trap-Aufruf, mit TH.EXEC der Aufruf eines Thing als Job.

Es folgt ein Beispiel zum Auffinden der Vectoren.:
 

4.6.2.2 * Trap-Emulation

Aufruf zum Heraussuchen der Thing-Vectoren

Eingang:

ohne Angaben
Ausgang:
D0 Null / Fehlercode
A1 Ptr auf th.entry / ohne Wert bei Fehler
Flags entsprechen D0, andere Register bleiben erhalten
 
thg_vec movem.l d1-d2/a0/a2,-(sp) 
move.w sr,d1 Rechner-Flags
trap #0 alles sperren (Things !)
move.w d1,-(sp) Processor-Status merken
moveq #0,d0 mt.inf zum Holen
trap #1 der Systemvariablen-Basis
move.l  $b8(a0),d0 sv.thgl
beq.s thg_nix ? ohne thinger ret err.nf
thg_fnd move.l d0,a0
ror.b #1,d0
bcs.s thg_nix ? Adressenfehler
move.l (a0),d0 ptr holen
bne.s thg_fnd ? weiter durchfädeln
lea thg_name(pc),a2 Name des THING-Thing
lea $2a(a0),a1 Länge des Namen
tst.b (a1)+
bne.s thg_nix ? ganz absurde Angabe, Fehler
move.b (a2),d0 Länge als Zähler
thg_nam cmp.b (a2)+,(a1)+ Länge und Zeichen
dbne d0,thg_nam ? weiter vergleichen
bne.s thg_nix ? falscher Name
move.l $10(a0),a1 Ptr zum Thing
cmp.l #'THG%',(a1)+ sicherheitshalber
bne.s  thg_nix  ? falscher Typen-Name
moveq #-1,d0 Typ wird okay-Flag
sub.l (a1)+,d0 justiert a1 auf th.entry
beq.s thg_xit ? THING-Thing gefunden
thg_nix moveq #-7,d0 err.nf
thg_xit move.w (sp)+,sr alte Betriebsart
tst.l d0 Flags nach Fehlercode
movem.l  (sp)+,d1-d2/a0/a2 
rts a1 Ptr auf th.entry
thg_name dc.b 5,'THING' 
 
Mit den Vectoren TH.ENTRY und TH.EXEC sind die folgenden Aufrufe möglich:

TH.ENTRY

Nur im User-Modus aufzurufen, erwartet dieselben Parameter wie die im Tabellenteil bei den Manager-Traps aufgeführte entsprechende SMS2-Trap.

Bei Aufruf erhalten die Register nach Bedarf

D0 Operationscode
D1 Job-ID oder -1
D2 zusätzliche Angaben
D3 dto. oder Wartezeit
A0 Ptr auf den Namen des Thing
A1 Ptr in den Link-Block
A2 zusätzliche Angaben
Die Op-Codes in D0 sind
 
SMS.LTHG 38 Thing einfügen
SMS.RTHG 39 unbenutztes Thing aus der Liste nehmen
SMS.UTHG 40 Thing in Betrieb nehmen
SMS.FTHG  41 freigeben
SMS.ZTHG 42  wegnehmen
SMS.NTHG 43 Nächstes Thing aufsuchen
SMS.NTHU 44 Nächsten Benutzer herausfinden
 
Zurückgegeben werden je nach Aufruf
D0 Fehlercode
D2 Job-ID oder zusätzliche Angabe
D3 Versions-ID
A1 Ptr in den Thing-Linkblock
A2 zusätzliche Angabe
TH.EXEC

Besorgt die Ausführung eines Thing, das als Job definiert ist, übergibt einen Standard-Parameterstring und öffnet einen Filekanal.

In den Registern sind zu übergeben:

D1 Null oder Besitzer-ID oder -1
D2 Priorität (hi.w) und Wartezeit (lo.w)
A0 Ptr auf einen Filenamen
A1 Ptr zum Parameterstring
Zurückgegeben werden
D0 Fehlercode
D1 Job-ID
Die anderen Register bleiben erhalten.
 

4.6.2.3 * Link Block

Alle diese Stellen werden aus SMS.LTHG mit Daten versehen.

Erst die folgenden Eintragungen sind bei der Einrichtung eines Thing vorzunehmen. Auch die Ptr auf die verschiedenen Routinen sind in jedem Falle zu besetzen. Diese Programmteile dienen der Behandlung besonderer Bedingungen beim Aufruf, der Feigabe oder dem Entfernen eines Thing. Ist dergleichen nicht erforderlich, trägt man Null ein. Dann wird das Thing-System selbst mit seinen Routinen die Randbedingungen überwachen.
 

Ist, was der Name sagt.
  An dieser Stelle kann die Adresse einer Routine eingesetzt werden, von der aus die eventuell erforderlichen ordnenden und vorbereitenden Operationen erledigt werden. Sie wird bei Anforderung einer Nutzung des Thing als SMS.UTHG aus TH.ENTRY mit dem entsprechenden Operationscode aufgerufen.

Ihr werden mit dem Aufruf übergeben:

D1 Job-ID
A1 Thing-Linkblock
A6 Basis der Systemvariablen
A7 Supervisor Stack
Zusätzliche Parameter stehen ggf. in D1, D2, A2.
Zurückzugeben sind
D0 Fehlercode
A0 Ptr auf Nutzbereich der Anwendung (usage block)
A0 zeigt auf den Zuweisungsblock eines Speicherbereiches, wie er etwa mit MM.ALLOC (Vector $0D8) eingerichtet wird, also nicht schon in den frei verwendbaren Bereich. Diese Adresse gilt als Basis des Usage Blocks. Zusätzliche Daten können in D2 und A2 übergeben werden. Der Zustand der anderen Register ist ungewiß. Das Dokument ist hierzu in mehreren Punkten widersprüchlich, sodaß auf nähere Angaben kein Verlass ist. Zur Sicherheit sollten sie unverändert zurückgegeben werden.
Insbes. die Übergabe des Supervisor-Stackptr im User-Modus ist fragwürdig: Kein Programm hat in diesem Zustand daran ewas zu schaffen, grundsätzich, aber vor allem, weil sein Wert dann ganz und gar unsicher ist.
  In A0 kommt der Ptr auf den "usage block", der von hier aus an den Heap zurückzugeben ist. Die anderen Register kommen mit Werten, wie schon in TH.USE. Auch die Rückgabe erfolgt so. Dabei dient A0 dann nur noch als Referenz zum Streichen dieses Arbeitsblocks aus der Verwendungsliste, wo über alle Benutzer eines Thing buchgeführt wird.

Mit diesem Aufruf kann ein Thing auch teilweise aufgegeben werden. Der eigentliche Speicherblock bleibt erhalten und A2 etwa gibt die Adresse eines untergeordneten Bereiches zurück. Der entsprechenden Auswahl dienen die zusätzlichen Angaben der anderen Register.
 

Außer Stack und Systemvariablenbasis werden übergeben
A0 Adresse des Usage Blocks
A1 Link-Block des Thing
Fehlermeldungen gibt es nicht. Die Bearbeitung ist wie in TH.FREE abzuwickeln.
A0 bleibt als einziges Register erhalten, womit nach Rückkehr dann die Verwendungsliste zu aktualisieren ist.
  Wenn ein Thing vollständig aufgegeben werden soll, kommt ein Aufruf hier her. Alle Speicherblöcke sind aufzulösen und sämtliche Operatione des Thing zu einem geordneten Ende zu führen. Danach gibt es keine Möglichkeit des Zugriffs mehr.
  Diese drei Posten werden oben angegebener Bestimmung gemäß ausgefüllt.
 

4.6.3 * Erweiterungs-Thing

Soll ein besonderes Übergabeprotokoll für Variable an ein Thing sein. Irgendwelche Proceduren als Code sollen damit Parameter empfangen und absenden können. "Das Dokument beschreibt einen Standard, der den Austausch grundsätzlich mit Proceduren jeder beliebigen Programmiersprache ermöglicht. Die Struktur erlaubt die Unterbringung zusammenhängender Proceduren innerhalb eines Thing. Sie lassen sich so vereinfacht auf dem Laufenden halten, der Systemüberhang wird verringert."

Genannter "Standard" ist nie wirklich einer geworden, und er is ausdrücklich auf ein - längst vergessenes - fremdes Betriebssystem ausgerichtet (SMS2), und so sieht der Autor keinen Sinn darin, diesen hier zu beschreiben, zumal wer im Thing-System programmieren will, ohnehin das Original-Dokument besitzen und konsultieren(!) sollte. Es sind im Tabellenteil nur die notwendigen Daten aufgeführt.

Tatsächliche Anwendungen sind nicht bekannt; sie können auf durchaus umständliche Verfahren hinauslaufen. Als probate Alternative bietet sich an, einen Block Proceduren mit einer Adressenliste zu versehen, deren Positionen dann als Vectoren auf die Routinen angesehen werden können.
Das HOTKEY System selbst und andere Erweiterungen (so z.B. WMAN) sind bewährte Beispiele.

Diese "Erweiterungs-Things" sind genaugenommen gänzlich überflüssig, sie leisten weniger, als die im QDOS ohnehin schon angelgten Devices, wie auch hier wieder das MEM-Device aus DVS der IO2-Sammlung (und den Beispielen zu PiQ) zeigt. Dort werden über spezielle OPEN-Codierung nicht Kanäle aufgemacht, sondern in D0 entweder die Einsprungadresse eines Vectors oder die Ergebnisse besonderer Aufrufe übergeben. Insofern entspricht diese Nutzung eines  OPEN-Aufrufs nicht nur o.g. proceduralen Teilen, sondern kann, ohne irgendwelche "neuartigen" Erweiterungen in das System hineinzufummeln, darüberhinaus auch noch einen Funktionswert zurückgegeben.
 

4.6.4 * Anwendung

Wenn hierzu nur wenig folgt, so liegt das daran, daß diese Things wirklich nur irgendwelche Dinger sind. Nicht ganz chaotisch zwar, da immerhin in geordneten Bahnen einzurichten, zu verwenden und wieder zu entfernen. Doch sonst erst einmal völlig passiv und ohne jede Vorbestimmung.

Der Nutzen offenbart sich durch die Anwendung, der die Thing-Struktur die sichere Umgebung bietet. Am Besten vielleicht als ein geschützter Speicherbereich, auf den man mit selbst programmierten Jobs zugreifen kann. Dies ohne auf Systemvariable angewiesen zu sein, oder gar - mit nur allzu bekannten Folgen - darauf einwirken zu müssen. Alles bei völlig freier Verwendung im Innern.

Ein Vergleich mit den Directory Device Handlern bietet sich an. Das Device wäre die Thing-Struktur, Things selbst die an Zahl unbegrenzten Laufwerke mit ihren Tabellen, wo die Files betreut werden. Die wiederum entsprächen den Usage-Listen. Die Kanäle wären dann die Usage Blöcke. Das Thing völlig der Sinngebung durch den Anwender untergeordnet, wie die Daten eines File auch.

Hotkey System II

Nur soviel sei erwähnt, daß das Hotkey System sich als Thing installiert. Dazu ist im Zusammenhang mit dem Thing- System wichtig, daß darin das THING-Thing mit den Vectoren der Trapemulation enthalten ist. Es erlaubt nur die ungeteilte Nutzung, so sollte es darum immer umgehend freigegeben werden. Sein Name ist 'Hotkey', ähnlich aufzufinden, wie das THING-Thing. Die besonderen Variablen und andere Definitionen dazu sind im Tabellenteil aufgeführt. Das System ist Anwendung der Things und des Qdos, nicht eigentlich eine Erweiterung.
 

  oben : zurück : weiter : inhalt 

= (count)