Até onde eu sei, os chamados "binários gordos" - arquivos executáveis que contêm código de máquina para vários sistemas - são realmente usados apenas em Apple PCs, e mesmo lá parece que eles só foram usados porque precisavam fazer a transição de PowerPC para x86.
Atualmente, muitos softwares são multiplataforma e parece que criar um único binário gordo seria, de muitas maneiras, mais simples do que acompanhar uma dúzia de downloads diferentes para cada combinação de sistema operacional e arquitetura, sem mencionar de alguma forma o transporte para o cliente qual deles eles querem.
Posso sugerir muitas suposições sobre por que essa abordagem nunca pegou, por exemplo:
- Falta de ferramentas de compilação cruzada inviabilizando binários multi-OS
- Você precisa testar o código em cada sistema operacional de qualquer maneira, para que você já precise ter sistemas que possam compilar nativamente para cada sistema operacional
- Aparentemente, programas de 32 bits "simplesmente funcionam" em máquinas de 64 bits já
- A vinculação dinâmica funciona de maneira diferente em cada sistema operacional; portanto, uma "biblioteca de gordura" pode não funcionar, mesmo que um "aplicativo de gordura" funcione
Mas como eu sempre trabalho com uma biblioteca ou estrutura que esconde todos esses detalhes específicos de SO e de arquitetura, não sei o quanto isso é verdade ou se há ainda mais problemas que não conheço. sobre. Então, quais são as razões reais pelas quais os binários gordos geralmente não são usados para criar software de arquitetura múltipla e / ou multi-SO? (fora da Apple)
Respostas:
Uma abordagem binária gorda faz mais sentido se:
É por isso que eles não são usados para código de plataforma cruzada (ambos os critérios não se aplicam) ou para oferecer suporte a diferentes distribuições Linux com um binário (1. não se aplica, 2. se aplica a um certo grau).
No Linux, os dois critérios ainda se aplicam se você deseja suportar 32 e 64 bits em uma única distribuição Linux . Mas por que se preocupar, se você já tem que suportar várias distribuições?
No Windows , a transição de 16 bits para 32 bits ocorreu inicialmente com a introdução do Windows NT, que foi o principal desvio do mundo Windows de 16 bits em muitos aspectos (memória virtual, controle de acesso multiusuário, alterações de API ...). Com todas essas mudanças, era melhor manter os mundos de 32 e 16 bits separados. O NT já tinha o conceito de "subsistemas" com suporte a diferentes "personae" de SO (Win32, POSIX), portanto, tornar o Win16 um terceiro subsistema foi uma escolha direta.
A transição do Win32 para o Win64 não envolveu grandes mudanças semelhantes, mas a Microsoft usou uma abordagem semelhante de qualquer maneira, provavelmente porque foi comprovada e experimentada.
fonte
A logística de distribuição da era da Internet desincentiva os binários de gordura de duas maneiras:
O ponto de venda não envolve bens físicos e, portanto, favorece menos SKUs, como é o caso quando os produtos competem pelo espaço de prateleira do varejo e os clientes têm poucas oportunidades de fazer uma compra.
Os custos da largura de banda favorecem o fornecimento apenas dos bits mínimos necessários para um pacote de software específico. O envio de um binário gordo diminui a experiência do cliente e a eficiência da infraestrutura do vendedor.
Binários gordos faziam mais sentido quando o software era encolhido em mídia física.
fonte
Parte das razões pelas quais os binários gordos não foram bem-sucedidos é que existem mais do que as especificações da ABI e do processador (na verdade, conjunto de instruções ) para invalidar um executável binário. Um executável binário geralmente depende muito de outros recursos, em particular bibliotecas dinâmicas (consulte o inferno da DLL ), serviços externos (pense em DBMS como PostGreSQL ....), configuração do sistema (por exemplo, localização dos arquivos de configuração
/etc/no Linux), etc. etc ...Apenas para Linux / x86-64, na prática, é difícil tornar um executável binário capaz de executar em todas as distribuições Linux (porque geralmente está vinculado a versões específicas de
libcou delibstdc++). O FatELF existe, mas não é muito bem sucedido.Mesmo com um conjunto de instruções e ABI bem definido, a otimização seria diferente em várias marcas de processadores - consulte o sinalizador de
-mtune=nativeotimização x86 do GCC .A Apple conseguiu em parte ter binários gordos apenas porque eles fornecem um ecossistema muito fechado de recursos de computação.
O software livre é outra maneira de solucionar sua preocupação com portabilidade: se um aplicativo é um software livre (cuidadosamente codificado para portabilidade), é facilmente portado para sistemas similares. E mesmo que o código-fonte original não funcione conforme o planejado em seu sistema, você pode adaptá-lo (ou pagar alguém para fazer o trabalho) normalmente com bastante facilidade (é claro, o software livre vinculado a um SO ou ABI ou processador específico não é fácil de porta, você pagará mais esforços por isso). E padrões como POSIX ou Linux Standard Base também ajudam.
Você pode pagar (ou pedir) a alguém para portar algum software (gratuito) com o código-fonte disponível, mas não é realista portar um executável binário.
Por fim, existem várias estruturas para ajudar a transportar em vários sistemas operacionais (desde que o código fonte esteja disponível), por exemplo, Qt & POCO .
Mesmo o uso de um código de código bem especificado como a JVM nem sempre é uma garantia de portabilidade: sabe-se que alguns aplicativos Java não são portáveis (por exemplo, porque esperam alguma hierarquia e nomeação de arquivos em particular).
Atualmente, os sistemas de computador são provavelmente muito menos heterogêneos hoje do que nos anos 80 ou no começo dos anos 90 (ou na era do mainframe).
Por fim, os binários gordos são gordos: você gastará muitos recursos (tempo de construção, largura de banda, tamanho do executável) para um problema de portabilidade que pode não interessar a muitas pessoas. Lembre-se do aforismo: "não existe software portátil, apenas software portado" (para alguns sistemas em particular).
fonte