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.

Endlich da: MultiTOS

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.

typedef struct { WORD ph_branch; /* 0x601A */ LONG ph_tlen; /* Länge des TEXT-Abschnitts */ LONG ph_dlen; /* Länge des DATA-Abschnitts */ LONG ph_blen; /* Länge des BSS-Abschnitts */ LONG ph_slen; /* Länge der Symboltabelle */ LONG ph_res1; /* reserviert; muss 0 sein */ struct { /* Bitfeld für PureC, ansonsten nachprüfen! */ unsigned tpasize; 4; /* Bit 28..31 */ unsigned res1: 12; /* Bit 16..27 */ unsigned res2: 4; /* Bit 12..15 */ unsigned shared; 1; /* Bit 11 */ unsigned res3: 3; /* Bit 8-*10 */ unsigned protection: 4; /* Bit 4..7 */ unsigned res4: 1; /* Bit 3 */ unsigned malt: 1; /* Bit 2 */ unsigned lalt: 1; /* Bit 1 */ unsigned fload: 1; /* Bit 0 */ } phprgflags; WORD phabsflag; /* 0: Relozierungsinformationen vorhanden */ } PH;

Ä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)

# Die zu MiNT 0.95 und zur Betatest-Version von MiNT 0.99 gehörenden Dateien.

MiNT 0.95 selbst:

mint095b.zoo (170705 Bytes) — die ausführbaren Programme und die Grunddokumentation.
mint095s.zoo (227093 Bytes) — die Quelltexte, kompilierbar mit Gnu-CC oder Lattice C
mntman95.zoo (44131 Bytes) — die Manual-Pages zu den neuen MiNT- Systemaufrufen (benötigt einen ‘nroff oder ‘groff als Formatierer).
mntutl95.zo (166131 Bytes) — Commandline-Utilities inkl. der C-Quelltexte MiNT 0.99,

Betatest-Version für Programmierer

mint99s.zoo (286668 Bytes) — Sourcecode der Betatest-Version von MiNT 0.99; geeignet für GNU-CC

MiNT-Libraries (Patchlevel 25, mit viel interessantem Beispielcode):

mntinc25.zoo (99712 Bytes) — Headerfiles
mntlib25.zoo (291753 Bytes) — Die C-Quelltexte
mntolb25.zoo (380466 Bytes) — die fertig übersetzten Bibliotheken für GNU-CC.

**MiNT-Libraries, Beta-Version (Patchlevel 27) **

mntinc27.zoo (99313 Bytes) — Headerfiles (auf ftp-Servern: mntinc27_beta.zoo)
mntlib27.zoo (351906 Bytes) — Headerfiles (auf ftp-Servern: mntlib27_beta.zoo)

Diese Dateien sollten in jeder besser sortierten Mailbox zu finden sein (zum Beispiel: »Maus MS2«, 02 51/772…). Leser mit Internet-Zugang können die Dateien uu. a. auf den ftp-Servern »atari.archive.umich.edu« und »ftp.uni-muenster.de« im Verzeichnis »atari/Mint« finden.

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


Julian F. Reschke
Aus: ST-Magazin 04 / 1993, Seite 62

Links

Copyright-Bestimmungen: siehe Über diese Seite