MagicMacX > Anhang > Versionsgeschichte Index

Änderungen in der Version 1.2 (20. Dezember 2004)

Erweiterte Einstellungen

In Einstellungen > Allgemeines können Sie die Emulation der rechten Maustaste konfigurieren.

Application Package

MagicMacX ist jetzt ein Application Package. MachO steht für Mach-Object, Mach ist der microkernel von Mac OS X. Applikationen im MachO-Paketformat haben folgende Eigenheiten:

1. Das Programm ist eigentlich ein Ordner .app (der Finder unterschlägt normalerweise das Suffix .app). Der Ordner enthält beliebige Programme und Daten, die man im Finder unter Paketinhalt anzeigen sehen kann.
2. Es gibt keine resource forks mehr wie in Mac OS Classic. Daher kann das Programm problemlos gepackt oder z.B. auf Windows-Systeme kopiert werden.
3. Die Lokalisierung ist einfach und wird sogar im Kontextmenü des Finders unterstützt. Für jede Lokalisierung existieren Unterordner mit entsprechenden Daten, mit denen die Standard-Daten überlagert werden können.
4. Statt des Prozessor-Registers gpr2 wird das Register RPIC verwendet, und zwar mit einem 32-Bit-Offset. Anscheinend ist RPIC aber gpr0, und dann verwendet der PowerPC absolute Adressen. Das wäre wegen der PMMU-Verwendung auch nicht verwunderlich (PIC = Position Independent Code).
5. Das Programm kann direkt von Mac OS X gestartet werden, auch von der Kommandozeile.
6. Das Programm kann nicht von Mac OS Classic gestartet werden.
7. Die Zuordnung zu Dateitypen (*.TOS, *.PRG usw.) ist auch ohne die klassische Type-/Creator-Methode möglich, d.h. wie bei Windows anhand des Dateisuffixes.
8. Die Icons liegen als einfach editierbare .icns-Dateien vor.

Die Vorteile des MachO-Paketformats überwiegen und die Nachteile lassen sich leicht in Kauf nehmen. Für MagicMacX ergeben sich damit insbesondere noch folgende Neuerungen:

1. Es gibt jetzt keine drei MagicMacX-Programme für Deutsch, Englisch und Französisch mehr, sondern nur noch eine, die automatisch je nach Systemeinstellungen die richtigen Ressourcen lädt. Der MagiC-Kernel ist ebenfalls lokalisiert. D.h., es liegen drei Versionen im Bundle, die je nach Spracheinstellung geladen werden.
   Achtung: Fehlt die Datei im Bundle, wird sie wie bisher vom Verzeichnis geladen, in dem das Bundle liegt. Es fehlen aber noch die Ressource-Dateien der Atari-Applikationen, z.B. MAGXDESK.RSC; diese sind nicht lokalisiert.
2. Es gibt eine eigene Icon-Datei für TOS-Programme, außerdem ist auch ein spezielles Icon für den Dateityp .CDK vorgesehen, aber es gibt noch keine zugehörige .icns-Datei.

Neue PlugIns (XCMDs)

Wegen des MachO-Formats von MagicMacX gibt es ein ganz neues PlugIn-Konzept, das sich an den Apple-Vorgaben (CFPlugIn) orientiert. Das Beispielprojekt ist für Xcode ausgelegt.

Von der Atari-Seite aus können außer den PEF-/CFM-Bibliotheken jetzt auch die neuen CFPlugIn-Bibliotheken im MachO-Format eingebunden werden. Dazu gibt man den ganzen Namen einschließlich Suffix (z.B. .bundle) als Bibliotheknamen an. Gesucht wird dann in

~/Library/MagicMacX/PlugIns

sowie in

/System/Library/MagicMacX/PlugIns

Weitere Informationen liefert das mitgelieferte Beispiel-PlugIn.

Alte XCMDs

Die bisherigen XCMDs (PlugIns) werden noch (eingeschränkt) unterstützt. Das eine Problem dabei besteht darin, daß die Bibliotheken im PEF-Format sind und vom CFM (Code Fragment Manager) verwaltet werden, das Programm selbst aber inzwischen ein MachO-Programm ist. Dafür muß sogenannter glue-Code eingebunden werden (call CFM from MachO), der zur Laufzeit einen Code-Schnipsel generiert, welcher die CFM-Funktion aufruft. Die Callbacks müssen natürlich andersrum ver-glue-t werden (call MachO from CFM). Beim Entladen der Bibliotheken werden alle Schnipsel wieder freigegeben. Das zweite Problem ist die Carbon-Funktion GetSharedLibrary(), die offenbar überhaupt nicht mehr funktioniert, d.h. die Bibliotheken nicht finden kann.

Um das zweite Problem, das Nichtfinden der Bibliotheken, zu umgehen, mußte statt GetSharedLibrary() die Funktion LoadDiskFragment() verwendet werden, die aber einen Dateinamen (eigentlich einen FSSpec) und nicht einen Bibiotheknamen benötigt. Wenn ein Atari-Programm den Bibiotheknamen angibt, so muß der Dateiname geraten werden, indem, wenn er keine Endung hat, .lib oder .shlib angehängt wird.

Zur Zeit sucht MagicMacX die PlugIns ausschließlich innerhalb des Paketes (application packet), und zwar dort, wo die ausführbare Datei liegt, also in (!FILE [MagicMacX.app/Contents/MacOS]). Eine spätere Version könnte aber einen Plugin-Ordner im Paket unterstützen.

Folglich müssen alle XCMDs, auch die von Calamus, in das Paket kopiert/verschoben werden. Der Ordner Preload-XCMDs sollte nicht mehr verwendet werden.

Beim Laden eines PlugIns (initiiert von der Atari-Seite aus) wird, wenn ein Pfad angegeben ist, nur eine CFM/PEF-Bibliothek geladen. Falls statt des Pfades ein Name angegeben wurde, wird zunächst ein CFPlugIn (MachO-Bundle) von (!FILE [~/Library/MagicMacX/PlugIns]) geladen, und, wenn es dort nicht gefunden wird, in (!FILE [/Library/MagicMacX/PlugIns]) und schließlich, wenn es dort auch nicht gefunden wird, wird eine CFM/PEF-Bibliothek gesucht.

68k-Emulator

Diverse Optimierungen im 68k-Emulator haben die Ausführungsgeschwindigkeit der Atari-Programme etwas erhöht. Es gibt ja bekanntlich keinen objektiven benchmark, aber der Gewinn dürfte so bei 10 bis 20 % liegen.

Eine neue Version von (!FILE [MagicMac.OS]) signalisiert dem Emulator, wenn sich MagiC in der idle loop befindet. Der Emulator-Thread legt sich dann schlafen, bis ein simulierter Interrupt auftritt. Damit braucht MagicMacX nur noch wenig Rechenzeit auf dem Mac, wenn gerade kein Atari-Programm läuft (d.h. Berechnungen o.ä. durchführt).

Emulatorfenster

Die Funktionen MagicMacX ausblenden bzw. Andere ausblenden werden jetzt berücksichtigt. Dabei wird dieser Fall wie ein manuelles Schließen behandelt. Beim Wiederöffnen wird der Inhalt des Atari-Emulatorfensters wieder automatisch neu aufgebaut.

Die Erkennung, wenn die Bildschirmeinstellungen geändert wurden (Größe, Farben), mußte geändert werden und benötigt jetzt mindestens Mac OS X 10.3 Panther (CGDisplayRegisterReconfigurationCallback() statt DisplayManager). Damit sollte MagicMacX bei Änderung der Bildschirmeinstellungen nicht mehr abstürzen, außerdem ignoriert MagicMacX Änderungen, die an anderen Bildschirmen als dem verwendeten vorgenommen werden.

Klick auf Icons im Finder

Das Apple-Event odoc wird ausgewertet, d.h., Sie können MagicMacX jetzt durch Doppelklick auf eine TOS-Datei starten oder eine Datei auf das Icon des laufenden Programms ziehen. Dazu braucht man aber den MagicMacX-Dämon MMXDAEMN.PRG. Dieses Hilfsprogramm, das die Kommunikation zwischen dem Emulator MagicMacX auf der Mac-Seite mit dem emulierten Atari bereitstellt, installieren Sie am besten durch Kopieren nach C:\gemsys\magic\start\ auf der Atari-Seite.

Beenden des Emulators

Beim Beenden von MagicMacX wird versucht, das emulierte MagiC sauber herunterzufahren. Dazu muß, wie beim Starten von Programmen über Apple-Events, auf der Atari-Seite der MMXDAEMN laufen. Funktioniert das manuelle Herunterfahren (über den Menüpunkt in MagicMacX) nicht, so kann ein zweiter Versuch unternommen werden; nach Bestätigung eines Dialogs kann MagicMacX dann beendet werden, ohne den Emulator korrekt herunterzufahren.

Im Fall eines Apple-Events quit, ausgelöst über das Dock, durch Abmelden oder Herunterfahren des Rechners, hat das emulierte MagiC zehn Sekunden Zeit, sich zu beenden. Anschließend wird MagicMacX nach Rückfrage beendet.

Diverses

Die Druckdateien werden beim Beenden von MagicMacX automatisch gelöscht.

Das XCMD-Beispielprogramm, das eine Dateiauswahl zeigt, stürzt nicht mehr ab, wenn man den Dialog mit Abbrechen beendet. Das war offenbar doch kein Fehler in MagicMacX, sondern ein Systemfehler, den Apple mit 10.3 beseitigt hat.

Der Beenden-Dialog (Alert) MagicMacX sofort beenden? Nichtgesicherte Daten laufender Atari-Anwendungen gehen verloren behandelt jetzt die [Esc]-Taste wie einen Klick auf den Abbrechen-Button. Dafür mußte die Objekt-Numerierung geändert werden (2 = Abbrechen, 3 = OK). Die [Return]-Taste wird offenbar nicht unterstützt, so daß man hier wohl keine Eingriffmöglichkeit hat.

Dpathconf(-1) arbeitet jetzt korrekt. Leider wurde fälschlich auf 0xffff statt 0xffffffff abgefragt. (Auf dem Mac ist ein int 32 Bit breit, nicht 16 wie bei den meisten Compilern auf dem Atari.)

Dcntl() überprüft den übergebenen Zeiger und wird daher von Calamus nicht mehr zum Absturz gebracht.

Eine tschechische Lokalisierung (mit englischem MagiC-Kernel) wurde hinzugefügt.

Verbleibende bekannte Fehler

Mitunter tritt das Phänomen auf, daß bei installiertem NVDI und log=-Eintrag im [boot]-Abschnitt von MAGX.INF die BIOS-Textausgabe völlig im Eimer ist. Man merkt das z.B., wenn man [Ctrl][Alt][Esc] drückt und nicht viel sieht. Oder wenn man das Programm VT52.PRG umbenennt, so daß das System das Programm nicht finden kann, und dann ein TOS-Programm startet. Läßt man NVDI weg oder löscht die log=-Zeile aus MAGX.INF, ist wieder alles in Ordnung.

Die Tastenkombination [Ctrl][F1] scheint nicht richtig beim Atari anzukommen. Offenbar ist sie von Mac OS X reserviert. Um sie wieder zu ermöglichen, muß man unter Mac OS X das Systemeinstellungen-Kontrollfeld Tastatur und Maus > Tastatur-Kurzbefehle öffnen. Hier muß man die Aktion, die der Taste [Ctrl][F1] zugewiesen ist, abschalten.

Irgendwas stimmt aber im Kontrollfeld nicht: Die Funktion Fenster drehen (gemeint ist: zyklisch wechseln) hat den Kurzbefehl [Cmd][^], den kann man aber nicht von Hand aktivieren, wenn der Taste versehentlich etwas anderes zugewiesen ist. Man muß alles auf Standard setzen, dann stimmt es wieder.