Atarium: Kurz vor MultiTOS

Allen Unkenrufen zum Trotz geht es bei Atari mit der Entwicklung der Systemsoftware weiter voran — besonders, seit MiNT-Schöpfer Eric Smith in Sunnyvale arbeitet.

Seit Januar sind die Sourcen von MiNT 0.99 Patchlevel 2 frei verfügbar. Damit ist klar, wie es Atari künftig mit den MiNT-Sourcen halten will: sie bleiben frei verfügbar, was die Weiterentwicklung ebenso wie die Fehlerbeseitigung erleichtern wird.

Der nun freigegebene Sourcecode enthält auch alle Quelltexte zur Memory Protection — es wird also künftig keinen Unterschied zwischen einem »MultiTOS-MiNT« und einem »Eric-MiNT« geben. Wichtig ist, daß nur die Quelltexte, nicht aber fertig übersetzte Kernel, weitergegeben werden dürfen. Damit soll erreicht werden, daß die Betaversion nur von erfahrenen Programmierern zu Testzwecken eingesetzt wird. Diese Einschränkung sollte man nicht leichthin ignorieren, ist sie doch Voraussetzung dafür, daß wir auch künftig Einblick in den Sourcecode nehmen dürfen.

Ein paar Hinweise für alle, die sich mit MiNT 0.99 beschäftigen wollen: das »alte« AES in existierenden TOS-ROMs funktioniert nicht mit Memory-Protection. Im Zweifelsfall muß die Memory-Protection per Kommandozeilen-Parameter ausgeschalten werden. Direkt übersetzen kann man die vorliegende Fassung der Sourcen nur mit »GNU-CC«. Die notwendigen Änderungen zur Übersetzung mit »Pure C« kann man dem Archiv »mnt99pc.zoo« entnehmen (sollte überall da erhältlich sein, wo es MiNT-Quelltexte gibt).

Da die Quelltexte zur Memory Protection frei verfügbar sind, ist es an der Zeit, auf die verschiedenen Schutzmodi zu erläutern: »normalerweise« ist der gesamte, zu einem Prozeß gehörende Speicher »privat« (Modus 0). Das heißt, nur der Kernel und der Prozeß selbst können auf diese Speicherbereiche zugreifen. Natürlich ist dies der sicherste Modus. Daher sollte man sich immer bemühen, seine Programme so zu schreiben, daß sie in diesem Modus funktionieren.

Doch es gibt Ausnahmen: Viele resident geladene Programme »veröffentlichen« zum Beispiel über den Cookie Jar Zeiger auf programminterne Speicherbereiche. Andere Applikationen benutzen AES-Messages, um Zeiger auf interne Speicherbereiche auszutauschen (s. beispielsweise XACC- oder VA-Protokoll).

Zum Glück gibt es drei weitere Schutzmodi, mit denen man sich der jeweiligen Sachlage anpassen kann:

Im Modus »Global« ( Modus 1) sind die Speicherbereiche völlig ungeschützt. Wie man sich denken kann, sollte man in einem Multitasking-Betriebssystem diesen Modus möglichst meiden. »Super« ( Modus 2) erlaubt Zugriffe, wenn man sich im Supervisor-Modus befindet (ähnelt also dem Status der Systemvariablen unter dem normalen TOS). »Private/readable« (Modus 3) schließlich erlaubt es allen anderen Prozessen, lesend zuzugreifen.

Entgegen vielfach geäußerter Meinung kann auch unter Memory Protection das Textsegment verändert werden. Dies ist allerdings eine Folge der Tatsache, daß der Kernel zur Zeit beim Laden Textsegment und Datensegment nicht auf unterschiedliche Pages legen kann — bei neuen Programmformaten kann sich das ändern. Wie legt man fest, welcher Schutzmodus benutzt werden soll? Zunächst beachtet MiNT neue Flags im Programmheader. Bestehende Programme laufen daher automatisch im Standardmodus »Privat« (dies gilt sowohl für den Programmcode, als auch für alle vom Programm angeforderten Speicherbereiche!). Bei Programmen, die per »Ptermres()« beendet worden sind, werden automatisch alle »privaten« Speicherbereiche »global« gemacht. Damit sollten die meisten residenten Programme ohne jede Modifikation funktionieren. Diese generelle Voreinstellung kann das Programm auch zur Laufzeit ändern, indem es einen speziellen »Fcntl()«-Aufruf auf der zugehörigen Prozeßdatei in »u:\proc« macht.

Änderungen im Programm-Header

Geschützter Speicher

Daneben kann man auch per »Mxalloc()« gezielt Speicherbereiche mit speziellen Schutzeigenschaften anfordern. Dies ist beispielsweise dann praktisch, wenn ein Programm nur einen einzigen Speicherbereich »freigeben«, an allen anderen Stellen aber geschützt bleiben will. Zu diesem Zweck sind die Bits 4...7 des Modus-Parameters bei »Mxalloc()« reserviert worden: ein Wert von Null gibt hier an, daß die normale Einstellung für den aktuellen Prozeß benutzt werden soll. Anderenfalls übergibt man Eins plus die Nummer des gewünschten Schutzmodus.

Wichtig: GEMDOS mag es gar nicht, wenn man bei »Mxalloc()« diese neuen, bislang reservierten Bits setzt. Daher sollte man vorsichtshalber vorher den MiNT-Cookie inspizieren. Wer mehr über die Interna der Memory Protection erfahren will, sollte einen Blick in die Quelltexte werfen.

Was es Neues gibt? Eric Smith hat sich von der Pflege der MiNT-Libraries zurückgezogen — verständlich, denn er hat bei Atari alle Hände voll mit MultiTOS zu tun. Neuer »Library-Maintainer« ist Nicholas S. Castellano (entropy@terminator.is.itd.umich.edu). Bei Redaktionsschluß wurde Patchlevel 27 (als Betatest-Version) veröffentlicht, aber bis Sie diese Ausgabe in Händen halten, gibt es mit großer Wahrscheinlichkeit schon eine neue Version.

Neu ist auch die Fassung 1.01 der XHDI-Spezifikation ([2] und [3]). Alle Änderungen sind Erweiterungen, die in Hinsicht auf IDE-Festplatten vorgenommen worden sind: neue Fehlercodes und eine erweiterte Auskunftsfunktion für Geräteinformationen. Die vollständige Spezifikation ist als »xhdi-101.zoo« in Mailboxen und im Lieferumfang des Festplattentools »Diskus« von Uwe Seimet (Vertrieb »CCD«) zu finden. (uw)

Leider konnten wir uns aus Platzgründen in der letzten Ausgabe ein kurzes Listing und das Projekt-File nicht abdrucken. Hier die »Nachlieferung«:

; @(#)Atarium/setstack.c
; Julian F. Reschke, 9. Januar 1993

		.globl setstack

setstack:
		move.l	0(sp),d0
		move.l	4(sp),sp
		move.l	d0,-(sp)
		rts



mint_tsr.prg
=
mint_tsr.c
setstack.s
pctoslib.lib

[1] Julian F. Reschke, »MiNT 0.96 — »Shared Text« und Debugging«, ST-Magazin 12/1992, Seite 98

[2] Julian F. Reschke, »Die XHDI-Spezifikation«, ST-Magazin 6/92, Seite 85

[3] Julian F. Reschke, »Die Gruselwelt von AT-Bus-Platten«, ST-Magazin 2/92, Seite 100