Was macht OSX-Programme unter Linux nicht lauffähig?

Ich weiß, dass es viele Unterschiede zwischen OSX und Linux gibt, aber was unterscheidet sie so sehr, dass sie grundsätzlich inkompatibel sind?

Das ganze ABI ist anders, nicht nur das Binärformat (Mach-O versus ELF) wie in sepp2k erwähnt.

Während zum Beispiel sowohl Linux als auch Darwin / XNU (der Kernel von OS X) scauf PowerPC und int 0x80/ sysenter/ syscallauf x86 für den Syscall-Einstieg verwenden, gibt es von da an nicht mehr viel Gemeinsamkeiten.

Darwin leitet negative Syscall-Nummern an den Mach-Mikrokern und positive Syscall-Nummern an den monolithischen BSD-Kern - siehe xnu / osfmk / mach / syscall_sw.h und xnu / bsd / kern / syscalls.master . Die Syscall-Nummern von Linux variieren je nach Architektur - siehe linux / arch / powerpc / include / asm / unistd.h , linux / arch / x86 / include / asm / unistd_32.h und linux / arch / x86 / include / asm / unistd_64.h - aber sind alle nicht negativ. Es ist also offensichtlich, dass Syscall-Nummern, Syscall-Argumente und sogar welche Syscalls existieren, unterschiedlich sind.

Die Standard-C-Laufzeitbibliotheken unterscheiden sich ebenfalls. Darwin erbt meistens FreeBSDs libc, während Linux normalerweise glibc verwendet (aber es gibt Alternativen wie eglibc und dietlibc und uclibc und Bionic).

Ganz zu schweigen davon, dass der gesamte Grafikstapel anders ist. Wenn die gesamten Cocoa Objective-C-Bibliotheken ignoriert werden, kommunizieren GUI-Programme unter OS X über Mach-Ports mit WindowServer, während GUI-Programme unter Linux in der Regel über UNIX-Domänensockets mit dem X11-Protokoll mit dem X-Server kommunizieren. Natürlich gibt es Ausnahmen; Sie können X unter Darwin ausführen und X unter Linux umgehen, aber OS X-Anwendungen sprechen definitiv nicht X.

Wie Wein, wenn jemand die Arbeit hineingesteckt hat

• Implementierung eines Binärladers für Mach-O
• Überfüllen Sie jeden XNU-Systemaufruf und konvertieren Sie ihn in entsprechende Linux-Systemaufrufe
• Schreiben von Ersatz für OS X-Bibliotheken wie CoreFoundation nach Bedarf
• Schreiben von Ersatz für OS X-Dienste wie WindowServer nach Bedarf

Dann könnte es möglich sein, ein OS X-Programm "nativ" unter Linux auszuführen. Vor Jahren hat Kyle Moffet an dem ersten Element gearbeitet und einen Prototypen für binfmt_mach-o für Linux erstellt, der jedoch nie fertiggestellt wurde, und ich kenne keine anderen ähnlichen Projekte.

(Theoretisch ist dies durchaus möglich, und ähnliche Anstrengungen wurden viele Male unternommen. Zusätzlich zu Wine unterstützt Linux die Ausführung von Binärdateien unter anderen UNIX-Betriebssystemen wie HP-UX und Tru64, und das Glendix- Projekt zielt darauf ab, die Kompatibilität mit Plan 9 zu verbessern Linux.)

Jemand hat sich die Mühe gemacht, einen Mach-O-Binärlader und einen API-Übersetzer für Linux zu implementieren!

shinh / maloader - GitHub verwendet den Wine-ähnlichen Ansatz, die Binärdatei zu laden und alle Bibliotheksaufrufe im Userspace abzufangen / zu übersetzen. Es ignoriert Syscalls und alle grafischen Bibliotheken vollständig, reicht jedoch aus, um viele Konsolenprogramme zum Laufen zu bringen.

Darling baut auf Maloader auf und fügt Bibliotheken und andere unterstützende Laufzeitbits hinzu.

Warum OSX-Anwendungen nicht nativ unter Linux laufen:

Zunächst verwendet OSX ein anderes Binärformat als Linux, sodass Linux keine für OSX kompilierten Binärdateien ausführen kann (genauso wie es keine für Windows oder BSD kompilierten Binärdateien ausführen kann).

Zweitens, wenn Sie über GUI-Anwendungen sprechen, ist Apples GUI-Toolkit Cocoa a) nur für OSX verfügbar und b) läuft nicht auf X11.

Warum gibt es kein Weinäquivalent für OSX-Anwendungen:

Es musste viel Arbeit geleistet werden, bevor der Wein überhaupt halbwegs brauchbar war. Da ein OSX-Äquivalent nicht so gefragt ist, hat noch niemand den gleichen Aufwand in ein solches Projekt gesteckt.

Der wichtigste Grund, warum OS X-Apps unter Linux nicht ausgeführt werden, ist, dass diese Betriebssysteme unterschiedliche Systemaufrufe verwendeten.

Einige frühere Antworten erwähnten Bibliotheken, aber das ist im Allgemeinen nicht der Fall - Core Foundation wird von Apple unter dem Namen CFLite zum größten Teil als Open-Source-Lösung angeboten und ist problemlos auf jede Plattform übertragbar (die Windows-Version von iTunes befindet sich tatsächlich auf einem Windows-Port von Core Foundation und mit Bei einigen Compiler-Optimierungen können Sie CFLite direkt mit clang auf einer Linux-Distribution erstellen. Außerdem gibt es Open-Source-Bemühungen, Objective-C-Umgebungen zu portieren, hauptsächlich Foundation und AppKit auf Linux, insbesondere GNUstep, eine GNU-Implementierung von OpenStep früher als Apple's Cocoa (begann, als es noch die Firma NeXT Computer gab.)

Wenn jemand bestimmt ist, kann er einen Loader entwerfen, der jeden Mach-O-Systemaufruf aufzeichnet und in den entsprechenden Linux-Systemaufruf übersetzt sowie diese Open-Source-Bibliothek "Gegenstücke" dynamisch mit der Binärdatei mit entsprechender ABI-Übersetzung verknüpft.

Und nur zu Ihrer Information, wenn Sie den Quellcode der Mach-O-Anwendung erhalten können, können Sie eine Portierung in Betracht ziehen, und es kann sich als sehr einfach herausstellen. Zum Beispiel kann die mit OS X 10.6 gelieferte TextEdit-App nach dem Entfernen einiger Zeilen (nicht kritischer) CF-Code direkt für die Verknüpfung mit GNUstep neu kompiliert werden und ist somit sofort unter Linux verfügbar (ganz zu schweigen von dem mit GNUstep gelieferten TextEdit) direktes Neukompilieren der TextEdit-App von NeXTSTEP, dem Vorläufer von OS X, auch unter Beibehaltung des Labels "© 1995 NeXT". TextEdit steht unter der BSD-Lizenz.

Am 8. Dezember 2012 wurde ein neues Projekt gestartet - Darling.

http://www.darlinghq.org/