Por que os “binários gordos” não são mais amplamente utilizados para aplicativos de plataforma cruzada?


27

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)


5
Existe um problema sério que isso resolveria? Quando vou à página de download dos principais aplicativos de plataforma cruzada, eles detectam automaticamente o sistema operacional que estou usando e me apontam na direção certa. Usuários do Linux têm gerenciadores de pacotes. Parece-me que tudo isso faria é inchar os tamanhos de download.
Doval

4
Não sei muito sobre binários gordos, mas eles não precisam de suporte do sistema operacional (especificamente do carregador)? Então não vejo o apelo por "software multi-OS" especificamente, pois não há como os fornecedores de SO concordarem com um formato interoperável.

7
Porque temos código de bytes e máquinas virtuais que resolvem melhor esse problema.
21415 Robert Hvey

2
Me faz pensar, é possível criar um arquivo executável poliglota que funcione no Windows e em alguns * NIX?
Aaaaaaaaaaaa 01/03

2
Para o registro histórico, os binários gordos datam da transição 68k -> PPC, não da transição PPC -> x86.
Mark

Respostas:


9

Uma abordagem binária gorda faz mais sentido se:

  1. Ambas as arquiteturas coexistem no mesmo sistema
  2. Tudo o resto é mais ou menos o mesmo para todas as arquiteturas

É 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.


11

A logística de distribuição da era da Internet desincentiva os binários de gordura de duas maneiras:

  1. 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.

  2. 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.


1
Para implantações de software, o custo da largura de banda é quase inconseqüente hoje em dia. Se ainda houver um problema, aguarde mais 5 minutos.
Robert Harvey

2
@ RobertHarvey, mas esses são 5 minutos, eu prefiro não esperar.
Arturo Torres Sánchez

2

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 de libstdc++). 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=native otimizaçã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).


4
Eu discuto a noção de que tornar o software "gratuito" também o torna facilmente portátil.
Robert Harvey

3
Ele não torna o software portátil, mas permite que alguém gaste esforços para transportá-lo para outra plataforma (o que você não pode fazer realisticamente se não tiver acesso e direito de modificar o código-fonte)
Basile Starynkevitch

2
@RobertHarvey, pode não haver um vínculo fundamental em princípio, mas há várias razões inteiramente pragmáticas pelas quais o Software Livre se espalhou amplamente por tantas plataformas e criou tantas ferramentas de construção entre plataformas e cadeias de ferramentas.
itsbruce

Um aplicativo de código fechado que depende inteiramente de estruturas e bibliotecas portáteis de código aberto será um pouco mais fácil de portar para outras plataformas pelo proprietário do aplicativo de código fechado. Digo isso pela minha experiência em primeira mão de felicidade depois de descobrir que "codificar no estilo OpenCV" é tudo o que você precisa (para necessidades de processamento de imagem). É claro que a GUI ainda requer outras estruturas, como Qt, etc. (embora eu não tenha experiência em primeira mão disso).
rwong

4
@RobertHarvey Isso não acontece. Software livre que é uma bagunça absoluta para portar ainda uma bagunça absoluta para portar - você apenas aumenta a superfície em que pode encontrar alguém que se preocupe em usá-lo em uma arquitetura ou sistema operacional específico o suficiente para portá-lo, ou sugere um caminho que possa faça portar algo que não faça as pessoas sangrarem.
Tim Post
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.