Atarium: Der ATARI-Markt ohne ATARI

Trotz des grausigen Wetters hatten sich am letzten Novemberwochenende viele Interessierte auf der proTOS in Hennef eingefunden. Ähnlich wie für mich dürfte es für viele überraschend gewesen sein, wie professionell die Messe gestaltet und wie gut sie besucht war. Im direkten Vergleich zur MacWorld Expo in Frankfurt durfte man eigentlich noch ganz zufrieden sein (ein bißchen kleiner, ein bißchen weniger Styling, aber immerhin). Die nun folgenden Messeeindrücke erheben natürlich keinerlei Anspruch auf Vollständigkeit, sondern spiegeln nur wider, was speziell für mich interessant war.

Auf der Hardware-Seite erregten sicherlich die drei neuen' Hardware-Plattformen das größte Aufsehen: TOS Anwender können ihre Software künftig nicht nur auf ATARIs und Medusa, sondern auch auf dem Eagle' von GE Soft, der 060er-Medusa von Fredi Aschwanden und auf 68xxxer-Macs laufen lassen (letzteres dank der MagiC Portierung von Application Systems Heidelberg). Und gerade eben erst hört man aus England, daß C-Lab von ATARI die Rechte am Falcon und dessen Weiterentwicklungen übernommen haben soll - man darf gespannt sein, was aus dieser Richtung kommt (zunächst wohl ein leicht überarbeiteter Nachfolger mit höherwertigen Sound Bausteinen).

Daneben wurde natürlich jede Art von ATARI-Hardware verkauft bzw. verschleudert (2600er, 7800er, XE Game Systems, Portfolios, TTs und Jaguare). Daneben dürften wieder mal CD-ROMs ein Renner gewesen sein; angesichts der ständig fallenden Preise schneller SCSI-Geräte sicher kein Wunder.

Auf der Software-Seite waren für mich MagiCMac' (am zweiten Messetag konnte man bereits Testversionen kaufen) und Linux/68k die Eyecatcher'. Die endgültige Fassung von MagiCMac' soll im Januar kommen (bzw. gekommen sein), und man kann nur hoffen, daß die Entwickler bis dann noch die eine oder andere Lücke schließen können. Andererseits ist es natürlich klar, daß ein in so kurzer Zeit entstandenes Produkt zwar vielleicht stabil, aber noch lange nicht vollständig' sein kann.

Von Linux waren das aktuelle Patchlevel und eine erste Version vom X-Window-System (X11 R6) zu sehen. Zumindest auf einem TT mit monochromem Großbildschirm war die Geschwindigkeit sicherlich ausreichend (wenn man nicht gerade von erheblich schnelleren Plattformen verwöhnt ist).

Insgesamt war die Veranstaltung sicherlich ein Erfolg. Die Händler und Schnäppchensucher sind wohl auf ihre Kosten gekommen, und ein paar Neuigkeiten waren auch zu sehen. Dies unterstreicht, daß der TOS-Markt auch ohne ATARIs Mithilfe noch einige Zeit überleben kann und wird. Viele Innovationen sind dabei allerdings wohl nicht mehr zu erwarten; es geht in erster Linie darum, die Investitionen der Kunden in bestehende Software und Hardware zu schützen, indem man die Programme auch weiterhin pflegt und neuen Anforderungen anpaßt.

MagiCMac im Kreuzfeuer

Nun möchte ich noch zu einigen Themen kommen, die im MausNet in Hinsicht auf `MagicMac' zu allerlei Diskussionen geführt haben.

Eine häufig gestellte Frage auf der Hennefer Messe war sicherlich: „Wie bekomme ich unter MagicMac die Diskette aus dem Laufwerk?" Nun, einerseits funktioniert auch unter MagicMac der zugehörige Apple-Standard Shortcut (Apfel-Shift1). Zweitens kann man auch jederzeit in den Finder zurückschalten (Apfel-W). Allerdings kann man auch unter TOS schon lange Medien softwaregesteuert auswerfen. Bei MO-Laufwerken erledigt das zum Beispiel ein XHDI-kompatibler Treiber über die Funktion XHEject(). CDROMs lassen sich auswerfen, wenn der betreffende CD-ROM-Treiber den Fcntl-Opcode CDROMEJECT kennt (siehe in [ 1]). Man darf also hoffen, daß MagiCMac früher oder später eine dieser Methoden unterstützen wird. Gewiß werden spätestens dann auch die gängigen Desktops diese Funktion zugänglich machen. Wer es nicht erwarten kann, findet im neuesten Release der Mupfel-Tools [Maus MS2 (0251/77262): mupft106.tos] das Programm eject. ttp, das genau diese Funktionen benutzt.

Lange Dateinamen

Immer wieder taucht auch die Frage nach langen Dateinamen auf. Grundsätzlich wird es für die MagicMac-Entwickler einfacher sein, die langen Namen des Mac-Dateisystems zu unterstützen, denn die entsprechenden MiNT-Funktionen sind ja seit langem bekannt und sollten nun auch endlich benutzt werden (ohne Abfrage des MiNT-Cookies, versteht sich). Für kurze Dateinamen [also für Fsfirst() und Fsnext()] hingegen müssen die Namen halbwegs sinnvoll abgekürzt werden, und das ist nicht immer einfach.

In diesem Zusammenhang wird auch immer wieder danach gefragt, welche Zeichen denn nun in Dateinamen erlaubt sind. Die im GEMDOS Reference Manual und im Profibuch angegebenen Zeichen gelten nur (!) für TOS Dateisysteme, zeigen also keine Beschränkungen des GEMDOS an sich auf. Hinzu kommt, daß unter MSDOS schon seit langem mehr Zeichen erlaubt sind und TOS damit auch keine wirklichen Probleme hat (es sei denn, man benutzt zu allem Überfluß kleingeschriebene Umlaute).

Erlaubt sind grundsätzlich alle Zeichen, die nicht explizit verboten sind. Und das sind nur das Null-Byte (weil damit der Dateiname abgeschlossen wird), der Backslash (als Pfadtrennzeichen) und der Doppelpunkt (trennt Laufwerksnamen vom Rest). Der Schrägstrich (`/') kann übrigens schon mal in Dateinamen vorkommen, daher hat Eric Smith sich auch strikt geweigert, im MiNT-Kernel alternativ auch dieses Zeichen als Pfadtrenner zu erlauben! Schließlich will ich noch was zum Thema Return-Werte sagen: mittlerweile sollte sich ja herumgesprochen haben, daß der Aufruf nicht existierender GEMDOS-Funktionen grundsätzlich zum Fehlercode -32 (long) führt. So und nur so kann man überprüfen, ob eine GEMDOS-Funktion vorhanden ist oder nicht. Das heißt aber auch, daß der Returncode jeder GEMDOS-Funktion 32 Bits breit ist, ob es nun so im Handbuch, der Online-Help oder im Headerfile angegeben ist oder nicht. Anderenfalls kann man bei manchen Funktionen nicht zwischen dem Fehler - 32 (long) und einem Returnwert -32 (int) unterscheiden.

Besonders gefährlich ist solche Schlamperei bei den Funktionen Fopen() und Fcreate(). Wenn bei Fopen() nämlich -2 herauskommt, muß man sich schon etwas genauer überlegen, ob es nun -2 (long) ($FFFFFFFE: Fehlermeldung: Drive not ready) oder -2 (int) ($0000FFFE: Handle -2) war. Daher: solche Returncodes sollten immer erst nach der Fehlerbehandlung auf einen 16-Bit-Wert gecastet werden!

Julian F. Reschke

Quellennachweis:
[1] Julian F. Reschke: „Atarium -Audioprogrammierung ", ST-Computer 7-8/1994, Seite 77