Atarium: Konkurrenz für die Konkurrenz

Neue Multitasking-AESse

Wer heutzutage vor der Wahl eines Multitasking-Systems steht, hat mehr Möglichkeiten offen als je zuvor. Nachdem das amerikanische Produkt „Geneva“ in Deutschland nicht so recht Fuß fassen konnte (wo ist denn nun die MiNT-kompatible Version?), kann man mittlerweile aus gleich drei anderen Alternativen auswählen! Alle haben gemeinsam, daß sie auf MiNT als Kernel aufbauen. Vielleicht wird dadurch auch der MiNT-Weiterentwicklung wieder etwas mehr Schwung gegeben.

„N.AES" wird von Overscan Berlin als MultiTOS-Nachfolger verkauft (wer MultiTOS bereits besitzt, kann es in Form eines Updates erwerben). Interessant wird es nicht nur durch den günstigen Preis und den umfassenden Lieferumfang (ST-Guide, Desktop N.Thing, MultiStrip etc.), sondern auch durch seine größere Stabilität und Geschwindigkeit gegenüber den letzten MultiTOS-AES-Versionen. Mit einer Neuprogrammierung der AES-Funktionalität des MultiTOS hat es allerdings Programmierer Jens Hiescher nicht bewenden lassen, sondern er ließ auch eine Vielzahl von Detailverbesserungen einfließen. So kann man beispielsweise das überflüssige Fuller-Feld im Fensterrand ausblenden (der Doppelklick auf die Titelliste hat ja ohnehin die gleiche Wirkung), oder die Menüleiste nur bei Bedarf einblenden (was die für Fenster nutzbare Arbeitsfläche vergrößert). Ein Beispiel mit dem Utility „MultiStrip" am unteren Bildrand sehen Sie in Abbildung 1.

Abbildung 1: CAB unter N.AES

Wer gar kein Geld ausgeben, dafür aber Einblick in die Sourcen haben will, kann gleich bei zwei verschiedenen Projekten fündig werden.

„XaAES“ von einer Gruppe um Craig Graham ist in einer frühen Betatest-Phase. Interessant sind nicht nur die ausgefallene Optik (siehe Abbildung 2), sondern auch die Interna: so kommunizieren die „Clients“ mit dem AES-Kernel über Pipes (ganz wie bei X .11). Bestehende GEM-Applikationen werden dabei durch TRAP-2-kompatible Routinen unterstützt. Trotz einiger Redraw-Probleme konnte man im Beta-Release 5 schon mit allerlei Programmen arbeiten.

Etwas konventioneller sieht hingegen „oAESis“ von Christer Gustavsson aus. Auch bei diesem Projekt stehen die Sourcen zur freien Verfügung (siehe Verweise auf Web-Server in Abbildung 3). Bleibt zu hoffen, daß mindestens eines dieser Projekte zu einem stabilen, freien GEM „für alle“ wird. Wer daran mitarbeiten will, sollte sich bei den Autoren melden.

Von neuen AES-Versionen für MiNT zum MacMiNT (siehe [1]) und gleich weiter zu MagiCMac ist kein weiter Sprung. Die Autoren des Mac-FS im MacMiNT haben glücklichenweise die Voraussicht besessen, die wichtigsten Mac-spezifischen Funktionen über die GEM DOS-Funktion Fnctl() für TOS-Programme verfügbar zu machen (siehe Listing 1).

Die Funktionen FMACGET-TYCR und FMACSETTYCR erlauben es, die sogenannten Finder-Information zu lesen oder zu verändern. Damit kann ein Programm gezielt dafür sorgen, daß die von ihm angelegten Dateien von einer bestimmten Mac-Applikation geöffnet werd en. Ebenso könnte ein Utility „Creator" und „Type“ anzeigen oder gar nach Dateien mit bestimmten Werten suchen. Dies ist beispielsweise im „find, ttp" der Mupfel-Tools (Rel. 10) implementiert (entweder über meine Web-Seite oder die Maus MS2 abzurufen) .

FMACOPENRES eröffnet den Zugriff auf die Resource-Fork der Datei. Damit können endlich alle Bytes einer Mac-Datei analysiert werden, oder ein Kopierprogramm kann Mac-Datei-en kopieren, ohne dabei die eine Hälfte unter den Tisch fallen zu lassen (in den Mupfel-Tools haben beispielsweise nun „cat.ttp" und „od.ttp“ Zugriff auf die Resource-Fork).

Glücklicherweise waren die Autoren von MagiCMac ebenfalls der Meinung, daß dies eine nützliche Einrichtung sei, und so bietet MagiCMac ab Version 1.3 genau die gleichen Funktionen an. In Listing 1 sehen Sie den Quelltext für das Einfach-Programm „showmac.ttp“, das Type, Creator sowie die Größen der beiden Forks anzeigt. Die Beispielausgabe in Abbildung 4 zeigt sehr schön, daß bei Mac-68K-Applikationen der wichtige Teil in der Resource-Fork steht und daß bei vielen anderen Dokumenten, wie zum Beispiel Framemaker-Texten oder Stuf-fit-Archiven, die Resource-Fork leer ist.

Abbildung 2: CAB unter XaAES

Abschließend noch eine Warnung: die Resource-Fork enthält komplizierte Strukturen, und der Mac ist nicht besonders glücklich, wenn man sie durcheinander bringt. Wer tatsächlich Schreibzugriffe auf die Resource-Fork machen will, sollte genau wissen, was er tut.

Bis zum nächsten Monat!

Julian Reschke

Quellennachweis:

[1] Julian F. Reschke, ATARIum, ST-Computer 12/1995, Seite 44

Listing 1: Fnctlfl-Opcodes für das Mac-Dateisystem

Overscan (N.AES): http://www.overscan.com

Christer Gustavsson (oAESis): http://www.mdstud.chalniers.se/~d2cg/oaesis/

Data Uncertain News & Support (XaAES): http://www.i-way.co.uk/~cgraham/home.html

Eine Übersicht gibt es auch auf der Homepage von Julian Reschke: http://wwwmath.uni-muenster.de/~reschke

Abbildung 3: Nützliche WEB-Adressen zu alternativen AES-Versionen

type crea data size rsrc size total filename
APPL R*ch 28960 242399 271359 BBEdit Lite 3.5
SITD SIT! 66483 0 66483 Chuck’s Printer Driver.s'rt
TEXT Fram 79872 0 79872 D20 cutover 05 96.frm
APPL EXTR 351736 13273 365009 MacMiNT112+VM.Binary
APPL MgMc 0 165763 165763 MagicMac

Abbildung 4: Beispielausgabe von showmac.ttp


Julian F. Reschke
Aus: ST-Computer 07 / 1996, Seite 42

Links

Copyright-Bestimmungen: siehe Über diese Seite