AtariX 64bit

[tosbombe]

Hi,

AtariX lässt sich spätestens für macOS 10.15 nicht mehr bauen, da 10.15 nur noch 64bit Binaries startet und AtariX noch auf Carbon basiert. Das Carbon Framework gibt es aber meines Wissens nach nicht mehr als 64bit SDK.

Die Rahmenapplikation müsste nach Cocoa portiert werden. Eventuell könnte man das Gerüst gleich in Swift implementieren.

Hat sich schon jemand an einer Aktualisierung versucht?

Grüße
Sven

[Lukas Frank]

Vor dem gleichen Problem stehe ich auch ...

[Thorsten Otto]

Ja, das Problem ist bekannt.

Eventuell könnte man das Gerüst gleich in Swift implementieren.

Schlechte Idee. Abgesehen davon daß ich Swift für ziemlichen Blödsinn halte (was bitte schön kann man in Swift was man nicht auch in anderen Sprachen kann?), würde sich die Applikation dann nicht mehr für älterere MacOS Versionen bauen lassen.

Hat sich schon jemand an einer Aktualisierung versucht?

Noch nicht aber ich hatte es mir schonmal angeschaut. Wird nicht trivial, Haupt-Probleme dabei sind der Filesystem-Treiber für das Hostfs (essentiell da der Emulator davon bootet), der momentan mit Carbon-Funktionen implementiert ist die eine ID für das Directory benutzen, da müsste man dann auf komplette Pfadnamen umstellen. Anderes Problem ist daß einige Pointer auch an den geladenen Kernel weitergereicht werden und dann 64bit sind, der Kernel aber sowohl für 32bit als auch für 64bit funktionieren muss (er weiss ja nicht in welchem Emulator er später geladen wird).

Ich bin allerdings auch kein absoluter macOS-Experte, wenn du es dir mal anschauen willst sind meine aktuellen sourcen unter https://github.com/th-otto/MagicMac bzw. https://github.com/th-otto/AtariX

[Lukas Frank]

Habe gerade meinen MacMini auf macOS Catalina geupdatet und alle alten 32-bit Programme gelöscht.

Ich hoffe das irgendwann mal AtariX 64bit fähig wird !?!

[Thorsten Otto]

Kann ich von meiner Seite aus nicht so bald versprechen (irgendwie zu viele Baustellen im moment

Mir wäre auch wohler wenn ich da Unterstützung von jemandem hätte der sich besser mit macOS auskennt.

[tkreutz]

Ja, das Problem ist bekannt.

Eventuell könnte man das Gerüst gleich in Swift implementieren.

Schlechte Idee. Abgesehen davon daß ich Swift für ziemlichen Blödsinn halte (was bitte schön kann man in Swift was man nicht auch in anderen Sprachen kann?), würde sich die Applikation dann nicht mehr für älterere MacOS Versionen bauen lassen.

Es ist ja nicht nur die Pflege der Sprache, sondern auch der damit verbundenen Umgebung- und Möglichkeiten.

Objective C und Cocoa sind halt in die Jahre gekommen, gerade auch was die Pflege von Software nach vorne hin angeht. Der aktuelle Trend ist eben auch die Möglichkeit, hybride Apps zu entwickeln und mobile Apps- sowie Desktop Apps zu vereinen. Der User will heute seine Arbeit auf dem Rechner zu Hause anfangen, unterwegs mit dem Smartphone oder Tablet weiter daran arbeiten und im Büro die Arbeit fertigstellen. Ob dieser Trend "gesundheitlich" toll ist, steht natürlich auf einem anderem Blatt. Aber Allways on wird nur schwerlich wieder rückentwickelt werden.

Was die Sprachfeatures angeht, so gibt es doch recht umfangreiche Informationen über neue Features u.a. auf Swift.org. Andere Sprachen haben ähnliche Features schon lange integriert, nur Apple hat lange gebraucht, um seinen Entwicklern hier mal etwas zu bieten. Das ist eben 2019 geliefert worden. Und nachdem die ersten Versionen von Swift einfach Schrott waren, funktioniert es nun langsam.

Natürlich hätte man das auch mit anderen Sprachen haben können. Aber wenn der Hersteller diese nur halbherzig in seine Plattform integriert, ist den Entwicklern ja nicht geholfen.

https://www.hackingwithswift.com/articles/182/whats-new-in-swift-5-1

Ich wundere mich ehrlich gesagt immer über Entwickler, die von Informationen "überrascht" werden, die seit Jahren bekannt sind.

https://www.heise.de/mac-and-i/meldung/macOS-Apple-kuendigt-32-Bit-Apps-OpenGL-und-OpenCL-ab-4068653.html

[Thorsten Otto]

Es ist ja nicht nur Swift, auch alles andere was daran hängt, die komplette GUI müsste neu programmiert werden. Und Swift ist halt auch nur für neuere Systeme verfügbar, womit man dann zwei Applikationen pflegen müsste.

Aber keiner hält dich davon ab das zu portieren

[tkreutz]

Es ist ja nicht nur Swift, auch alles andere was daran hängt, die komplette GUI müsste neu programmiert werden. Und Swift ist halt auch nur für neuere Systeme verfügbar, womit man dann zwei Applikationen pflegen müsste.

Aber keiner hält dich davon ab das zu portieren

Ja, leider ist es so. Meiner Meinung nach ist man allerdings besser beraten, sich in so einem Fall eher einer bestehenden Community anzuschließen, anstatt das 23ste Nischenprodukt alleine zu entwickeln.

Gut, MagiC hatte sicher seine Kunden. Aber jede Softwarelösung lebt auch von ihrer Unterstützung. Wem nützt es, das tollste Produkt in Form von Sourcen zu besitzen, wenn keine Unterstützung in Form von reichlich Manpower gefunden werden kann ?

[Thorsten Otto]

Äh, reichlich Manpower? Wo soll die plötzlich herkommen?

Und ich glaub auch nicht, daß sich die Swift-Community plötzlich mit Retro-Systemen wie dem Atari beschäftigen wird. Da hilft nur eins: selber machen.

[tkreutz]

Äh, reichlich Manpower? Wo soll die plötzlich herkommen?

Und ich glaub auch nicht, daß sich die Swift-Community plötzlich mit Retro-Systemen wie dem Atari beschäftigen wird. Da hilft nur eins: selber machen.

Das war doch ironisch gemeint  (Mein Irrglaube führte mich zu der Annahme, dass es bei Hatari zahlreiche Unterstützer gäbe) Ja, leider scheint es immer schwieriger zu werden, Unterstützer zu finden. Selber machen - ist natürlich ein Weg.

[gh-baden]

Kann ich von meiner Seite aus nicht so bald versprechen (irgendwie zu viele Baustellen im moment

Mir wäre auch wohler wenn ich da Unterstützung von jemandem hätte der sich besser mit macOS auskennt.

Ich frag mal Alexander Clauss auf’er CETiK …

[tkreutz]

Hallo Zusammen,

ich hatte auch ein Issue bei Gitlab hierzu eingestellt. Mittlerweile ist eine Antwort vom Maintainer eingetroffen, welche ich dem Forum nicht vorenthalten wollte:

Kopie der Antwort aus Gitlab, wo das Projekt zurzeit liegt:
-----------------------------------------------------------------------------

Daß das Programm mit Catalina nicht läuft, hat wohl zwei Gründe:

Wenn ich mich recht erinnere, wird ein 32-Bit-Programm gebaut. Das Umstellen auf 64 Bit wäre aber machbar.
Der bei weitem komplizierteste Programmteil ist der Umsetzer für die Dateisystem-Aufrufe (Dateien und Ordner lesen und schreiben). Der stammt noch vom „klassischen” Mac OS und lief bis macOS „Mojave” unter Verwendung der Carbon-API. Die gibt es aber nun nicht mehr. Eine Umsetzung wäre ein Neuschreiben.

Ich kann nicht versprechen, daß ich mich um das Problem kümmern kann. Ja, ich habe nicht einmal einen Rechner, auf dem Catalina läuft, ich könnte es also nicht einmal testen. Und die SDL sollte man auch mal austauschen...

[Thorsten Otto]

mein Reden

[gh-baden]

Anderes Problem ist daß einige Pointer auch an den geladenen Kernel weitergereicht werden und dann 64bit sind, der Kernel aber sowohl für 32bit als auch für 64bit funktionieren muss (er weiss ja nicht in welchem Emulator er später geladen wird).

Falls du damit meinst, dass die Abhängigkeit darin besteht, auf macOS 32 Bit und macOS 64 Bit funktionieren zu können – wir können da ja eine Umfrage machen, aber macOS ist schon sehr lange 64bittig, und die letzten Mac-Hardwarekisten, die 64 Bit nicht konnten, waren die Core Duo (ohne „2“) von 2006-2007.

Will sagen, auf 32bittiges macOS muss man IMO keine Rücksicht nehmen.

[Thorsten Otto]

Doch, muss man irgendwie. Momentan läuft AtariX ja nur als 32bit-Programm, auch wenn es auf einem 64bit-Prozessor ausgeführt wird. Für das Programm macht es keinen Unterschied, ob es auf macOS-32-Bit oder in der 32-bit-emulation von macOS-64-bit ausgeführt wird. Letztere gibt es dann mit Catalina nicht mehr.

[gh-baden]

Doch, muss man irgendwie. Momentan läuft AtariX ja nur als 32bit-Programm, auch wenn es auf einem 64bit-Prozessor ausgeführt wird. Für das Programm macht es keinen Unterschied, ob es auf macOS-32-Bit oder in der 32-bit-emulation von macOS-64-bit ausgeführt wird. Letztere gibt es dann mit Catalina nicht mehr.

Okay, ich kapier’s nicht :-)

Ich probier’s mal:

* AtariX ist ein reines 32 Bit-Programm
* Es läuft im 32-Bit-Subsystem bis 10.14
* Ab 10.15 entfällt das 32-Bit-Subsystem
* Seit macOS 10.6 sind alle macOSse 64bittig, seit 10.7 komplett

Ergo muss man doch bei einer Portierung von AtariX auf 64Bit mit entsprechenden An- und Umbauten nicht mehr Rücksicht auf 32bittige macOSse nehmen? Man muss IMO „nur“ den 64-Bit-Teil weiterpflegen, weil der alles seit 10.7, d.h. so grob 2007/2008 abdeckt.

Den 32-Bit-Teil kann so lassen wie er jetzt ist, und ignorieren. Damit bleibt ja „nur“ der Teil, ein Gutteil von AtariX umschreiben zu müssen.

[Thorsten Otto]

Ja, aber das Problem ist, AtariX besteht im wesentlichen aus zwei Teilen, dem eigentlichen Emulator, der unter macOS läuft, und einem speziell dafür angepassten MagiC-Kernel. Die Anpassung besteht u.a. darin, daß AtariX dem MagiC-Kernel bestimmte Resourcen des Hosts zur Verfügung stellt (z.B. einen Bildschirm-Puffer, in den die Ausgaben erfolgen, Callback-Funktionen für das Dateisystem etc.). Dieses sind dementsprechend teilweise Pointer, die je nach OS entweder 32- oder 64-bit sind. Der MagiC-Kernel ist aber in beiden Fällen der gleiche, da es ja eigentlich nur ein normales Atari-Programm ist.

Dazu kommt noch, daß bis Catalina macOS eigentlich beides gleichzeitig unterstützt, dh. wenn man einmal die 64-bit Anpassung vorgenommen hat, könnte man ein Programm bauen daß sowohl auf 32- als auch auf 64-bit läuft (oder auch für andere Prozessoren wie ppc).

Hoffe das war verständlich, weiss auch nicht wie ich es besser erklären soll;)

[tkreutz]

Dazu kommt noch, daß bis Catalina macOS eigentlich beides gleichzeitig unterstützt, dh. wenn man einmal die 64-bit Anpassung vorgenommen hat, könnte man ein Programm bauen daß sowohl auf 32- als auch auf 64-bit läuft (oder auch für andere Prozessoren wie ppc).

Hoffe das war verständlich, weiss auch nicht wie ich es besser erklären soll;)

Worin besteht eigentlich der wesentliche Unterschied z.B. zu anderen Emulatoren wie der Hatari ? - denn dieser läuft ja soweit ich es bisher beobachten konnte ohne Probleme auf dem neuen Catalina.

Ich dachte mir, ich frage einfach mal, da ich gesehen habe, dass Du ja auch irgendwo im Hatari Dev Bereich gelistet bist.

[Thorsten Otto]

Der Unterschied besteht darin, daß Hatari (und auch ARAnyM) problemlos als 64-Bit Programm übersetzt werden können. Auch benötigen die keinen speziellen Kernel, sie laufen mit TOS oder EmuTOS. Die Sourcen von AtariX sind aber schon recht alt, und benutzen Funktionen die es in der 64-bit-Umgebung nicht mehr gibt. Und er funktioniert nur mit dem MagiCMac-Kernel, auch nicht mit MagiC für Atari oder MagicPC

[tkreutz]

Der Unterschied besteht darin, daß Hatari (und auch ARAnyM) problemlos als 64-Bit Programm übersetzt werden können. Auch benötigen die keinen speziellen Kernel, sie laufen mit TOS oder EmuTOS. Die Sourcen von AtariX sind aber schon recht alt, und benutzen Funktionen die es in der 64-bit-Umgebung nicht mehr gibt. Und er funktioniert nur mit dem MagiCMac-Kernel, auch nicht mit MagiC für Atari oder MagicPC

Okay, danke.