¿Qué hace que los programas OSX no sean ejecutables en Linux?

Sé que hay muchas diferencias entre OSX y Linux, pero ¿qué los hace tan totalmente diferentes, que los hace fundamentalmente incompatibles?

Todo el ABI es diferente, no solo el formato binario (Mach-O versus ELF) como sepp2k mencionó.

Por ejemplo, si bien Linux y Darwin / XNU (el núcleo de OS X) usan scPowerPC y int 0x80/ sysenter/ syscallen x86 para la entrada de syscall, no hay mucho más en común a partir de ahí.

Darwin dirige los números negativos de syscall en el microkernel Mach y los números positivos de syscall en el kernel monolítico BSD: consulte xnu / osfmk / mach / syscall_sw.h y xnu / bsd / kern / syscalls.master . Los números de syscall de Linux varían según la arquitectura: consulte linux / arch / powerpc / include / asm / unistd.h , linux / arch / x86 / include / asm / unistd_32.h y linux / arch / x86 / include / asm / unistd_64.h - pero todos son no negativos. Entonces, obviamente, los números de syscall, los argumentos de syscall e incluso qué syscall existen son diferentes.

Las bibliotecas de tiempo de ejecución estándar de C también son diferentes; Darwin hereda principalmente la libc de FreeBSD, mientras que Linux generalmente usa glibc (pero hay alternativas, como eglibc y dietlibc y uclibc y Bionic).

Sin mencionar que toda la pila de gráficos es diferente; ignorando todas las bibliotecas de Cocoa Objective-C, los programas GUI en OS X hablan con WindowServer a través de puertos Mach, mientras que en Linux, los programas GUI generalmente hablan con el servidor X a través de sockets de dominio UNIX utilizando el protocolo X11. Por supuesto que hay excepciones; puede ejecutar X en Darwin, y puede omitir X en Linux, pero las aplicaciones OS X definitivamente no hablan X.

Como el vino, si alguien pone el trabajo en

• implementar un cargador binario para Mach-O
• atrapar cada llamada al sistema XNU y convertirla en llamadas al sistema Linux apropiadas
• escribir reemplazos para bibliotecas OS X como CoreFoundation según sea necesario
• escribir reemplazos para servicios de OS X como WindowServer según sea necesario

entonces podría ser posible ejecutar un programa OS X "nativamente" en Linux. Hace años, Kyle Moffet trabajó en el primer elemento, creando un prototipo binfmt_mach-o para Linux, pero nunca se completó, y no conozco otros proyectos similares.

(En teoría, esto es bastante posible, y se han hecho esfuerzos similares muchas veces; además de Wine, Linux tiene soporte para ejecutar binarios de otros UNIX como HP-UX y Tru64, y el proyecto Glendix tiene como objetivo llevar la compatibilidad del Plan 9 a Linux.)

¡Alguien se ha esforzado por implementar un cargador binario Mach-O y un traductor API para Linux!

shinh / maloader: GitHub adopta el enfoque tipo Wine de cargar el binario y capturar / traducir todas las llamadas de la biblioteca en el espacio de usuario. Ignora por completo las llamadas al sistema y todas las bibliotecas relacionadas con gráficos, pero es suficiente para que funcionen muchos programas de consola.

Darling se basa en el maloader, agregando bibliotecas y otros bits de tiempo de ejecución compatibles.

Por qué las aplicaciones OSX no se ejecutarán de forma nativa en Linux:

En primer lugar, OSX usa un formato binario diferente que Linux, por lo que Linux no puede ejecutar archivos binarios compilados para OSX (de la misma manera que no puede ejecutar archivos binarios compilados para Windows o BSD).

En segundo lugar, si habla de aplicaciones GUI, el kit de herramientas GUI de Apple Cocoa a) solo está disponible para OSX yb) no se ejecuta sobre X11.

Por qué no hay equivalente de wine para aplicaciones OSX:

Había que hacer mucho trabajo antes de que el vino fuera utilizable hasta la mitad. Como no hay tanta demanda de un equivalente de OSX, nadie ha invertido la misma cantidad de esfuerzo en dicho proyecto todavía.

La razón más importante por la que las aplicaciones OS X no se ejecutarán en Linux es porque esos sistemas operativos utilizaron diferentes llamadas al sistema.

Algunas respuestas anteriores mencionaron bibliotecas, pero ese no es generalmente el caso: Core Foundation es en gran parte de código abierto por Apple con el nombre CFLite y es fácilmente portátil para cualquier plataforma (la versión de Windows de iTunes en realidad se encuentra encima de un puerto de Windows de Core Foundation, y con algunos ajustes del compilador, puede hacer CFLite directamente usando clang en una distribución de Linux) y también hay esfuerzos de código abierto para portar el entorno Objective-C, principalmente Foundation y AppKit a Linux, especialmente GNUstep, una implementación GNU de OpenStep, que data anterior a Apple's Cocoa (comenzó cuando todavía existía la empresa NeXT Computer).

Si alguien está determinado, pueden diseñar un cargador que capturará cada llamada al sistema de Mach-O y la traducirá a la llamada al sistema Linux correspondiente, así como también vincular dinámicamente esas "contrapartes" de la biblioteca de código abierto al binario con la traducción ABI adecuada.

Y solo para su información, si puede obtener el código fuente de la aplicación Mach-O, puede considerar portarlo y puede resultar muy simple. Como ejemplo, la aplicación TextEdit incluida con OS X 10.6 puede recompilarse directamente con GNUstep después de quitar algunas líneas de código CF (no crítico) y, por lo tanto, inmediatamente disponible en Linux (sin mencionar que TextEdit enviado con GNUstep era en realidad un recompilación directa de la aplicación TextEdit de NeXTSTEP, el precursor de OS X también, incluso conservando su etiqueta "© 1995 NeXT"). TextEdit está bajo licencia BSD.

El 8 de diciembre de 2012 se lanzó un nuevo proyecto: Darling.

http://www.darlinghq.org/