ASM86FAQ - Datenstrukturen
MCB-Struktur (Memory Control Block [DOS])
Juergen Thelen 2:2450/55.5:
{ Struktur: MCB [DOS]
Ofs Typ Bezeichnung
00H B Identifier 01H W Owner 03H W BlockSizeInParas 05H 3 B unbenutzt (Scratch)
--- DOS 2.0+ -------------------------------------------------------------
08H 8 B unbenutzt (Scratch)
--- DOS 4.0+ -------------------------------------------------------------
08H 8 B PrgName
--- DOS 5.0+ -------------------------------------------------------------
08H 2 B TypeID 0aH 6 B unbenutzt (Scratch)
}
MCBs werden direkt (vom Programm) oder indirekt (von COMMAND.COM oder ver- schiedenen DOS-Funktionen (z.B. EXEC, INT 21.4b??H)) erzeugt, wenn Speicher (z.B. über die Funktion INT 21.48??H) reserviert wird. Erzeugte MCBs begin- nen immer auf 0MOD16-Boundaries, sind generell einen Paragraph (= 16 Bytes) lang, und werden dem eigentlichen (reservierten) Speicherbereich vorgesetzt.
Identifier, Offset 00H, Byte:
4dH = 'M' diesem MCB folgen noch ein oder mehrere andere MCBs 5aH = 'Z' dieser MCB ist der letzte MCB der Gesamtkette
Die Segmentadresse des allerersten MCBs im System ist in der List of Lists (LOL) von DOS verzeichnet. Um sie zu ermitteln, holt man sich zunächst die Adresse der LOL über INT 21.52??H nach ES:BX und liest danach das Word an Adresse (ES:BX) - 2 aus.
Für die Einsteiger: die vorstehende Klammerung von ES:BX soll hervorheben, daß die gesamte segmentierte Adresse um den Wert 2 vermindert werden muß, bevor das Word ausgelesen werden kann. Grund: Je nach DOS-Version kann es sein, daß die von INT 21.52??H zurückgegebene LOL-Adresse z.B. ????:0000H ist. Würde man hier mit ¯mov ax, [es:bx-2]® auslesen, oder vorher nur BX um 2 vermindern, käme es u.U. zu einer Fehladressierung (????:fffeH)... &)
Der erste MCB im System verwaltet das DDS (DOS Data Segment). Im DDS sind Informationen über Gerätetreiber und alle möglichen CONFIG.SYS Variablen enthalten. Seit DOS 4.0+ wird das DDS in mehrere Untersegmente unterteilt, die jeweils ihren eigenen Kontrollblock besitzen, einen sogenannten DDSSCB (DOS Data Segment Subsegment Control Block). Natürlich besitzt ein solcher DDSSCB (siehe dazu auch Topic STR0004) eine andere Struktur als ein MCB, aber das nur am Rande... ;)
Bei MCBs vom Typ 4dH ('M'), kann die Segmentadresse des nachfolgenden MCBs durch (Segmentadresse aktueller MCB + 1 + BlockSizeInParas) ermittelt wer- den. Sobald die Segmentadresse eines MCBs den Wert 9ffeH überschreitet, handelt es sich i.d.R. um einen sogenannten UMB (Upper Memory Block).
Owner, Offset 01H, Word:
Über dieses Word lässt sich der Besitzer des MCBs ermitteln. Normalerweise entspricht er der Segmentadresse des PSPs (Program Segment Prefix, siehe auch Topic STR0002) des besitzenden Programmes. Bestimmte Werte haben al- lerdings besondere Bedeutungen:
0000H MCB ist frei (i.d.R. Environment-Leichen beendeter Programme) 0006H MCB ist ein XMS UMB (nur DR-DOS) 0007H MCB ist ein sogenannter Excluded UMB (nur DR-DOS) 0008H MCB gehört DOS
Es gibt noch weitere Spezialwerte jenseits von fff0H, aber diese sind im allgemeinen hierzulande bedeutungslos (386MAX, usw.)
BlockSizeInParas, Offset 03H, Word:
Größe des über den MCB verwalteten Speicherblocks in Paragraphen (16 Byte) welcher unmittelbar auf den MCB folgt.
PrgName, Offset 08H, 8 Bytes:
Wenn als Owner die Segmentadresse eines gültigen PSPs vorliegt, findet man ab DOS 4.0+ in PrgName den Namen (OHNE Extension) des zugehörigen Program- mes. Sollte der Name kürzer als 8 Byte sein, wird er durch ein 00H-Byte terminiert (ASCIZ).
Ist DOS der Owner (0008H oder 0000H), findet man in PrgName leider meist nur Müll. Erst ab DOS 5.0+ wird in diesem Fall weiter klassifiziert (siehe nachstehende Beschreibung von TypeID).
TypeID, Offset 08H, 2 Bytes:
Ab DOS 5.0+ dienen diese Bytes der weiteren Blockklassifizierung. Das gilt allerdings nur für MCBs, deren Owner DOS ist (0008H oder 0000H), ansonsten gilt nach wie vor PrgName (siehe vorstehende Beschreibung).
Wie dem auch sei, hier die Klassifizierungen:
53H, 43H = 'SC' DOS-Systemprogramm oder Excluded UMB 53H, 44H = 'SD' DOS-Systemdaten 53H, 4dH = 'SM' Letzter UMB
PSP-Struktur (Program Segment Prefix [DOS])
Juergen Thelen 2:2450/55.5:
{
Ofs Typ Bezeichnung
00H 2 B OldExitInstruction 02H W FollowSeg 04H B unbenutzt 05H 5 B FarCallInt21H 0aH D VectorInt22H 0eH D VectorInt23H 12H D VectorInt24H (DOS 1.1+) 16H W ParentPSPSeg 18H 20 B JFT (DOS 2.0+) 2cH W EnvSeg (DOS 2.0+) 2eH D LastInt21HSS:SP (DOS 2.0+) 32H W JFTEntries (DOS 3.0+) 34H D JFTPtr (DOS 3.0+) 38H D PreviousPSPPtr (DOS 3.0+, SHARE) 3cH B ICS (DOS 4.0+, DCBS) 3dH B TrueNameFlag 3eH 2 B unbenutzt 40H 2 B DOSVersion (DOS 5.0+) 42H 14 B unbenutzt 50H 3 B DOSService (DOS 2.0+) 53H 9 B unbenutzt 5cH 16 B FCB1 6cH 16 B FCB2 7cH 4 B unbenutzt
--- unmittelbar nach Programmstart ---------------------------------------
80H B CmdLineLen 81H 127 B CmdLine
--- sobald die erste Dateioperation erfolgt ------------------------------
80H 128 B DTA
}
OldExitInstruction, Offset 00H, 2 Bytes:
cdH, 20H = Opcodes für INT 20H
Relikt aus CP/M-Zeiten. Wurde früher direkt zur Beendigung des Programmes angesprungen. Seit DOS 2.0+ wird stattdessen ein INT 21.4cH am Programmen- de empfohlen.
Trotzdem ist das Feld auch heute u.U. noch nutzvoll. Einige DOS Extender zermatschen nämlich diverse Felder im PSP, die von Programmierern manchmal zur Identifikation von PSPs herangezogen werden. Die INT 20H Opcodes lie- fern in diesen Fällen ein halbwegs verlässliches Entscheidungskriterium.
Ist die cdH, 20H Signatur vorhanden und stimmt das Word ab Offset 3 im vor dem fraglichen PSP liegenden Paragraphen (mutmaßlicher MCB.Owner) mit der Segmentadresse des fraglichen PSP überein, lässt sich mit relativ hoher Wahrscheinlichkeit sagen, daß es sich tatsächlich um einen PSP handelt. ;)
FollowSeg, Offset 02H, Word:
Segmentadresse des ersten Paragraphen, der unmittelbar auf das dem PSP zu- gehörige Programm folgt.
FarCallInt21H, Offset 05H, 5 Bytes:
9aH, ??H, ??H, ??H, ??H = Opcodes für CALL ????:????H
Noch ein CP/M Relikt. Aus DOS-Sicht kann man diesen FAR CALL als direkten, aber ziemlich eingeschränkten, Weg zum INT 21H Dispatcher betrachten, d.h. über diesen Call lassen sich Funktionen des INT 21H aufrufen (so u.a. die Funktionen 00..24H, wenn man die Funktionsnummer statt in AH in CL über- gibt), ohne einen INT 21H auszulösen.
Der Call ist allerdings nur mit äußerster Vorsicht zu genießen, da man im Prinzip alle Vorsichtsmaßnahmen, die DOS bei einem INT 21H trifft, umgeht.
Man sollte also imo schon über fundierte Kenntnisse verfügen (Handling der drei DOS-Stacks, Arbeitsweise von Software Interrupts, Reentranz-Verhalten von Funktionen des INT 21H, Funktionsweise DOS Idle (INT 28H), InDOS-Flag, usw.), bevor man sich direkt an den Dispatcher wagt... ;)
VectorInt22H, Offset 0aH, DWord:
Kopie des Vektors für INT 22H (Program Termination Address)
VectorInt23H, Offset 0eH, DWord:
Kopie des Vektors für INT 23H (Ctrl-C / Ctrl-Break)
VectorInt24H, Offset 12H, DWord, ab DOS 1.1+:
Kopie des Vektors für INT 24H (Critical Error)
ParentPSPSeg, Offset 16H, Word:
Segmentadresse des elterlichen PSPs.
Um die Sache zu vereinfachen: Unter DOS gilt das Programm, das gerade die Kontrolle besitzt, immer als Eltern-Programm. Einem Eltern-Programm steht es (in gewissen Grenzen) frei, jederzeit ein Kind-Programm zu erzeugen und diesem die Kontrolle zu übergeben. Ist dies geschehen, wird das Kind-Pro- gramm selbst zu einem Eltern-Programm. Dieses neue Eltern-Programm wieder- um kann ebenfalls Kind-Programme erzeugen, und so weiter...
Mit anderen Worten lässt sich also über das ParentPSPSeg indirekt das Pro- gramm ermitteln, welches den zugrundeliegenden PSP erzeugt hat. I.d.R wird dies COMMAND.COM sein, aber auch eigene Programme können bekanntlich als Shell fungieren...
JFT, Offset 18H, 20 Bytes, ab DOS 2.0+:
Job File Table. Tabelle für die ersten 20 FILES eines Prozesses.
= ffH File-Handle noch geschlossen # ffH SFT-Nummer des entsprechenden File Handles (s. Topic STR0005)
HINWEIS: Seit DOS 3.0+ ist man glücklicherweise nicht mehr auf einen 20er JFT festgenagelt, sondern kann Lage und Umfang relativ frei be- stimmen (siehe dazu JFTPtr bzw. JFTEntries weiter unten).
EnvSeg, Offset 2cH, Word, ab DOS 2.0+:
Segmentadresse des DOS Environment Blocks (DEB, siehe Topic STR0006) der zum vorliegenden PSP gehört.
LastInt21HSS:SP, Offset 2eH, DWord, ab DOS 2.0+:
Wert der Register SP und SS zu Beginn des letzten INT 21H.
JFTEntries, Offset 32H, Word, ab DOS 3.0+:
Anzahl Einträge des JFT (Job File Table) an Adresse [JFTPtr]. Bei unverän- dertem JFTPtr (= PSP:0018H) sind dies normalerweise 20 Stück.
JFTPtr, Offset 34H, DWord, ab DOS 3.0+:
16:16 Zeiger, über den sich der JFT (Job File Table) verlagern lässt. Nor- malerweise zeigt JFTPtr auf den Standard-JFT bei PSP:0018H, welcher maxi- mal 20 SFT-Nummern, und damit maximal 20 FILES handlen kann.
Benötigt ein Programmierer mehr als 20 Einträge, kann er sich einfach ir- gendwo x Bytes Speicher für einen größeren JFT reservieren, den Standard- JFT (20 Bytes von PSP:0018H) an den Beginn des neuen JFT kopieren und alle weiteren Bytes als unbenutzt (SFT-Nummer ffH) markieren. Nach Anpassung von JFTPtr (auf die neue JFT-Adresse) und JFTEntries (auf die neue Anzahl FILES) ist der JFT einsatzbereit.
HINWEIS: Aktiviert ein Programm eigene Kind-Prozesse (z.B. INT 21.4b??H), kopiert DOS generell nur die ersten 20 Einträge (von JFTPtr an) in den Standard-JFT im PSP des Kind-Prozesses. Alles weitere ist Sache von Eltern- und/oder Kind-Prozess selbst... ;)
0038H D PreviousPSPPtr (DOS 3.0+, SHARE) 003cH B ICS (DOS 4.0+, DCBS) 003dH B TrueNameFlag 003eH 2 B unbenutzt 0040H 2 B DOSVersion (DOS 5.0+) 0042H 14 B unbenutzt 0050H 3 B DOSService (DOS 2.0+) 0053H 9 B unbenutzt 005cH 16 B FCB1 006cH 16 B FCB2 007cH 4 B unbenutzt
--- unmittelbar nach Programmstart ---------------------------------------
0080H B CmdLineLen 0081H 127 B CmdLine
--- sobald die erste Dateioperation erfolgt ------------------------------
0080H 128 B DTA
mehr in einer zukünftigen FAQ-Release... ;)
FCB-Struktur (File Control Block [DOS])
Juergen Thelen 2:2450/55.5: Topic in Vorbereitung.
DDSSCB-Struktur (DOS Data Segment Subsegment Control Block [DOS])
Juergen Thelen 2:2450/55.5: Topic in Vorbereitung.
SFT-Struktur (System File Table [DOS])
Juergen Thelen 2:2450/55.5: Topic in Vorbereitung.
DEB-Struktur (DOS Environment Block [DOS])
Juergen Thelen 2:2450/55.5: Topic in Vorbereitung.