Es gibt Programme, die das TOS-Datum oder die TOS-Versionsnummer abfragen. Da möchte der Programmierer z.B. Funktionen nutzen, die erst von neueren Versionen des Betriebssystems zur Verfügung gestellt werden. Soll das Programm auch auf älteren, vielleicht noch weit verbreiteten OS-Versionen lauffähig sein, muß entsprechend verzweigt werden, um die nicht vorhandenen Features zu umgehen oder vielleicht sogar nachzubilden.

Jedenfalls sollte das Programm nicht etwa nur böse bombend abstürzen: Guter Stil erfordert zumindest eine Meldung der Art Prg. XYZ läuft erst ab OS-Version ABC!. Diese Art der TOS-Versionsabfrage ist völlig korrekt und entspricht guter Programmierpraxis.

Es gibt aber noch eine ganz andere Art der Versionsabfrage: Da hat ein pfiffiger Programmierer eine OS-interne Variable entdeckt, über die sich Manipulationen vornehmen lassen, die seinem Programm ungeahnte Möglichkeiten eröffnen. Der einzige Nachteil ist, daß sich die Lage dieser Variablen von OS-Version zu OS-Version verändert. Was tun? Der 'brave’ Programmierer stöhnt: „schade!“ und läßt die Finger davon. Vielleicht beginnt er auch eine Korrespondenz mit den Systemprogrammierern seines Rechners und versucht, sie davon zu überzeugen, wie gut es wäre, die bewußte Variable zu dokumentieren und damit zur Benutzung freizugeben.

Doch magisch lockt die Macht des Bösen, und das Fleisch ist schwach. So wird denn schließlich eine Tabelle installiert, in der die Lage der besagten Variablen für alle relevanten, bis dato bekannten OS-Versionen festgelegt ist. Die Höflichkeitsmeldung - sofern implementiert müßte hier lauten: Prg. XYZ läuft nur auf OS-Version(en) ABC! Bitte Update ordern! [1]

Nach dieser Einführung hoffentlich neugierig gemacht und entsprechend motiviert, lassen Sie uns zur Lösung eines bekannten praktischen Problems nun gemeinsam in die (Un-)Tiefen des TOS, seiner Dokumentation und speziell seiner internen Speicherverwaltung durch das GEMDOS hinabsteigen.

Ziel aller Wünsche

Eine der am heißesten begehrten internen TOS-Variablen ist der sogenannte MPB (Memory Parameter Block): Er stellt nämlich den Schlüssel für die Speicherverwaltung des Betriebssystems (hier GEMDOS) dar und besteht aus drei Zeigern, angeordnet in folgender Struktur:

Der roving ptr, ein intern verwendeter Zeiger auf den zuletzt bearbeiteten (oder den demnächst zu bearbeitenden?) Block, ist allerdings in seiner Funktion nicht weiter offiziell beschrieben. Bei meiner Konfiguration (TOS 1.4) zeigt er immer auf die mfl; wenn es keine mfl gibt (mp_mfl = 0), ist er auch Null. Man sollte sich allerdings hüten, aus solchen Beobachtungen irgendwelche Annahmen für die Zukunft abzuleiten, und siehe da, im TT-TOS 3.01 wird er anscheinend schon nicht mehr benutzt...

In den beiden Listen, der mfl und der mal, befinden sich die sog. MDs (Memory Descriptor), sie haben folgende Struktur:

Beide Listen bestehen also aus diesen MDs, die mittels der m_link-Zeiger einfach miteinander verkettet sind, jeder allozierte (mit bestimmten Ausnahmen, s.u.) und jeder freie Block des Anwenderspeichers ist hier eingetragen. Der m_own-Zeiger ist allerdings bei den in der mfl befindlichen MDs bedeutungslos, wenn nicht schon Null. Diese Strukturen sind - äußerst sparsam - offiziell dokumentiert in [2], eine ausführliche Diskussion (inoffiziell) gibt ’s in den grundlegenden Beiträgen von Alex Esser [3]. Dabei sollte man aber bedenken, daß sich die nicht offiziell dokumentierten internen Strukturen des Betriebssystems des öfteren geändert haben und auch weiterhin ändern werden, ja, daß sie gerade deshalb nicht dokumentiert werden, um die Möglichkeit ihrer Änderung - Optimierung oder Erweiterung - offenzuhalten.

Wenn man also über die Kenntnis des leider nur strukturmäßig wohldokumentierten Ankers, eben des MPB, Zugriff auf diese ebenfalls in ihrer Existenz und Struktur dokumentierten einfach verketteten Listen hätte, könnte man die Speicherverwaltung des GEMDOS allerliebst manipulieren. Dazu eröffnen sich folgende Perspektiven:

Ein süßer Traum...

Atari dokumentiert endlich die Adresse des MPB als Systemvariable und gibt damit den Zugriff auf die schon längst publizierten MDs frei. Dafür sollte man Allan Pratt und seinem Team von Systemprogrammierem den ‘Goldenen Jack am Band’ verleihen! Gewisse ‘trickreiche’ Programme könnten dann mit Tabellen für Abfragen erster Art versehen werden und endlich in den Bereich der so lang ersehnten programmiertechnischen Legalität überwechseln.

...und die harte Wirklichkeit

Es gibt da die allgemein bekannte, dokumentierte [2] und vom Anwender tunlichst nicht aufzurufendc BIOS-Funktion Nr.0 getmpb, die vom GEMDOS während des Systemstarts dazu benutzt wird, den MPB auszufüllen und dabei gleichzeitig einen MD, nämlich den MD, das ist die Systemvariable themd $48E, zu initialisieren [2, 4].

Da wir wissen, daß das GEMDOS nur einmal die Funktion BIOS (0) getmpb aufruft, müssen wir uns zu einem Zeitpunkt in der Systeminitialisierung, zu dem der BIOS-Trap schon eingerichtet ist, aber vor der Initialisierung des GEMDOS, in den Trap hängen und warten, bis getmpb aufgerufen wird. Dabei wird p_mpb als Zeiger auf den MPB auf dem Stack übergeben, wir brauchen ihn uns nur zu merken und können ihn in einer dokumentierten und deshalb für andere Programme zugänglichen Form ablegen, z.B. als cookie im cookie jar, um gleich einmal diese mit TOS 1.6 eingeführte, aber auch bei früheren TOS-Versionen nachrüstbare Informationsstruktur zu nützen.

Leider stellt sich bei Untersuchung der im schon zitierten HHG [2] sehr ausführlich dokumentierten Startup-Sequenz heraus, das nur eine ROM-Port-Cartridge dort hineinkommen kann, und zwar in unserem Falle am besten eine Anwendung vom Typ L direkt vor der Initialisierung des GEMDOS. Nun haben aber Cartridges, auch ROM-Module genannt, einen Nachteil: Sie sind ziemlich hart und lassen sich weder auf Diskette ziehen noch über ein elektronisches Medium schicken, was ihrer Verbreitung natürlich im Wege steht - zumal dies ja eine der wenigen echten ROM-Modul-Anwendungen wäre. Na, zumindest den Code kann man ja veröffentlichen. Leider ist diese harte Tour bis dato der einzige Weg, dem MPB auf völlig legale - und damit 100%ig und für alle Zeiten (...solange das TOS noch von Belang ist und Atari sich an seine eigene Dokumentation hält...) sichere - Weise beizukommen.

Weichere Möglichkeiten

Der Anker der MD-Listen ist also der MPB. Nur, was macht man, wenn man seine Adresse nicht kennt? Das einzige, worauf man seine Hand legen kann, ist themd ($48E), eine ‘garantierte’ Systemvariable zwar, aber leider nicht sehr von Nutzen. Das war und ist der bisherige Stand der (recht kärglichen) Dokumentationen und die generelle Meinung der Fachautoren. Das soll sich nun ändern, denn genau hier setze ich den Hebel an!

themd ist gleich nach der GEMDOS-Initialisierung ein (der einzige) Eintrag der mfl und weist damit den gesamten Anwenderspeicher - auch TPA (Transient Program Area; genannt - von membot bis memtop als frei aus, so ist’s dokumentiert in [2]. Die mal ist zu diesem Zeitpunkt leer (mp_mal=0), mp_mfl (und bis TOS 1.6 auch mp_rover) zeigt auf themd. Dies ändert sich, sobald die erste Speicherreservierung (z.B. zum Starten eines Prozesses) vorgenommen wird. Nun ist themd der letzte MD der mal: m link=0, m_own = Urprozeß (seit TOS 1.4, früher Null), m_start = membot, m_length enthält die Größe des ersten reservierten Blocks. Die Möglichkeit zu einer solchen ‘öffentlichen’ Reservierung - mit Malloc() - besteht bei ausführbaren Boot-Sektoren (Floppy- und DMA-Boot) und Päckchen, in dieser Reihenfolge. Danach ist dann wieder das ROM dran, und hier geschehen auf jeden Fall die ersten Reservierungen für Environment-String und Basepage, die für den sog. AUTOEXEC-Prozeß eingerichtet werden (nicht dokumentiert), der dann, falls vorhanden, die AUTO-Ordner-Programme und anschließend das AES (oder das COMMAND.PRG) startet (das ist wieder dokumentiert!).

Fallunterscheidung

1. Wir haben in themd eine Struktur, auf die zu einem Zeitpunkt, zu dem noch kein Speicher reserviert wurde (Boot-Sektorprogramme und Päckchen), ein oder zwei Zeiger (mp_mfl und mp_rover) zeigen. Die müßten sich doch finden lassen, und damit wäre dann der ach so heißbegehrte MPB lokalisiert [5].

Äußerst kritisch ist hier, daß noch kein Speicher reserviert worden sein darf, im Falle des Päckchens könnte z.B. ein Harddisk-Treiber aus dem Boot-Sektor von Laufwerk C: dazwischen gekommen sein, so daß eine gewisse Sicherheit für diese Methode nur dann besteht, wenn das Programm aus dem Boot-Sektor von Laufwerk A: startet und damit garantiert als allererstes ausgeführt wird. Die Unberührtheit des Speichers läßt sich recht einfach nachprüfen. Um dem Problem mit der Benutzung des mp_rover aus dem Wege zu gehen, empfiehlt sich hier die Suche von unten nach oben. Die verbleibende Unsicherheit resultiert aus der nicht ganz dokumentenechten Annahme, daß es im durchsuchten Bereich nur einen solchen Zeiger gibt, und daß das dann der gesuchte mp_mfl ist (ich wüßte allerdings nicht, was das GEMDOS mit mehr als einem solchen Zeiger auf die mfl anfangen sollte!).

2. Wir haben in themd das letzte Glied einer Kette, auf deren Beginn mp_mal zeigt. Dies ist zu allen späteren Zeiten so, gleich, ob aus dem AUTO-Ordner oder vom Desktop aus. Dieser Fall ist etwas kniffliger: Zeiger suchen, der auf themd zeigt; prüfen, ob’s ein m_link eines MD sein könnte; prüfen, ob m_own Null ist; wenn ja, ist es vermutlich der mp mal; sonst: Zeiger suchen, der auf diesen MD zeigt...

Hier gibt es zwei kritische Punkte, den einen allerdings erst seit TOS 1.4. Die von residenten Programmen belegten MDs werden nämlich wie schon zuvor üblich aus der mal ausgehängt und sind damit dem GEMDOS unbekannt. [6] Leider werden die von ihnen belegten ‘Slots’ aber nicht freigegeben, d.h. der Inhalt gelöscht oder zumindest ihr m_own ungültig gemacht. Bei z.B. 10 residenten AUTO-Ordner-Programmen sind dann 20 MD-Slots völlig unnötigerweise belegt (je 10 für die Environment-Strings, 10 für die residenten Programmteile inklusive Basepage), ein weiterer Bug im neuen GEMDOS-Poolmanager (POOLFIX3 hilft da leider auch nicht weiter)! Unser Suchprogramm könnte somit auf die Adressen zwar formal gültiger, aber für uns wertloser MDs stoßen, die als ‘Leichen’ im GEMDOS-Pool liegen. Ein Test auf die Gültigkeit von m_own (muß auf gültige Basepage zeigen [7]) nützt in diesem Falle auch nichts. Der Referenzierungsalgorithmus, der die verkettete Liste von hinten aufrollen soll, muß also durch einen entsprechenden Dereferenzierungsalgorithmus ergänzt werden, damit sich die Routine sozusagen wieder rückwärts aus der Sackgasse - Stufe für Stufe - heraushangeln kann, um dann jeweils neue Versuche nach vom zu starten. Damit das Programm bei etwaigem Versagen nicht hängenbleibt, sollte die maximal mögliche Anzahl der ‘Backtracking’-Versuche auf einen vernünftigen Wert begrenzt werden. Das alles hört sich zwar furchtbar kompliziert an, der Code ist jedoch recht kurz und klar!

Der zweite kritische Punkt ist die Abbruchbedingung, nämlich m_own=0. So etwas darf es allerdings in der mal nicht geben: einen herrenlosen Block. Dann hätten wir also hoffentlich den mp mal selbst erwischt. Das wäre dann aber kein Element eines MD mehr, und die Tatsache, daß an diesem Offset eine Null steht, haben wir nur dem glücklichen Umstand zu verdanken, daß der MPB (zumindest zur Zeit des AUTO-Ordners und meist auch des Desktops) allein auf weiter Flur in einem sonst leeren Datenbereich steht. Dies ist natürlich logisch überhaupt nicht zwingend. Und das muß auch nicht so bleiben, selbst wenn es schon seit Uralt-Rauchpilz-TOS-Zeiten so war und auch im STE-TOS 1.6 sowie im TT-TOS 3.01 noch immer so ist. Die Methode funktioniert prächtig, wie der geneigte Leser sicher schon erraten hat, und wird es wohl auch weiterhin, doch kann man dies weder 100%ig noch für alle Zeiten garantieren.

Lösungsvorschlag

Die erste Methode bietet mehr Sicherheit, eignet sich aber nicht für Programme, die, wie das nun vorgestellte MAL_FIND oder GET_MPB, lediglich eine darstellende Funktion haben. Um nicht umständlich mit Boot-Sektor-Installationen herumbasteln zu müssen, könnte man auch ein Päckchen installieren (ein Bonus für Programme, die sowieso auf einem resetfesten Päckchen laufen sollen!), evtl. gleich einen Warmstart veranstalten und aus dem Päckchen heraus den MPB ermitteln. Da man hier immer damit rechnen muß, daß ein selbstbootender Harddisk-Treiber von Laufwerk C: dazwischenfunkt, empfiehlt sich eine Kombination der beiden Methoden, wie es in dem als Link-Modul ausgelegten _GET_MPB implementiert wurde.

Gesucht wird jeweils von membot nach unten bis $2000 (willkürlich, auch bei Uralt- TOS-Versionen findet sich nichts darunter). Hierbei wird vorausgesetzt, daß die Liste komplett im ursprünglichen OS-Pool liegt und dieser nicht etwa schon erweitert wurde (z.B. durch FOLDRXXX.PRG). Ferner ist denkbar, daß Pool-Manipulationen residenter Programme, z.B. Monitore, den Suchalgorithmus blockieren könnten, die Reihenfolge der Programme wäre hier zu beachten: Je früher der Start, desto höher die Erfolgswahrscheinlichkeit! Die Suchrichtung von oben nach unten ist zwar um einiges langsamer, hat sich aber als stabiler erwiesen. Das Problem der ‘Sackgassen durch Geister-MDs’ wird zwar in beiden Suchrichtungen von der Routine gleich gut bewältigt, auch wenn man ihnen bei der Suche von unten nach oben natürlich öfter begegnet, zuweilen tauchen jedoch kurzfristig (!) ‘verstümmelte’ MDs auf, die mit ausgenulltem m_own vorzeitig die Abbruchbedingung erfüllen. Diese Gefahr hat sich bei der Suche von oben nach unten nicht ergeben.

Einbruchsgefahr!

Wie man sieht, bewegen wir uns hier auf ziemlich dünnem Eis. Sinnvolle Plausibilitätstests, in der richtigen Kombination, sind demnach das A und O solcher Routinen, da ließe sich evtl. noch einiges verfeinern. Das war auch mit der schwierigste Teil beim Entwurf der Routine, denn hier spiegeln sich ja alle Annahmen, die man so macht. Der Test auf 24-Bit-Adressen mußte dem TT zuliebe z.B. wieder gestrichen werden, ebenso die Annahmen über das Verhalten des mp_rover. Andere Tests erwiesen sich als nicht stabil: der ‘Ad-hockery’ sind bei solchen Problemen ja Tür und Tor geöffnet, und man muß schon sehr aufpassen, was für Annahmen man macht und was sie implizieren. Man darf sich auch nicht von SpeicherabbiIdern, sog. Dumps, zu generalisierenden Annahmen verleiten lassen. Wenn ich vorhin sagte, daß der Bereich um den MPB so schön leer sei, so gilt das durchaus nicht immer. Beim Nachladen anderer Programme werden u.U. direkt anschließend Tabellen mit Deskriptoren angelegt. Das bedeutet, daß die Abbruchbedingung der Routine z.B. unter auf dem AES laufenden Debuggern oder bestimmten Shells (u.a. Gulam, Gemini 1.2) nicht erfüllt werden kann. So etwas ist aber nun gerade nicht die Umgebung, unter der die Routine nachher laufen soll, und ich habe mich daher gehütet, hier ad hoc Abhilfe zu schaffen!

Weitere Einzelheiten zu erklären, erspare ich mir, und lasse dafür lieber den Code sprechen: Er ist ja kurz genug und, wie ich hoffe, ausreichend kommentiert. Also, immer die Zeiger suchen oder den Zeigern folgen! Glücklicherweise läßt sich dieses ganze Zeigergewurstel in Assembler nicht nur einigermaßen elegant programmieren, sondern der Code ist auch entsprechend schnell in der Ausführung, so daß selbst bei RAM-TOS, wo membot ja ziemlich hoch liegt und sich der Algorithmus erst durch das ganze TOS.IMG wühlen muß, passable Ausführungszeiten erreicht werden.

Die Programme

MAL_FIND gibt die ganze mal entsprechend dem Algorithmus von hinten nach vom aus, wobei ungültige MDs mit <invalid! gekennzeichnet werden. Weitere solche Markierungen hintereinander bedeuten, daß entsprechend viele Zeilen darüber als ungültig zu betrachten sind, wie schon oben erklärt. Dann wird der MPB ausgegeben und anschließend die mfl[8] von vorn nach hinten, den m_link-Zeigern folgend. Falls der Suchalgorithmus bei Ausgabe der mal steckenbleiben sollte, gibt es eine entsprechende Fehlermeldung.

GET_MPB gibt bei Erfolg nur den MPB aus, sonst eine Fehlermeldung. Der Code entspricht MAL_FIND bis auf die MD-Listenausgabe.

GET_MPB ist ein Modul, das zur Einbindung in Hochsprachen gedacht ist. In D0 wird bei Erfolg die Adresse des MPB zurückgeliefert, sonst eine Null. Man bedenke allerdings, daß so ein Modul wirklich nur zur Vewendung in ganz speziellen (meist resetfesten) Utilities geeignet ist und nicht etwa für Standard TOS- oder gar AES-Applikationen. Dort gibt es schließlich genug bekannte und gut dokumentierte Methoden, sich Speicher zu besorgen.

CART_MPB und BOOT_MPB sind die Implementationen der Routine für Cartridge bzw. Boot-Sektor. Sie installieren ein Cookie namens MPB* im Cookie Jar, auf das andere Programme dann zu greifen können. Falls das Cookie Jar erst eingerichtet werden muß (<TOS 1.6), wird auch ein Resethandler installiert, der die Systemvariable _p_cookies $5A0 bei einem allfälligen Warmstart wieder löscht, wie von Atari in [0] vorgeschrieben. Speicher für das Cookie Jar besorgen sich beide Programme in einer Art, die ich ‘stille Reservierung’ nennen möchte - also ohne Benutzung von Malloc(). Das ist, wie man sieht, sehr einfach - wir sitzen ja schließlich an der Quelle! Im Falle der Cartridge ist es noch einfacher und zudem die einzig mögliche Methode, da ja noch keine GEMDOS-Aufrufe gemacht werden dürfen.

Probe aufs Exempel

Spott erntet, wer sich darüber beklagt, daß sein wunderbares XYZ-Programm nicht auf der neuen OS-Version läuft. Neulich hatte ein (registrierter!) User endlich sein Update eines bekannten biegsamen Programms für TOS 1.4 erhalten und strahlte übers ganze Gesicht. Der STE stand auf dem Tisch. Ich sagte nur: ‘Nimm doch mal diesen hier... 4Unbekannte TOS-Version ’, das war’s! Betretenes Schweigen...

Bei aller Begeisterung für den wunderbar ‘tight & clean’ geschriebenen Code des Luftschlosses [10] aus Scheibenkleister II habe ich es wegen der dort enthaltenen Versionsabfragen zweiter Art nicht gustiert. RRN2500F wurde nach kurzem Test wieder gelöscht: Aus den Augen, aus dem Sinn! Doch nun her damit und neu ausgepackt! Das Stückchen Code schnell ersetzt, assembliert und gleich mal auf dem STE gestartet: läuft! Desgleichen auf diversen modernen RAM-TOS-Versionen, Blitter TOS, KAOS, RAM/ROM-TOS 1.0, Very OLD RAM-TOS 1.0 vom 20.11.85. Läuft nicht auf Rauchpilz-TOS, scheitert dort aber an act_pd (nicht in der Liste). Eine Abfrage erster Art wäre hier natürlich möglich, wird jedoch nicht eingearbeitet, da unwichtig!. Wer noch auf so einer alten Gurke hackt, muß wohl irgendwie von der Zivilisation abgeschnitten sein, vielleicht auf Expedition am Amazonas...

P.S. Nach nunmehr über einem Jahr stabilen Dauerbetriebs des mit der hier vorgestellten MPB Suchroutine ausgerüsteten ‘Luftschlosses’ auf meinem und einigen anderen Systemen unter wechselnden Konfigurationen, konnte es dank der Nachrüstung des stufen weisen Dereferenzierungsalgorithmus’ nun auch erfolgreich auf dem TT030 (32 MHz, TOS 3.01) getestet werden, so daß ich, von der relativen (Beachtung der Caveats) Robustheit des Algorithmus’ überzeugt, diesen einer größeren Öffentlichkeit nicht länger vorenthalten möchte. Eigentlich schön, daß Atari zur Zeit so aktiv ist: Die nächste Probe aufs Exempel wäre, ob’s auch auf TOS 2.05 des neuen Mega STE läuft.

Anmerkungen und Referenzen:

1. Leider sind diese Methoden selbst bei Leuten, die ansonsten etwas anderes ‘predigen’, noch immer nicht ganz aus der Mode gekommen. Hat’s doch subjektiv auch manches für sich: Das anhängige Problem ist gelöst, und wenn’s dann spätestens bei Erscheinen der nächsten OS-Version nicht mehr funktioniert, muß der Programmierer eben das Programm anpassen (Auftrag) und der Kunde halt zahlen (fürs Update). So steigert man das Bruttosozialprodukt!

2. Landon Dyer: A Hitchhiker’s Guide to the BIOS (HHG), 1985, Atari Corp
   Unter ‘themd’ heißt es: „Filled in by the BIOS on a ‘getmpb’ call; indicates to GEMDOS the limits of the TPA. ...(you can’t use the m_link field in the first MD). Someday (with a better GEMDOS) these limitations may be lifted.“ ...und stellt somit die Freigabe des MPB in Aussicht.

3. Alex Esser: TOS intern, ST-Computer 1987, Sonderheft Nr.2, S.35 ff.:
   Umfassende Analyse der GEMDOS-Speicherverwaltung, mit Programmen zur Erforschung der interessierenden Strukturen, basierend auf TOS 1.0. Siehe ebenfalls den 1. Teil des zweiteiligen Beitrags ‘Systemvariablen des TOS’, ST-Computer 11/88, sowie zu TOS 1.4 ‘Somewhere over the Rainbow’, 2 und 3, ST-Computer 5-6/90, vom gleichen Autor. In letzterem Beitrag übrigens auch die Beschreibung des oben genannten Pool-Bugs.

4. Allan Pratt. UUCP Message-ID: < 2737@atari.UUCP >, 12 Nov 90 20:03:26 GMT „...Getmpb is a BIOS call which is used by GEMDOS to find out the lay of the land at the beginning of the world: it is the BIOS’s way of telling GEMDOS what memory it found and where. It should not be used by user programs.

5. Zu diesem Zeitpunkt könnten wir übrigens auch, ohne den MPB zu ermitteln und damit dann die ‘mfl’ wie gehabt zu bearbeiten, völlig simpel gleich ‘themd’ manipulieren. Das ist es nämlich, was in Wirklichkeit geschieht, wenn man zu eben der Zeit über den MPB auf die ‘mfl’ zugreift: Sie besteht dann ja nur aus ‘themd’!

6. Allan Pratt, UUCP Message-ID: < 2756@atari.UUCP >, 30 Nov 90 02:03:15 GMT „...You can’t free memory which has stayed resident as a result of a TSR. It’s not even accounted for in the system as „allocated“ memory - it’s been UNHOOKED from the memory management lists. It’s GONE.“

7. B. Rosenlecher, ‘XBRA? XNAM?? BASEFIND!!!’, ST Computer 9/90, S.147 ff.

8. Bei meiner Standardkonfiguration (TOS 1.4 mit geladenem POOLFIX3 sowie weiteren fünf residenten und einem nicht residenten AUTO-Ordner-Programm und sechs Accessories) habe ich immer nur einen MD in der ‘ mfl ’ gesehen, auf den regelmäßig beide Zeiger mp_mfl und mp rover zeigten, bei anderen Konfigurationen auch schon mal 2 oder 3, und manchal sogar, daß der mp_rover nicht auf das gleiche Ziel zeigte wie der mp _mfl. Nur einen MD in der ‘mfl’ zu haben, bedeutet natürlich, daß der als frei ausgewiesene Speicher nur aus einem großen Block besteht und nicht etwa zersplittert ist, eine wirklich erfreuliche Tatsache also!

9. Atari Corp., STE TOS Release Notes, Jan 12, 1990, Sunnyvale, CA 94086

10. Claus Brod, Anton Stepper: Scheibenkleister II, MAXON Computer GmbH, Eschborn 1989. Das ‘Luftschloß’ ist eine über den Dateinamen konfigurierbare, superschnelle, resetfeste, autobootfähige, winzigkleine (mit eigener Optimierung unter 2 kB) RAM-Disk, die nach Einbau der hier vorgeschlagenen ‘ _geMnpb’-Routine auf allen relevanten TOS-Versionen läuft (hoffentlich zur Freude der Autoren wie auch der Anwender!).