¿Por qué los "binarios gordos" no se usan más ampliamente para aplicaciones multiplataforma?

Hasta donde yo sé, los llamados "binarios gordos", archivos ejecutables que contienen código de máquina para múltiples sistemas, solo se usan realmente en las PC de Apple, e incluso allí parece que solo los usaron porque necesitaban hacer la transición de PowerPC a x86.

En la actualidad, una gran cantidad de software es multiplataforma, y ​​parece que hacer un solo binario gordo sería, en muchos sentidos, más simple que realizar un seguimiento de una docena de descargas diferentes para cada combinación de sistema operativo y arquitectura, sin mencionar que de alguna manera se transmite al cliente cuál quieren.

Puedo llegar a muchas conjeturas sobre por qué este enfoque nunca se dio cuenta, por ejemplo:

• La falta de herramientas de compilación cruzada hace que los binarios de múltiples sistemas operativos
• De todos modos, debe probar el código en cada sistema operativo, por lo que ya debe tener sistemas que puedan compilarse de forma nativa para cada sistema operativo
• Aparentemente, los programas de 32 bits ya "funcionan" en máquinas de 64 bits
• La vinculación dinámica funciona de manera diferente en cada sistema operativo, por lo que una "biblioteca fat" podría no funcionar incluso si una "aplicación fat"

Pero como siempre trabajo con una biblioteca o marco que oculta todos estos detalles específicos del sistema operativo y de la arquitectura, no sé cuán cierto es realmente eso, o si hay más problemas que no sé acerca de. Entonces, ¿cuáles son las razones reales por las que los binarios gordos generalmente no se usan para crear software de arquitectura múltiple y / o sistema operativo múltiple? (fuera de Apple)

Un enfoque binario gordo tiene más sentido si:

1. Ambas arquitecturas coexisten en el mismo sistema.
2. Todo lo demás es más o menos igual para todas las arquitecturas.

Es por eso que no se usan para código multiplataforma (ambos criterios no se aplican), o para admitir diferentes distribuciones de Linux con un binario (1. no se aplica, 2. se aplica en cierto grado).

En Linux, ambos criterios se seguirían aplicando si desea admitir 32 y 64 bits en una única distribución de Linux . ¿Pero por qué molestarse, si ya tiene que soportar distribuciones múltiples?

En Windows , la transición de 16 bits a 32 bits se produjo inicialmente con la introducción de Windows NT, que fue una desviación importante del mundo de Windows de 16 bits en muchos aspectos (memoria virtual, control de acceso multiusuario, cambios de API ...). Con todos estos cambios, era mejor mantener separados los mundos de 32 y 16 bits. NT ya tenía el concepto de "subsistemas" compatibles con diferentes "personajes" del sistema operativo (Win32, POSIX), por lo que convertir a Win16 en un tercer subsistema fue una elección sencilla.

La transición de Win32 a Win64 no involucró cambios importantes similares, pero Microsoft usó un enfoque similar de todos modos, probablemente porque fue probado y probado.

La logística de distribución de edad en Internet desincentiva los binarios gordos de dos maneras:

1. El punto de venta no involucra bienes físicos y, por lo tanto, favorece menos SKU, como es el caso cuando los productos compiten por el espacio de venta minorista y los clientes tienen oportunidades limitadas para realizar una compra.

2. Los costos del ancho de banda favorecen la entrega de los bits mínimos necesarios para un paquete de software en particular. Enviar un binario gordo por el cable degrada tanto la experiencia del cliente como la eficiencia de la infraestructura del vendedor.

Los binarios gordos tenían más sentido cuando el software era un medio físico envuelto por contracción.

Parte de las razones por las cuales los binarios gordos no tuvieron éxito es que hay más que las especificaciones ABI y procesador (en realidad, conjunto de instrucciones ) para invalidar un ejecutable binario. Un ejecutable binario a menudo depende mucho de otros recursos, en particular bibliotecas dinámicas (vea el infierno de DLL ), servicios externos (piense en DBMS como PostGreSQL ...), configuración del sistema (por ejemplo, ubicación de archivos de configuración /etc/en Linux), etc. etc ...

Solo para Linux / x86-64, en la práctica es difícil hacer que un ejecutable binario pueda ejecutarse en todas las distribuciones de Linux (porque a menudo está vinculado a versiones específicas de libco de libstdc++). FatELF existe pero no tiene mucho éxito.

Incluso con un ABI bien definido y un conjunto de instrucciones, la optimización sería diferente en varias marcas de procesadores; vea el indicador de -mtune=native optimización x86 de GCC .

Apple logró en parte tener binarios gordos solo porque proporcionan un ecosistema muy cerrado de recursos informáticos.

El software libre es otra forma de resolver su problema de portabilidad: si una aplicación es software libre (cuidadosamente codificado para portabilidad), es bastante fácil de transportar a sistemas similares. E incluso si el código fuente original no funciona según lo previsto en su sistema, puede adaptarlo (o pagarle a alguien para que haga el trabajo) por lo general de manera razonablemente fácil (por supuesto, el software gratuito vinculado a un SO o ABI o procesador en particular no es fácil de usar). puerto, pagarás más esfuerzos por eso). Y estándares como POSIX o Linux Standard Base también ayudan.

^{Puede pagar (o pedirle) a alguien que transfiera algún software (gratuito) con el código fuente disponible, pero no es realista portar un ejecutable binario.}

Por último, existen varios marcos para ayudar a portar en varios sistemas operativos (siempre que el código fuente esté disponible), por ejemplo, Qt y POCO .

Incluso usando un bytecode bien especificado como JVM no siempre es una garantía de portabilidad: se sabe que algunas aplicaciones Java no son portables (por ejemplo, porque esperan alguna jerarquía y denominación de archivos en particular).

Por cierto, los sistemas informáticos son probablemente mucho menos heterogéneos hoy que en los años ochenta o principios de los noventa (o en la era del mainframe).

Por último, los binarios gordos son gordos: gastará una gran cantidad de recursos (tiempo de construcción, ancho de banda, tamaño ejecutable) para un problema de portabilidad que podría no afectar a muchas personas. Recuerde el aforismo: "no hay software portátil, solo software que ha sido portado" (a algunos sistemas particulares).