Auf der Schwelle zum Licht (2): Die Fehlermeldung des TOS (Teil 1)
Das Geheimnis des GEMDOS Teil II
In dieser Folge geht es um die Fehlermeldungen, die die TOS-Systemfunktionen liefern, sowie um die Möglichkeiten des TOS, diese anzuzeigen. Dabei machen wir sogar Abstecher in das BIOS und das AES.
Ich hoffe, daß Sie nach Lektüre dieses Artikels ein wenig mehr mit den Fehlercodes anfangen können, die Ihnen GEMDOS beim Programmieren bisher immer fleißig geliefert hat.
BIOS-Fehlermeldungen
Viele BIOS-Funktionen geben Fehlermeldungen zurück, die Aufschluß über die Art des aufgetretenen Fehlers geben sollen. In den Atari-Doku menta-tionen haben sie symbolische Namen bekommen, die man sich besser merken kann als die nackten Zahlenwerte, weswegen ich diese Bezeichnungen auch in dieser Serie benutzen werde (Tab.l). Man kann sich diese Konstanten z.B. in eine Include-Datei schreiben und zur Fehlerbehandlung in eigenen Programmen verwenden. Atari hat die Werte -1 bis -31 für BIOS-Fehlercodes reserviert.
Da es sich dabei hauptsächlich um Fehler beim Disketten-Zu-griff handelt, machen wir einen kleinen Ausflug in den Disk-Treiber des BIOS. Das Wissen um die Bedeutung und Anwendung der erwähnten BIOS-Funktionen wird vorausgesetzt und findet sich in diversen Büchern. Die Disketten-Funktionen des BIOS gliedern sich in zwei Ebenen. Zur unteren Ebene gehören die Spur-/ Sektor-orientierten Funktionen ’Floprd’, ’Flopwr’, ’Flopfmf und ’Flopver’ des XBIOS. Von diesen Funktionen ist bei der Erklärung der Fehlermeldungen die Rede, wenn von Lesen, Schreiben, Formatieren und Verifizieren gesprochen wird.
Auf der oberen Ebene befinden sich die BIOS-Funktionen ’R-wabs’, ’Mediach’ und ’Getbpb’, die nicht nur für Diskettenlaufwerke vorgesehen sind, sondern auch für Harddisks und RAM-Disks zuständig sind. Bei ’Getbpb’ ist zu beachten, daß alle auftretenden Fehler nur durch OL gemeldet werden, also keine weitere Differenzierung der Fehlerursache mehr erfolgt.
Fehler können nun auf beiden Ebenen auftreten, wobei i.a. jede Ebene ihre eigenen Fehlermeldungen hat. Einige Fehlercodes der unteren Ebene resultieren direkt aus den Fehlermeldungen des FDC (Floppy Disk Controller), deren Erläuterung sich im ”Floppy-Kurs” (ST-Computer 11/87) findet.
In einigen Fällen wurde die eindeutige Benutzung der Fehlercodes nicht ganz durchgehalten, d.h., gleiche Fehler erzeugen unterschiedliche Meldungen.
ERROR
Zum einen zeigt diese Meldung einen DMA-Fehler beim Lesen oder Formatieren (nicht beim Verifizieren) an. Achtung: Beim Schreiben wird ein DMA-Fehler überhaupt nicht erkannt!
Außerdem gibt er einen Timeout beim Schreiben oder Formatieren (nicht beim Lesen oder Verifizieren) an, d.h. wenn ein Kommando des Floppy Disk Controllers (FDC) nicht innerhalb einer gewissen Zeitspanne ausgeführt werden konnte.
EDRVNR
Hiermit wird ein Timeout beim Lesen angezeigt. Bei einem ’Rwabs’ ohne angeschlossene Floppy tritt dieser Fehler ebenfalls auf. Aber ganz ohne Floppy arbeitet es sich ja sowieso recht schlecht.
E-CRC
Hierdurch wird auf einen Prüf-summen-Fehler aufmerksam gemacht, was auf einen Lesefehler hindeutet. Die Meldung korrespondiert mit dem CRC-Bit des FDC-Statusregisters.
Dies gilt jedoch nur für das Blit-ter-TOS. Beim alten TOS wird der CRC-Fehler zwar korrekt erkannt, aber stattdessen eine andere Fehlermeldung zurückgegeben (EREADF bzw. EWRITF bei Lese/Verifizier bzw. Schreib/Formatier-Operationen).
E-SEEK
Wenn das BIOS eine Spur auch nach mehreren Versuchen nicht ansteuern kann, bricht es die Disketten-Operation hiermit ab. Vermutlich ist die Diskette auf dieser Spur nicht formatiert oder defekt.
ESECNF
Wenn der FDC einen gesuchten Sektor auf der Diskette nicht finden kann, wird diese Meldung erzeugt. Der Fehler entspricht dem Record-Not-Found-Bit des FDC-Statusregisters. Entweder ist die Diskette nicht ausreichend formatiert, oder sie ist beschädigt.
EPAPER
Das soll anzeigen, daß der Drucker nicht betriebsbereit ist, weil kein Papier eingelegt ist. Da der Atari hardwaremäßig das entsprechende Signal auf dem Centronics-Port gar nicht abfragen kann, ist diese Fehlermeldung wohl - wenn überhaupt - eher zukünftigen STs Vorbehalten.
EWRITF
Dieser "allgemeine Schreibfehler" tritt beim Schreiben oder Formatieren auf, wenn der FDC einen "Lost Data-Fehler” meldet. Auch dies funktioniert so nur beim Blitter-TOS; beim alten TOS wird stattdessen ein E-CRC gemeldet.
EREADF
Der "allgemeine Lesefehler” entspricht EWRITF beim Lesen oder Verifizieren (auch Vertauschung mit E-CRC beim alten TOS).
Beim alten TOS wird ein "Lost Data” beim Lesen jedoch (nicht beim Verifizieren) ignoriert, was einem Kopierschutz, der darauf baut, beim neuen TOS Schwierigkeiten macht.
Desweiteren bekommt man diesen Fehler auch bei einem DMA Fehler oder Timeout beim Verifizieren.
WPRPRO
Hiermit wird auf einen versuchten Schreibzugriff bei aktiviertem Schreibschutz aufmerksam gemacht.
E-CHNG
’Rwabs’ zeigt mit dieser Meldung an, das ein definitiver Wechsel des Speichermediums (z.B. Disketten) stattgefunden hat.
Die untere Ebene der Disket-ten-Funktionen kümmert sich nicht um Disketten-Wechsel, da die Routinen zur Diskettenwechsel-Erkennung und -Behandlung zur oberen Ebene gehören.
EUNDEV
Das angesprochene Laufwerk ist unbekannt. Dieser Fehler tritt nur bei ’Rwabs’ und ’Me-diach’ auf, bei ’Getbpb’ wird hierbei OL zurückgegeben. Ein Laufwerk ist unbekannt, wenn sich kein Treiber dafür in diese Disk-Routinen eingehängt hat. Die Floppy-Laufwerke A: und B: sind immer bekannt (s. auch EDRVNR). Der Zustand der Systemvariablen ’drvbits’ hat hiermit nichts zu tun.
EBADSF
Die bisher beschriebenen Fehlermeldungen beim Verifizieren erhält man nur, wenn man das Verifizieren direkt über die XBIOS-Funktion aufruft. Die Verifizier-Routine wird jedoch auch von ’Rwabs’ und der For matier-Funktion ’Flopfmf benutzt. Dabei wird bei einem Fehler jedoch einfach ein pauschales EBADSF zurückgegeben.
EOTHER
Hierbei handelt es sich nicht um eine Fehlermeldung, sondern um eine Anfrage. Das BIOS arbeitet bei nur einem Disketten-Laufwerk ja bekanntlich mit zwei logischen Laufwerken A: und B:. Wird das jeweils andere logische Laufwerk angesprochen, fordert das BIOS hiermit zum Diskettenwechsel auf. Normalerweise wird dies vom Critical Error Händler behandelt, so daß diese Fehlermeldung nicht an den Aufrufer der BIOS-Funk-tion zurückgegeben wird.
In Tab.1 findet der aufmerksame Leser noch die Fehlercodes EUNCMD, EBADRQ und EMEDIA; außerdem fehlt die -12. Diese Meldungen werden - soweit mir bekannt - vom BIOS aber garnicht verwendet.
GEMDOS-Fehlermeldungen
Die meisten GEMDOS-Funktionen geben einen Wert zurück, der anzeigt, ob sie ordnungsgemäß ausgeführt werden konnten, oder ob ein Fehler auftrat, ähnlich wie beim BIOS. Für die Fehlermeldungen des GEMDOS sind dabei 32-Bit Integers im Bereich von-32 bis-127 vorgesehen (einige Funktionen liefern nur 16-Bit-Werte zurück!). Funktionen, die Datei-Zugriffe machen, können außerdem die nun schon bekannten BIOS-Fehlermeldun-gen zurückgeben. Eine Auflistung mit den symbolischen Bezeichnungen und einer ”Kurzbeschreibung” findet sich in Tab.2. In einigen Dokumentationen ist ENMFIL fälschlicherweise als -47 angegeben.
Eigentlich sollte jeder Fehlermeldung eine bestimmte, eindeutige Bedeutung zukommen. Was für das BIOS noch einigermaßen zutrifft, gilt für GEMDOS jedoch noch lange nicht. Man darf auf Grund dieser Tabelle nämlich nicht davon ausgehen, daß nun das Thema "GEMDOS-Fehler” schon erledigt ist. Die Programmierer des GEMDOS haben die Fehlercodes nämlich manchmal recht wahllos verwendet.
Oft wird eine Fehlerursache, die bei mehreren Funktionen auftreten kann, dem aufrufenden Programm durch unterschiedliche Fehlercodes mitgeteilt, in einigen Fällen kann sogar ein Fehler bei ein und derselben Funktion zu verschiedenen Fehlermeldungen führen.
Ein gutes Beispiel hierfür ist der Mangel an freiem "internen Speicher” (s. Speicherverwaltung), der bei vielen Funktionen auftreten kann, aber nur in den seltensten Fällen zur Fehlermeldung ENSMEM führt, sondern meistens in einem ERROR, EPTHNF, EFILNF, ENMFIL, EDRIVE oder sogar in Bömbchen resultiert.
Andererseits kann ein Fehlercode die unterschiedlichsten Ursachen haben. Ein gutes Beispiel hierfür ist EACCDN, das anscheinend für fast alles herhalten muß, was nicht durch andere Fehlermeldungen abgedeckt ist.
Dies erschwert natürlich die einheitliche Behandlung von GEMDOS-Fehlern durch eine globale Fehlerbehandlungs-Routine, da die Bedeutung der Fehler von der aufgerufenen Funktion abhängt. Dies steht im Gegensatz zur offiziellen GEMDOS-Dokumentation, wo der Eindruck erweckt wird, als ob die meisten allgemeinen Fehler gleich behandelt werden könnten.
Das soeben beschriebene Fehler-Chaos kommt übrigens dadurch zustande, daß die von den GEMDOS-Routinen der unteren Ebenen gelieferten Fehlercodes von den übergeordneten Funktionen "verfälscht” weitergegeben werden.
Desweiteren werden einige Fehler überhaupt nicht bemerkt oder nur sehr unvollständig abgefangen.
Der Zusammenhang zwischen den Fehlern und den zurückgegebenen Fehlermeldungen ist in Tab. 3 dargestellt. Damit die Tabelle nicht zu unübersichtlich wird, fehlen die GEMDOS-Funktionen für zeichenorientierte Ein-/Ausgabe (C...) sowie Uhrzeit/Datum (T...), da sie gar keine bzw. die dokumentierten Fehlercodes zurückgeben.
Bei ’Frename’ bezieht sich die Zeile ’Q’ auf den Pfad der umzubenennenden Datei, ’Z’ auf den neuen Pfad. Die Funktionen ’Fsetdta’ und ’Fdatime’ liefern keinen definierten Wert zurück (’void'-Funktionen).
Erschrecken Sie bei dieser Tabelle nicht zu sehr, in der Praxis sieht die Sache einfacher aus, da einige Fehler normalerweise nicht auftreten. Trotzdem sollte für sie irgendeine Fehlerbehandlung vorgesehen sein, damit Ihr Programm wenigstens nicht abstürzt.
Für Vollständigkeit kann bei dieser Aufstellung nicht garantiert werden, da man leicht irgendeine Wechselwirkung übersieht. Vielleicht ergeben sich noch im Laufe dieser Serie Änderungen; auch würden mich hier Ihre Erfahrungen interessieren.
In den Spalten sind die bei den intern tatsächlich auftretenden Fehlern gelieferten Fehlercodes eingetragen. Fehlercodes, die wirklich nur unter ganz eindeutigen Umständen eintreten können, sind in der letzten Spalte gesondert aufgeführt.
Außer den symbolischen Bezeichnungen finden sich in der Tabelle manchmal folgende Einträge:
"Bomben”
Ein Fehler kann zwar auftreten, wird aber von GEMDOS nicht erkannt. Da GEMDOS mit falschen Werten weiterarbeitet (mit Vorliebe Null-Zeiger), gibt es sofort Bomben. Immerhin weiß man dann, daß etwas schiefgegangen ist.
Dies heißt jedoch keineswegs, daß hiermit alle Fälle abgedeckt sind, bei denen es bombt, da in der Tabelle nur die unmittelbar auftretenden Fehler aufgeführt sind. Durch geschickte Kombinationen von GEMDOS-Aufrufen und Fehlern im GEMDOS lassen sich ebenfalls Bomben erzeugen.
”unbem.”
Ähnlich wie "Bomben”, nur daß das Nicht-Bemerken des Fehlers nicht unmittelbar zu unangenehmen Konsequenzen fuhrt. Meistens passiert nicht viel, aber man sollte sich nicht über Spätfolgen in Form merkwürdiger Nebeneffekte wundern.
”k. Fehler”
Der Fehler wird zwar bemerkt und richtig behandelt, aber es erfolgt keine Fehlermeldung über die üblichen Fehlercodes. Der Fehler kann vom Anwenderprogramm höchstens indirekt erkannt werden.
”0L”
‘Malloc’ liefert im Gegensatz zu den anderen Funktionen Null als Fehler, dies entspricht aber der Dokumentation.
Doch nun zur Beschreibung der Fehlerursachen (Spalten der Tab.3 von links nach rechts):
”Kein freier Benutzer-Speicher mehr”
Der größte, zusammenhän gende freie Speicherbereich reicht nicht mehr für das gewünschte ’Malloc’ oder für das Laden bzw. Starten eines Tochterprozesses aus.
”Kein freier interner Speicher mehr”
Der von GEMDOS für die Verwaltung von Laufwerken, Di rectories und Dateien benötigte interne Speicher reicht nicht mehr aus. Dieser Fehler wird zwar fast überall abgefangen, aber da er zu den unterschiedlichsten Fehlermeldungen führt, und der Desktop ihn nicht erkennt bzw. erkennen kann, sollte man dafür sorgen, stets ausreichend internen Speicher zur Verfügung zu haben (vor allem wichtig bei Harddisk-Besitzern). Genauere Erläuterungen zum internen Speicher s. "Speicherverwaltung”.
"Laufwerk unbekannt”
Das angesprochene Laufwerk ist GEMDOS unbekannt und nicht vorhanden. Ein Laufwerk ist bekannt, sobald es zum ersten Mal angesprochen wurde und vorhanden war. Es bleibt bekannt, auch wenn es vielleicht später nicht mehr vorhanden sein sollte. In diesem Fall wird dies nicht vor Ausführung der GEMDOS-Funktion erkannt, sondern bestenfalls beim eigentlichen Zugriff über das BIOS.
GEMDOS geht halt davon aus, daß Laufwerke im System bleiben, wenn sie erst einmal installiert sind, was normalerweise ja auch zutrifft. Diese Zusammenhänge werden noch in der späteren Folge ”Disk-Verwaltung" erklärt.
"Illegaler Funktions-Modus”
Der der GEMDOS-Funktion übergebene Modus-Parameter (abhängig von der Funktion) liegt nicht im vorgesehenen Werte-Bereich (z.B. darf ’mo-de’bei’Fseek' nur die Werte 0,1 oder 2 haben). Dies wird bei vielen Funktionen nicht bemerkt, hat aber (meistens) keine schlimmen Nachwirkungen.
"Kein Standard-Handle”
Die GEMDOS-Funktion erwartet ein Standard-Handle (0...5). Es werden hier tatsächlich alle illegalen Handles abgefangen.
’Illegales Datei-Handle”
Das übergebene Handle ist kein Datei-Handle (6... 74) bzw. das Device- oder Standard-Handle eines auf eine Datei umgeleiteten Devices.
Achtung: Es wird nur überprüft, ob zu dem Datei-Handle eine geöffnete Datei existiert. Wenn das Handle nicht in dem für Handles allgemein zulässigen Wertebereich von -3 bis + 74 liegt, können vollkommen unvorhersehbare Effekte auf-treten, da GEMDOS auf falsche Speicherbereiche zugreift (Ar-ray-Index-Überlauf)!
Daher ist es besonders wichtig, eine Fehlerbehandlung bei ’Fo-pen’/’Fcreate’ durchzuführen, da ansonsten der Fehlercode (i.a. kleiner als -32!) als Datei-Flandle weiterverwendet wird.
"Keine Datei-Handles mehr”
Es ist kein Datei-Handle mehr frei. Bei 69 möglichen Datei-Handies sollte dies eigentlich nie der Fall sein, doch gibt es Situationen, bei denen GEM-DOS fehlerhafterweise Datei-Handies verbraucht, so daß man nicht sicher kann, daß GEMDOS nicht doch irgendwann einmal - auf Grund eines noch nicht entdeckten Fehlers vielleicht - alle Handles aufbraucht.
"Keine Pfad-Handles mehr”
Es sind keine Pfad-Handles mehr frei. GEMDOS braucht zur Verwaltung der Standard-Pfade von Laufwerken interne Datenstrukturen, die über (nur intern bekannte) Handles angesprochen werden. Näheres hierzu später in der Folge über "Directory-Verwaltung”. Die Maximalzahl von 39 Pfaden wird in der Praxis wohl kaum erreicht werden, so daß dieser Fehler nicht zu befürchten ist.
"Datei nicht gefunden”
Ein der GEMDOS-Funktion übergebener Dateiname wurde im angesprochenen Directory nicht gefunden.
"Pfad nicht gefunden”
Ein Pfad für eine Datei wurde nicht gefunden.
”'.' oder '..' als Dateiname”
Der Pseudo-Directory-Name oder wurde als Dateiname verwendet, wo es nicht zulässig ist.
”Nur-Lese-Datei”
Es wurde ein Schreibzugriff auf eine Datei versucht, die mit dem Nur-Lesen-Attribut versehen ist. Dazu zählt auch das versuchte Löschen der Datei, nicht jedoch das Ändern von Directoryinformationen (Name, Attribut, Datum/Zeit).
’Pexec’ sollte selbstverständlich immer funktionieren, aber beim Aufruf von ’Fopen’ innerhalb der ’Pexec’-Funktion wurde die Übergabe des Modus-Wortes vergessen. Befindet sich auf dem Stack zufällig ein Modus-Wort ungleich Null, so daß versucht wird, die Datei (auch) zum Schreiben zu öffnen, klappt dies natürlich nicht bei gesetztem ’Nur-Lesen’-Attribut. Beim Start vom Desktop aus trifft dies anscheinend nicht zu, aber bei Shell-Programmen kann man sich da ja nicht sicher sein. Außerdem werden nicht zulässige Modi beim ’Fopen’ auch nicht abgefangen, allerdings ohne Schaden anzurichten. Mit anderen Worten: Daß Ihr ST überhaupt Programme lädt, ist purer Zufall
"Datei/Speicher gehört (auch) noch zu anderem Prozeß”
Ein unzulässiger Zugriff auf eine Datei, die von mehr als einem Prozeß geöffnet wurde, wurde versucht. Zur Multi-Tas-king-Fähigkeit der Dateiverwaltung s. Folge "Dateiverwaltung”. Doch schon vorweg: Hier funktioniert so manches nicht, daher ist diese Fehlermeldung mit Vorsicht zu genießen.
Achtung: Es ist ohne weiteres möglich, mit Datei-Handles fremder Prozesse auf deren Dateien zuzugreifen.
"Diskette voll”
Dies wird günstigstenfalls bei Directory-Operationen gemeldet. Beim Datei-Zugriff (’Fwrite’) muß anhand der zurückgelieferten Anzahl der tatsächlich geschriebenen Zeichen selbst festgestellt werden, ob die Datei korrekt beschrieben wurde.
”Root-Directory voll”
Das Root-Directory (Haupt-Directory, oberste Ebene) ist voll. Beim Standard-Disketten-Format sind 112 Einträge möglich, so daß es hier keine Probleme geben sollte. Die Größe von Subdirectories (Ordnern) ist nur durch die Disketten-Kapazität begrenzt.
"Illegaler Subdirectory-Zugriff"
Es wurde versucht, ein nichtleeres Subdirectory zu löschen (’Ddelete’), eine mit einem Subdirectory namensgleiche Datei zu erzeugen (’Fcreate’), ein schon vorhandenes Subdirectory erneut zu erzeugen (’Dcreate’) oder ein Subdirectory mit nur für Dateien vorgesehenen Funktionen zu bearbeiten.
"Interner Fehler”
Dieser Fehler erfolgt, wenn GEMDOS-eigene Datenstrukturen in sich widersprüchlich sind. Dieser Fehler kann also nur auftreten, wenn zuvor schon Fehler im GEMDOS ihr Unwesen getrieben haben.
Solche Abfragen auf interne Fehler werden leider nur bei ’Fclose’ und ’Ddelete’ gemacht, obwohl sie sicherlich auch an anderen Stellen wünschenswert wären, um Schlimmeres zu verhindern. Denn GEMDOS ist - wie auch das GEM - sehr empfindlich gegenüber falschen Parametern usw., da kaum Kontrollen gemacht werden. Kleinste Programmfehler in Anwenderprogrammen können so GEMDOS ziemlich verwirren. Hinzu kommen noch die Fehler im GEMDOS selbst, die manchmal sehr versteckt sind, aber ganz unerwartet in Erscheinung treten.
”BIOS-Fehler”
In dieser Spalte sind alle GEM-DOS-Funktionen markiert, bei denen Disk-Zugriffe auftreten können. Dabei verwendet GEMDOS ausschließlich die BIOS-Routinen ’Rwabs’, ’Mediach’ und ’Getbpb'. Von den so gekennzeichneten Funktionen können also neben den GEMDOS-Fehlermeldungen auch BIOS-Fehlermeldungen zurückgegeben werden.
Zur Diskettenfehler-Behandlung habe ich ja schon in der letzten Folge einiges gesagt, aber eines bleibt noch nachzutragen. Da die GEMDOS-Funktion dann einfach abgebrochen wird, kann es sein, daß interne Datenstrukturen sich noch in einem Undefinierten Zustand befinden, weil Disk-Zugriffe manchmal während cer Manipulation dieser stattfinden. Normalerweise wirkt sich dies - wie die Erfahrung zeigt - nicht negativ aus, aber die Folgen daraus sind schwer abzusehen, so daß ich nur dazu raten kann, fehlerfreie Disketten zu verwenden. Noch gefährlicher ist der Diskettenwechsel während einer Disk-Operation, da dann das GEMDOS-Kommando einfach wiederholt wird, was noch undurchschaubarere Folgen hat.
Zum Schluß kommen wir zu den Fehlermeldungen, die nur bei ganz bestimmten GEMDOS-Funktionen auftreten können und eine eindeutige Bedeutung haben.
ENSAME
Die Funktion ’Frename’ kann Dateien nur innerhalb eines Laufwerks umbenennen. Bei einem anderen Laufwerk mit anderer Kennung müßte die Datei ja kopiert werden. Da GEMDOS über keine Kopierfunktion verfügt, wird mit dieser Fehlermeldung abgebrochen.
ERANGE
Mit ’Fseek’ wurde versucht, den Datei-Positions-Zeiger auf einen illegalen Wert zu setzen. Negative Werte und Werte größer als die Datei-Länge sind nicht zugelassen. Dies gilt auch bei einer zum Schreiben geöffneten Datei, bei der der Zeiger nur max. auf das Dateiende gesetzt werden darf.
EIMBA
Die an ’Mfree’ und ’Mshrink’ übergebene Adresse ist nicht die eines mit ’Malloc’ reservierten Speicherbereichs. Es wird nicht kontrolliert, ob der Speicherbereich überhaupt von dem eigenen Prozeß reserviert wurde, d.h. man kann auch fremde Bereiche freigeben bzw. verkleinern (sehr gefährlich!).
EGSBF
Es wurde versucht, mit ’Mshrink’ einen Speicherbereich zu vergrößern. Die Speicherverwaltung des GEMDOS ist dazu jedoch nicht in der Lage, die neue Länge des Bereichs muß kleiner gleich der alten sein.
EPLFMT
’Pexec’ hat versucht, eine Datei zu laden, deren Format nicht dem einer Programm-Datei entspricht. Das Format wird als illegal betrachtet, wenn das erste Wort des Programm-Headers nicht $601A ist, oder wenn die Relozier-Offsets aus dem zulässigen Bereich (TEXT-und DATA-Segment) herausführen.
In der nächsten Ausgabe werden wir uns dann dem Critical-Error-Handler und der Form-error-Routine widmen.
Alex Esser