Perché i "binari grassi" non sono più utilizzati per le applicazioni multipiattaforma?

Un fat binario ha più senso se:

1. Entrambe le architetture coesistono sullo stesso sistema
2. Tutto il resto è più o meno lo stesso per tutte le architetture

Ecco perché non vengono utilizzati per il codice multipiattaforma (entrambi i criteri non si applicano) o per supportare diverse distribuzioni Linux con un solo binario (1. doesn 'applicare, 2. si applica ad un certo livello).

Su Linux, entrambi i criteri sarebbero ancora validi se si desidera supportare sia 32 e 64 bit su una singola distribuzione Linux . Ma perché preoccuparsi, se devi già supportare più distribuzioni?

On Windows , la transizione da 16 bit a 32 bit è avvenuta inizialmente con l'introduzione di Windows NT, che era una deviazione maggiore dal mondo Windows a 16 bit per molti aspetti (memoria virtuale, multiutente controllo accessi, modifiche API ...). Con tutti questi cambiamenti, era meglio tenere separati i mondi a 32 e 16 bit. NT aveva già il concetto di "sottosistemi" che supporta diversi OS "personae" (Win32, POSIX), quindi rendere Win16 un terzo sottosistema era una scelta semplice.

La transizione da Win32 a Win64 non ha comportato modifiche importanti simili, ma Microsoft ha comunque utilizzato un approccio simile, probabilmente perché è stato provato e provato.

La logistica della distribuzione in Internet per età disincentua i file binari grassi in due modi:

1. Il punto vendita non coinvolge beni fisici e quindi preferisce meno SKU, come nel caso in cui i prodotti competono per lo spazio di vendita al dettaglio e i clienti hanno possibilità limitate di effettuare un acquisto.

2. I costi dei favori dell'ampiezza di banda che forniscono solo i bit minimi necessari per un particolare pacchetto software. La spedizione di un file binario lungo il cavo riduce l'esperienza del cliente e l'efficienza dell'infrastruttura del venditore.

I binari grassi avevano più senso quando il software era un supporto fisico ristretto.

Parte dei motivi per cui i file binari grassi non hanno avuto successo è che c'è più della ABI & processore (in realtà, set di istruzioni ) specifiche per invalidare un eseguibile binario. Un eseguibile binario spesso dipende molto da altre risorse, in particolare librerie dinamiche (vedi DLL inferno ), servizi esterni (pensa a DBMS come PostGreSQL ... .), configurazione del sistema (ad es. posizione dei file di configurazione in /etc/ su Linux), ecc. ecc ....

Solo per Linux / x86-64 è in pratica difficile rendere un eseguibile binario in grado di girare su tutte le distribuzioni Linux (perché è spesso legato a versioni specifiche di libc o di libstdc++ ). FatELF esiste ma non ha molto successo.

Anche con un ABI ben definito e un set di istruzioni, l'ottimizzazione sarebbe diversa su varie marche di processori - vedi il -mtune=native ottimizzazione x86 flag di GCC .

Apple è riuscita in parte a disporre di file binari grassi solo perché forniscono un ecosistema molto chiuso di risorse informatiche.

Il software gratuito è un altro modo per risolvere il tuo problema di portabilità: se un'applicazione è un software gratuito (accuratamente codificato per la portabilità) , è abbastanza facilmente trasferito su sistemi simili. E anche se il codice sorgente originale non funziona come previsto sul tuo sistema, potresti adattarlo (o pagare qualcuno per fare il lavoro) in genere abbastanza facilmente (ovviamente, il software libero legato a particolari SO o ABI o al processore non è facile porto, pagherai più sforzi per quello). E standard come POSIX o Linux Standard Base aiuta anche.

^{Potresti pagare (o chiedere) a qualcuno di portare un qualche software (gratuito) con il codice sorgente disponibile, ma non è realistico portare un eseguibile binario.}

Finalmente esistono diversi framework che aiutano il porting su diversi sistemi operativi (il codice sorgente disponibile è disponibile), ad es. Qt & POCO .

Anche l'uso di un bytecode ben specificato come JVM non è sempre una garanzia di portabilità: alcune applicazioni Java sono ben note non essere portabile (ad es. perché si aspettano particolari gerarchie e nomi di file).

A proposito, i sistemi informatici sono probabilmente molto meno eterogenei oggi rispetto agli anni '80 o all'inizio degli anni '90 (o nell'era del mainframe).

Infine, i file binari grassi sono grassi: spenderai molte risorse (tempo di costruzione, larghezza di banda, dimensioni dell'eseguibile) per un problema di portabilità che potrebbe non riguardare molte persone. Ricorda l'aforisma: "non c'è software portatile, solo software che è stato trasferito" (ad alcuni sistemi particolari).