Perché i "binari fat" non sono più ampiamente utilizzati per applicazioni multipiattaforma?

Per quanto ne so, i cosiddetti "fat binaries" - file eseguibili che contengono codice macchina per più sistemi - sono realmente utilizzati solo su PC Apple, e anche lì sembra che li abbiano usati solo perché dovevano passare da Da PowerPC a x86.

Oggigiorno molti software sono multipiattaforma e sembra che creare un singolo binario fat sarebbe in molti modi più semplice che tenere traccia di una dozzina di download diversi per ogni combinazione di sistema operativo e architettura, per non parlare del modo in cui ve ne sono al cliente quale desidera.

Posso fare molte ipotesi sul perché questo approccio non abbia mai preso piede, ad esempio:

• Mancanza di strumenti di compilazione incrociata che rendono impossibili i binari multi-OS
• È comunque necessario testare il codice su ciascun sistema operativo, quindi è già necessario disporre di sistemi in grado di compilare in modo nativo per ciascun sistema operativo
• Apparentemente i programmi a 32 bit "funzionano già" su macchine a 64 bit
• Il collegamento dinamico funziona in modo diverso su ciascun sistema operativo, quindi una "libreria fat" potrebbe non funzionare anche se una "applicazione fat" funzionerebbe

Ma poiché lavoro sempre con una libreria o un framework che nasconde tutti questi dettagli specifici del sistema operativo e specifici dell'architettura, non so quanto sia vero tutto ciò, o se ci sono ancora più problemi che non conosco di. Quindi, quali sono le ragioni reali per cui i binari fat non sono generalmente utilizzati per creare software multi-architettura e / o multi-OS? (fuori da Apple)

Un approccio binario grasso 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. non si applica, 2. si applica in una certa misura).

Su Linux, entrambi i criteri verrebbero comunque applicati se si desidera supportare sia 32 che 64 bit su una singola distribuzione Linux . Ma perché preoccuparsi, se devi già supportare più distribuzioni?

Su Windows , la transizione da 16 bit a 32 bit è avvenuta inizialmente con l'introduzione di Windows NT, che per molti aspetti ha rappresentato una grande deviazione dal mondo Windows a 16 bit (memoria virtuale, controllo di accesso multiutente, modifiche API ...). Con tutti questi cambiamenti, era meglio tenere separati i mondi a 32 e 16 bit. NT aveva già il concetto di "sottosistemi" in grado di supportare diversi "personaggi" del sistema operativo (Win32, POSIX), quindi rendere Win16 un terzo sottosistema era una scelta semplice.

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

La logistica della distribuzione dell'età di Internet disincentiva i binari dei grassi in due modi:

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

2. I costi della larghezza di banda favoriscono la consegna dei bit minimi necessari per un determinato pacchetto software. Spedire un grosso binario lungo il filo degrada sia l'esperienza del cliente sia l'efficienza dell'infrastruttura del venditore.

I binari grassi avevano più senso quando il software veniva ridotto con supporti fisici.

Parte dei motivi per cui i binari fat non sono riusciti è che ci sono più delle specifiche ABI e del processore (in realtà, set di istruzioni ) per invalidare un eseguibile binario. Un eseguibile binario spesso dipende molto da altre risorse, in particolare librerie dinamiche (vedi l' inferno DLL ), servizi esterni (pensate a DBMS come PostGreSQL ....), configurazione del sistema (ad es. Posizione dei file di configurazione /etc/su Linux), ecc. . eccetera....

Solo per Linux / x86-64 è in pratica difficile rendere un eseguibile binario in grado di funzionare su tutte le distribuzioni Linux (perché è spesso legato a versioni specifiche di libco 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 vari marchi di processori - vedi il flag di -mtune=native ottimizzazione x86 di GCC .

Apple è riuscita in parte ad avere fat binaries solo perché forniscono un ecosistema molto chiuso di risorse informatiche.

Il software libero è un altro modo per risolvere il problema della portabilità: se un'applicazione è un software libero (codificato con cura per la portabilità), può essere 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) di solito abbastanza facilmente (ovviamente, software libero legato a un particolare sistema operativo o ABI o processore non è facile da porto, pagherai più sforzi per quello). E anche standard come POSIX o Linux Standard Base aiutano.

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

Finalmente esistono diversi framework per aiutare il porting su diversi sistemi operativi (a condizione che sia disponibile il codice sorgente), ad esempio Qt e POCO .

Anche l'utilizzo di un bytecode ben specificato come JVM non è sempre una garanzia di portabilità: alcune applicazioni Java sono ben note per non essere portatili (ad esempio perché si aspettano una particolare gerarchia e denominazione dei 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).

Alla fine, i file binari fat sono fat: spenderai molte risorse (tempo di costruzione, larghezza di banda, dimensioni eseguibili) per un problema di portabilità che potrebbe non riguardare molte persone. Ricorda l'aforisma: "non esiste un software portatile, solo un software che è stato portato" (su alcuni sistemi particolari).