In den vergangenen Monaten haben mich immer wieder Mails erreicht, in denen darum gebeten wird, mehr auf MiNT einzugehen. Tatsache ist leider, daß es im MiNT-Bereich im letzten Jahr nur sehr wenig Weiterentwicklungen gegeben hat. Zu erwähnen ist gerade mal, daß sich eine MiNT-Version in Erprobung findet, in der der Systemaufruf Pfork() nicht mehr den aufrufenden Prozeß blockiert.
Normalerweise braucht man dafür die Hilfe einer PMMU, doch MiNT schafft es auch auf alten Maschinen. Ähnlich wie schon früher in Minix wird das Problem durch Umkopieren der Speicherbereiche gelöst. Das ist zwar langsamer als 'the real thing', aber dafür ist es wenigstens auf allen ATARI-Maschinen nutzbar.
Ebenfalls interessant ist, daß es nun endlich eine alternative zum MultiTOS- AES von ATARI gibt. Gribnifs "Geneva" läuft nämlich in der neuesten Version nun auch unter MiNT. Eine (englischsprachige) Demoversion findet man in vielen Mailboxen des MausNet, zum Beispiel in der Maus MS2 ("gnvademo.lzh").
Was viele nicht wissen, ist, daß MiNT nicht nur auf ATARIs läuft. Erst jüngst wurde MiNT auf einer 68030-VME-Karte zum Laufen gebracht, indem gerade mal die TOS-Funktionen implementiert wurden, die MiNT selbst braucht(zusätzlich mußte MiNT natürlich auch teilweise angepaßt werden).
Warum macht sich jemand derart viel Arbeit für eine absolute Nischenanwendung? Einmal gibt es natürlich immer den gesunden Programmiererergeiz: was theoretisch machbar ist, will natürlich früher oder später auch mal ausprobiert werden. Hinzu kommt aber eine absolut reale Anwendung: je 'exotischer' eine Rechnerplattform, desto schwieriger und teurer ist es, sich mit Software (Tools, Compiler etc.) für diesen Rechner zu versorgen. Hat man einmal MiNT zum Laufen gebracht, kann man in der Regel auch große Teile der nicht GEM-basierten TOS-Software (gcc, Shells usw.) in Betrieb nehmen.
Ähnliche Beweggründe spielten auch eine Rolle, als - lange vor MagiCMac!!! - MiNT auf dem Mac zum Laufen gebracht wurde. Auch hier wurde gerade so viel von TOS implementiert, wie unbedingt nötig war, um MiNT hochzufahren. In diesem Fall heißt der Kernel "JET" ("Just Enough TOS") und impiementiert neben den allerwichtigsten TOS-Aufrufen eine VT52-Konsole in einem MacOS-Fenster. Das heißt, daß im Gegensatz zu MagiCMac zwar keine GEM-Software benutzt werden kann, dafür aber die TOS-Programme direkt in einem Mac-Fenster auf dem Finder-Desktop laufen können. Leider sind die mir vorliegenden Versionen von MacMiNT nicht sonderlich stabil, dafür sind aber die Sourcen frei verfügbar. Wer ein interessantes Betätigungsfeld sucht und sowohl über MacOS als auch über TOS Bescheid weiß, sollte sich den aktuellen Stand vielleicht mal ansehen (ftp://suniams1.statistik.uni-muenchen.de/incoming/MacMiNT oder ftp://archive.cis.ohio-state.edu/pub/mac-unix/macmint).
Vergleicht man MacMiNT mit MagiCMac, findet man einige grundlegende Unterschiede, aber auch allerlei Parallelen. Völlig abweichend ist schon der Ansatz: das Ziel von MacMiNT ist, zumindest große Teile von der sauber programmierten TOS-Software auf einem Mac nutzen zu können. MagiCMac hingegen implementiert ein komplettes TOS-kompatibles Betriebssystem und läßt lediglich die ATARI-Hardware außen vor.
MacMiNT versucht gar nicht erst, TOS komplett abzubilden. So werden bis auf wenige Ausnahmen die Systemvariablen nicht mit emuliert, weil MacOS diesen Speicherbereich selbst braucht. Dadurch ist der technische Aufwand innerhalb von MacMiNT erheblich kleiner, weil nicht erst die PMMU bemüht werden muß. Außerdem gibt es vermutlich weniger Probleme mit PowerMacs und virtuellem Speicher.
Der Nachteil ist natürlich, daß viele nach normalen Maßstäben sauber geschriebene TOSProgramme nicht laufen, weil sie sich auf die Existenz und das Funktionieren einiger Systemvariablen verlassen.
Verlassen darf man sich nur noch auf den Zeiger auf den Cookie-Jar. Diese Variable mußte schon deshalb unterstützt werden, weil alle mit der MiNT-Library gelinkten Programme nach einem MiNT-Cookie suchen. Findet man im Cookie- Jar den Cookie SVAR, sollte man von wirklich allen anderen Systemvariablen die Finger lassen. Dann darf man allerdings auch darauf hoffen, seine Programme unter MacMiNT benutzen zu können (meine diversen Utility-Sammlungen und vielleicht auch die Mupfel werden schon sehr bald darauf angepaßt sein). Bei anderen Aspekten wiederum ähneln sich MacMiNT und MagiCMac deutlich: so wird der Zugriff auf das Mac-Dateisystem über einen internen, fest in den Kernel eingebundenen XFS-Treiber implementiert. Das heißt, daß zum Beispiel lange Dateinamen auf genau die gleiche Art und Weise unterstützt werden (eben so, wie es durch MiNT definiert worden ist und wie es MagiC nachempfunden hat).
Dennoch bedarf MacMiNT dringender Renovierungsarbeiten. Beispielsweise fehlen etliche 'minder' wichtige TOS-Aufrufe (Sversion()!), und auch einige wichtige Werte im Cookie-Jar sind gar nicht oder teilweise falsch gesetzt. Diese Verbesserungen wären an 'JET', also einer Mac-Applikation, durchzufahren. Die Anpassungen am MiNT-Kernel selbst halten sich hingegen in überschaubaren Grenzen und könnten mittelfristig in den normalen MiNT-Source-Baum einfließen. Es wäre schön, wenn dieser Artikel dazu beitragen würde, daß das Interesse an MacMiNT wieder auflebt.
Bis zum nächsten Monat!