AtariX => MagicOnLinux

[goetz @ 3rz]

Ich habe als Laufwerk D einen lokalen Pfad angegeben:

atari_drv_D = 4 /Users/goetz/Emulation/ST/C

Klicke ich dann unter MacOS 15.7.3 in MagiCDesk auf "D:" und drücke TAB, meldet zweimal MagiCDesk "Pfad nicht gefunden -34", zeigt dann aber doch den Dialog an:

Der Pfad enthält ein mittelmäßig gefülltes "Atari"-Laufwerk, wäre also prinzipiell ermittelbar. Dass MagiCDesk nichts an Inhaltsinfos anzeigt, liegt am HostFS?

[AndreasKromke]

Anscheinend stört man sich an der inkonsistenten Benamsung von Programmen und Dateien - zu Recht. Als erste Maßnahme heißt die Konfigurationsdatei jetzt wie das Programm, also "magic-on-linux.conf".

Eigentlich wollte ich aber die tausend Probleme lösen, auf die ich bei einer Probeinstallation auf einem anderen Rechner gestoßen bin. Ich kapiere immer noch nicht, wann man "index.theme" braucht und wann nicht und wie man das automatisch aktualisieren soll. Auf dem einen Rechner war es jedenfalls nötig, auf dem anderen nicht. Und außerdem mag das bekloppte "xdg-icon-resource" keine Vektorbilder. Das ist so bescheuert, daß es schon beschäuert ist. Also entweder von Hand reinkopieren oder in .png wandeln. Alles viel zu kompliziert. Ich werde jedenfalls die neuen Skripte selber nochmal testen müssen.

Was bisher noch niemandem aufgefallen ist: Beim ersten Start, wenn die conf-Datei geschrieben wurde, fand er seinen Kernel nicht. Da hilft nur testen, testen, testen.

[AndreasKromke]

Klicke ich dann unter MacOS 15.7.3 in MagiCDesk auf "D:" und drücke TAB, meldet zweimal MagiCDesk "Pfad nicht gefunden -34", zeigt dann aber doch den Dialog an:

Da könnten versteckte kranke Dateien liegen, an denen er sich stört. Mglw. zeigt die Debug-Version mehr an, wenn Du die Debug-Meldungen einschaltest. Vielleicht ist das XFS auch noch zu pingelig und sollte z.B. böse Dateien einfach überspringen bei Dreaddir().

[Thorsten Otto]

Da könnten versteckte kranke Dateien liegen, an denen er sich stört.

Vermutlich mal wieder diese ominösen .DS_Store Dateien, die der Finder immer und überall anlegt. Die passen halt nicht ins 8.3 Schema. Vlt. sollte man die (zumindest auf macOS) im XFS ausfiltern. Auf jeden Fall aber auf DOS-Verzeichnissen wie C: zB.

[thh]

Meiner ist etwa 20mal so schnell wie Hatari und etwa so schnell wie Aranym ohne JIT. Aranym-jit ist unerreicht, etwa 20- bis 40mal so schnell wie meiner.

Wäre die Unicorn-Engine (https://www.unicorn-engine.org/) evtl. eine Alternative für MagicOnLinux? Da wäre auch JIT dabei, sollte also ähnlich schnell wie Aranym sein...

[Thorsten Otto]

Da könnte man auch gleich QEMU nehmen. Wäre aber totaler Overkill, MagicOnLinux will ja nicht zig CPUs emulieren, sondern nur m68k.

Und QEMU ist (auch mit JIT) immer noch um Grössenordnungen langsamer als Aranym.

[AndreasKromke]

Etwas überflüssiges Wissen:

• KAOS ist ein Wortspiel aus "Kromke Andreas Operating System" und der Verbrecherorganisation aus der US-amerikanischen Serie "Get Smart" (siehe https://getsmart.fandom.com/wiki/KAOS)
  
• MagiX war ein Akronym von "Multi Application Graphical Interface eXtension".
  
• Wegen Namensgleichheit mit dem Programm MAGIX mußten wir das ändern in Mag!X ..
  
• .. und später dann in MagiC.
  

Deshalb haben einige Programme noch ein "MAGX" im Dateinamen.

Im Fenstertitel sollte eigentlich "MagiConLinux" stehen, das sieht aber aus wie "Magi-Con-Linux". Der Titel "magic-on-linux" ist häßlich, und dann bliebe noch "MagiCOnLinux", was auch saise aussieht.

[Thorsten Otto]

Schade, MagicOnLinux läuft leider nicht auf meinem 3.-Liebsten Betriebssystem, HaikuOS. GCC schmeißt beim HostXFS ettliche Fehler

Ein paar der Sachen lassen sich relativ leicht beheben (gleiches Problem wie bei macOS).

Was aber fehlt ist eine Funktion die zu einem Filehandle den Pfad ermittelt. Für linux/macOS wird dazu fcntl(F_GETPATH) verwendet. Das ist aber wenig portable, und würde wohl auch bei anderen Ports (Windows zb.) zu Schwierigkeiten führen. Für Haiku habe ich noch nichts entsprechendes gefunden.

Wenn du Lust hast, kannst du dich ja mal an https://github.com/th-otto/MagicOnLinux/tree/my versuchen. Ist soweit geändert daß es unter Haiku kompiliert, funktioniert aber noch nicht wegen den erwähnten Problemen.

Als Pakete werden (mindestens) cmake libsdl2_devel sdl2_mixer_devel benötigt.

gxmessage gibt es dort natürlich auch nicht. Die Version in src/gui/gxmessage lässt sich aber mit GTK3 bauen. Evtl kann man aber auch was Haiku-Spezifisches nehmen, ähnlich wie bei macOS.

[goetz @ 3rz]

MagiX war ein Akronym von "Multi Application Graphical Interface eXtension".

Danke, das war mir neu.

Ich war anno 199…2? auf einer Atari-Messe und einer der Behnes führte Mag!X vor, v.a. den Taskmanager. War noch kooperativ, damals.

Leider hatte ich als Schüler kein Geld :-/ Es dauerte noch ca. ein Jahr, bis ich MagiC bekam. Nach einer seeehr kurzen Periode mit MultiTOS (gäääähn, auf einem 16 MHz-Rechner), war das die Offenbarung für MultiTeX, Papyrus, Texel, Pure C, CAT, CoNnect, X-Act.

Im Fenstertitel sollte eigentlich "MagiConLinux" stehen, das sieht aber aus wie "Magi-Con-Linux". Der Titel "magic-on-linux" ist häßlich, und dann bliebe noch "MagiCOnLinux", was auch saise aussieht.

Haha, Magi-Con-Linux würde ja erlauben, die Mac- oder Haiku-Version dann Magi-Sin-Linux zu nennen. Aber Spaß beiseite: Welchen Namen/Schreibweise hätten’s gern, damit wir das mal glattziehen können?

Ich glaube Helli wird wegen MagiX nicht mehr meckern …

[kernal]

KAOS ist ein Wortspiel aus "Kromke Andreas Operating System"

Das hatte ich mir gedacht...

und der Verbrecherorganisation aus der US-amerikanischen Serie "Get Smart" (siehe https://getsmart.fandom.com/wiki/KAOS)

... und das nicht. Obwohl ich Get Smart natürlich immer gerne gesehen habe.

Im Fenstertitel sollte eigentlich "MagiConLinux" stehen, das sieht aber aus wie "Magi-Con-Linux". Der Titel "magic-on-linux" ist häßlich, und dann bliebe noch "MagiCOnLinux", was auch saise aussieht.

Warum überhaupt magic-on-linux? Es hiess ja auch nur MagiCMac und MagiCPC. Warum nicht einfach MagiCLinux?

Oh, ich habe es gerade recherchiert - es gibt schon eine Linux Distro die so heisst.

Da "MagiC-on-Linux" ja auch bereits auf Macs läuft und möglicherweise bald auch Haiku, wäre etwas generisches sinnvoller. Da du die Sourcen unter die GNU GPLv3 gestellt hast vielleicht "GnuMagiC"?

[AndreasKromke]

kein Kommentar

[ragnar76]

Schade, MagicOnLinux läuft leider nicht auf meinem 3.-Liebsten Betriebssystem, HaikuOS. GCC schmeißt beim HostXFS ettliche Fehler

Wenn du Lust hast, kannst du dich ja mal an https://github.com/th-otto/MagicOnLinux/tree/my versuchen. Ist soweit geändert daß es unter Haiku kompiliert, funktioniert aber noch nicht wegen den erwähnten Problemen.

Bauen tuts fein, keine Warnung oder Error. Allerdings kommt dann im Betrieb ein schwarzer Bildschirm. Das was auf der Konsole ausgespuckt wird ist im Anhang

gxmessage gibt es dort natürlich auch nicht. Die Version in src/gui/gxmessage lässt sich aber mit GTK3 bauen. Evtl kann man aber auch was Haiku-Spezifisches nehmen, ähnlich wie bei macOS.

gxmessage habe ich noch nicht probiert, es läuft ja auch ohne.

[Thorsten Otto]

Allerdings kommt dann im Betrieb ein schwarzer Bildschirm.

Ja, wie gesagt, kompiliert, aber funktioniert noch nicht. Es wird mindestens noch ein Ersatz für fcntl(F_GETPATH) benötigt (oder es muss so umgestrickt werden, daß man das nicht braucht, evtl. müsste dazu der Pfadname in der HostFD Struktur gespeichert werden). Ohne das funktioniert Fsfirst()/Fsnext() nicht, und damit wird auch der Bildschirmtreiber nicht gefunden, deswegen schwarzer Bildschirm.

Kenne mich aber eigentlich mit Haiku nicht besonders aus, hatte vor Jahren mal was damit gemacht, aber musste mir jetzt auch wieder einiges zusammen suchen.

War aber spannend zu sehen, daß es tatsächlich noch möglich ist, moderne Betriebssystem zu bauen, die in wenigen Sekunden booten.

[thh]

Da könnte man auch gleich QEMU nehmen. Wäre aber totaler Overkill, MagicOnLinux will ja nicht zig CPUs emulieren, sondern nur m68k.

Nein, der Gag an Unicorn ist ja, dass das als Library kommt, die auch schon bei vielen Distros einfach vorcompiliert dabei ist. D.h. es wäre einfach ein bequemer Ersatz für den CPU-Kern, ohne dass man sich mit den QEMU-Sourcen auseinandersetzen muss.

Und QEMU ist (auch mit JIT) immer noch um Grössenordnungen langsamer als Aranym.

Sollte trotzdem noch deutlich schneller sein als ohne JIT.

[Thorsten Otto]

Beim Start bekomme ich aus irgendeinem Grund noch eine Fehler-Meldung daß winframe.rsc nicht gefunden wurde.

Hat sich auch geklärt. Ich hatte natürlich meine lokale Kopie von WINFRAME.SLB in das Verzeichnis kopiert, und das hatte das SLB-Flag (bit 3 im Header) nicht gesetzt, wodurch kein Speicher für die Resource-Datei frei war

Müsste man evtl. auch mal in Slbopen fixen, daß dieses Bit automatisch angenommen wird. Oder die libs fixen, daß sie selber einen Mshrink() machen, so wie andere Programme auch.

[goetz @ 3rz]

Klicke ich dann unter MacOS 15.7.3 in MagiCDesk auf "D:" und drücke TAB, meldet zweimal MagiCDesk "Pfad nicht gefunden -34", zeigt dann aber doch den Dialog an:

Da könnten versteckte kranke Dateien liegen, an denen er sich stört. Mglw. zeigt die Debug-Version mehr an, wenn Du die Debug-Meldungen einschaltest. Vielleicht ist das XFS auch noch zu pingelig und sollte z.B. böse Dateien einfach überspringen bei Dreaddir().

Ja:

(16:00:50) DBG-WRN hostpath2HostFD() : fstatat("BUERO/PAPYRUS.X/VORLAGEN/PRA_SENTATIONSGRAFIK/") -> No such file or directory


mMn sollte sowas nicht als Warndialog an den Nutzer gemeldet werden, denn ohne Angabe was und wo kann er damit nichts anfangen.

[AndreasKromke]

fstatat("BUERO/PAPYRUS.X/VORLAGEN/PRA_SENTATIONSGRAFIK/") -> No such file or directory

Ob das etwas mit der "decomposed utf-8"-Apple-Krankheit zu tun hat? Versüch's mäl öhne Ümläute.

[goetz @ 3rz]

fstatat("BUERO/PAPYRUS.X/VORLAGEN/PRA_SENTATIONSGRAFIK/") -> No such file or directory

Ob das etwas mit der "decomposed utf-8"-Apple-Krankheit zu tun hat? Versüch's mäl öhne Ümläute.

Ohne Umlaut gibt’s keinen Fehler.

[AndreasKromke]

Ohne Umlaut gibt’s keinen Fehler.

Wenn Du Dir die Mühe machen möchtest, könntest Du Dich hier einlesen: [https://stackoverflow.com/questions/6153345/different-utf8-encoding-in-filenames-os-x]. Und schau mal, ob hier das Problem liegt.

Ich weiß schon, warum ich mich auf Linux/Ubuntu beschränkt habe. Dieser Unix-Wildwuchs ist lästig, das wäre trotz meiner Abneigung in Windows besser, da läuft es dann gleich überall.

PS: Das gleiche Problem hatte ich bei Android, wo ich nämlich Antonín Dvořák zweimal hatte, und beide sahen völlig gleich aus. Ich habe dann die Komponistendatenbank normalisiert, um Dubletten zu vermeiden. Unter Android bzw. Java gibt es dafür irgendwelche gruseligen Funktionen.

[goetz @ 3rz]

Wenn Du Dir die Mühe machen möchtest, könntest Du Dich hier einlesen: [https://stackoverflow.com/questions/6153345/different-utf8-encoding-in-filenames-os-x]. Und schau mal, ob hier das Problem liegt.

Ich kann bestätigen, dass mac OS decomposed UTF-8 nutzt. Ändern kann ich das bei mac OS nicht – ich könnte nur als Würgumher regelmäßig ein Script über meinen Pfad laufen lassen, der alle Umlaute ä -> a etc. verbiegt.

Ich weiß schon, warum ich mich auf Linux/Ubuntu beschränkt habe. Dieser Unix-Wildwuchs ist lästig, das wäre trotz meiner Abneigung in Windows besser, da läuft es dann gleich überall.

Äh, sicher? Windows (2k und neuer) nutzt UTF-16, nicht UTF-8. Und selbst das mußt du im Code umständlich ankündigen, zumindest bis Windows 8 konnte ein schlichtes fopen kein Unicode.