Pourquoi les «gros binaires» ne sont-ils pas plus largement utilisés pour les applications multiplateformes?

Pour autant que je sache, les soi-disant "gros binaires" - des fichiers exécutables qui contiennent du code machine pour plusieurs systèmes - ne sont vraiment utilisés que sur les PC Apple, et même là, il semble qu'ils ne les ont utilisés que parce qu'ils avaient besoin de passer de PowerPC à x86.

De nos jours, beaucoup de logiciels sont multiplates-formes, et il semble que créer un seul gros binaire serait à bien des égards plus simple que de garder une trace d'une douzaine de téléchargements différents pour chaque combinaison de système d'exploitation et d'architecture, sans parler de la transmission au client lequel il veut.

Je peux proposer de nombreuses suppositions pour expliquer pourquoi cette approche n'a jamais pris, par exemple:

• Un manque d'outils de compilation croisée rendant les binaires multi-OS irréalisables
• Vous devez quand même tester le code sur chaque système d'exploitation, vous devez donc déjà avoir des systèmes qui peuvent compiler en mode natif pour chaque système d'exploitation
• Apparemment, les programmes 32 bits "fonctionnent juste" sur les machines 64 bits déjà
• La liaison dynamique fonctionne différemment sur chaque système d'exploitation, donc une «bibliothèque de graisse» peut ne pas fonctionner même si une «application de graisse»

Mais comme je travaille toujours avec une bibliothèque ou un framework qui me cache tous ces détails spécifiques au système d'exploitation et à l'architecture, je ne sais pas à quel point tout cela est vrai, ou s'il y a encore plus de problèmes, je ne sais pas à propos. Alors, quelles sont les véritables raisons pour lesquelles les binaires fat ne sont généralement pas utilisés pour créer des logiciels multi-architecture et / ou multi-OS? (en dehors d'Apple)

Une approche binaire grasse est plus logique si:

1. Les deux architectures coexistent sur le même système
2. Tout le reste est plus ou moins le même pour toutes les architectures

C'est pourquoi ils ne sont pas utilisés pour le code multiplateforme (les deux critères ne s'appliquent pas), ou pour prendre en charge différentes distributions Linux avec un seul binaire (1. ne s'applique pas, 2. s'applique dans une certaine mesure).

Sous Linux, les deux critères s'appliqueraient toujours si vous souhaitez prendre en charge à la fois 32 et 64 bits sur une seule distribution Linux . Mais pourquoi s'embêter, si vous devez déjà supporter plusieurs distributions?

Sous Windows , la transition de 16 bits à 32 bits s'est produite initialement avec l'introduction de Windows NT, qui constituait une déviation majeure par rapport au monde Windows 16 bits à bien des égards (mémoire virtuelle, contrôle d'accès multi-utilisateurs, changements d'API ...). Avec tous ces changements, il valait mieux garder les mondes 32 et 16 bits séparés. NT avait déjà le concept de «sous-systèmes» prenant en charge différents «personae» d'OS (Win32, POSIX), donc faire de Win16 un troisième sous-système était un choix simple.

La transition de Win32 à Win64 n'a pas impliqué de changements majeurs similaires, mais Microsoft a quand même utilisé une approche similaire, probablement parce qu'elle a été éprouvée et essayée.

La logistique de répartition par âge d'Internet décourage les binaires gras de deux manières:

1. Le point de vente n'implique pas de biens physiques et favorise donc moins de références comme c'est le cas lorsque les produits se disputent l'espace de vente au détail et que les clients ont des possibilités limitées de faire un achat.

2. Les coûts de la bande passante favorisent la livraison du minimum de bits nécessaires pour un progiciel particulier. L'expédition d'un gros binaire dans le fil dégrade l'expérience client et l'efficacité de l'infrastructure du vendeur.

Les gros fichiers binaires avaient plus de sens lorsque le logiciel était emballé sous forme de support physique.

Une partie des raisons pour lesquelles les binaires fat n'ont pas réussi est qu'il y a plus que les spécifications ABI et processeur (en fait, le jeu d'instructions ) pour invalider un exécutable binaire. Un exécutable binaire dépend souvent beaucoup d'autres ressources, en particulier des bibliothèques dynamiques (voir l' enfer DLL ), des services externes (pensez aux SGBD comme PostGreSQL ....), de la configuration du système (par exemple l'emplacement des fichiers de configuration sous /etc/Linux), etc. . etc....

Juste pour Linux / x86-64, il est en pratique difficile de faire un exécutable binaire capable de s'exécuter sur toutes les distributions Linux (car il est souvent lié à des versions spécifiques de libcou de libstdc++). FatELF existe mais n'a pas beaucoup de succès.

Même avec un ABI et un jeu d'instructions bien définis, l'optimisation serait différente sur différentes marques de processeur - voir l' indicateur d' -mtune=native optimisation x86 de GCC .

Apple a réussi en partie à avoir des binaires gras uniquement parce qu'ils fournissent un écosystème très fermé de ressources informatiques.

Le logiciel libre est un autre moyen de résoudre votre problème de portabilité: si une application est un logiciel libre (soigneusement codé pour la portabilité), il est assez facilement porté sur des systèmes similaires. Et même si le code source d'origine ne fonctionne pas comme prévu sur votre système, vous pouvez l'adapter (ou payer quelqu'un pour faire le travail) généralement assez facilement (bien sûr, un logiciel gratuit lié à un système d'exploitation ou un ABI ou un processeur particulier n'est pas facile à port, vous paierez plus d'efforts pour cela). Et des normes comme POSIX ou Linux Standard Base aident également.

^{Vous pouvez payer (ou demander) à quelqu'un de porter un logiciel (gratuit) avec le code source disponible, mais il n'est pas réaliste de porter un exécutable binaire.}

Enfin, plusieurs frameworks existent pour faciliter le portage sur plusieurs systèmes d'exploitation (à condition que le code source soit disponible), par exemple Qt & POCO .

Même l'utilisation d'un bytecode bien spécifié comme la JVM n'est pas toujours une garantie de portabilité: certaines applications Java sont bien connues pour ne pas être portables (par exemple parce qu'elles attendent une hiérarchie de fichiers et des noms particuliers).

BTW, les systèmes informatiques sont probablement beaucoup moins hétérogènes aujourd'hui que dans les années 1980 ou au début des années 1990 (ou à l'ère du mainframe).

Enfin, les gros binaires sont gros: vous dépenserez beaucoup de ressources (temps de construction, bande passante, taille exécutable) pour un problème de portabilité qui pourrait ne pas concerner beaucoup de monde. Souvenez-vous de l'aphorisme: "il n'y a pas de logiciel portable, seulement un logiciel qui a été porté" (sur certains systèmes particuliers).