Os arquivos de instalação como .deb contêm instruções de máquina para cada arquitetura suportada?

Question

Com base no meu humilde entendimento dos componentes internos do computador, se você compilar um programa C para uma arquitetura de conjunto de instruções específica, o executável resultante será o mesmo para qualquer sistema operacional, com exceção das chamadas do sistema.

Por outro lado, executáveis para diferentes arquiteturas de conjuntos de instruções são completamente diferentes.

Por que, então, quando você quer fazer o download de um programa para a Internet, geralmente é apresentado a você escolhas baseadas no seu SO, em vez de na arquitetura do conjunto de instruções?

Além disso, como existem muitas arquiteturas de conjunto de instruções, não consigo imaginar como é um instalador. Por exemplo, se um instalador suporta 20 arquiteturas diferentes, 95% dos dados são descartados durante a instalação?

    

Answer 1

Do installation files such as .deb contain machine instructions for every supported architecture?

Não, pacotes .deb - e geralmente pacotes para quase todos os sistemas de pacotes Linux - são construídos apenas para uma arquitetura específica. Geralmente essa arquitetura é anotada no nome do arquivo.

Why then, when you want to download a program for the internet, you are usually presented with choices based on your OS, rather than instruction set architecture?

• O Windows suporta principalmente somente a arquitetura x86 (_64). (A maioria dos desenvolvedores não considera o Alpha AXP e o Itanium relevantes e a versão ARM do Windows não permite a execução de programas de terceiros.)

• OS X e iOS usam "binários gordos" (veja abaixo).

• Para Linux / BSD, o código-fonte compilável é fornecido e o usuário final - ou o gerenciador de distros - o constrói para a arquitetura necessária.

  (E se o software for fornecido apenas em formato binário?
  Bem, em 99% das vezes, se você não estiver em x86, então você está ferrado.)

• Os aplicativos para Android são distribuídos como códigos de bytes da Dalvik; eles são traduzidos para código nativo durante a instalação (se você tiver ART).

• O código "gerenciado" do .NET funciona da mesma maneira; os arquivos .exe contêm o código de byte CIL que ngen pode converter em código nativo durante a instalação ou que pode ser executado diretamente no tempo de execução do .NET.

For example if an installer supports 20 different architectures, is 95% of the data discarded during installation?

Depende do método de instalação. (Vamos supor que o programa é construído como um binário nativo, não bytecode Android / .NET / Java.)

• No caso do Windows, geralmente você tem vários instaladores de arquitetura única em primeiro lugar, e só faz o download correto.

  Mas quando o programa é enviado como um único CD com várias arquiteturas, então sim, o instalador apenas copia arquivos para sua arquitetura e ignora todo o resto. (Não há nenhum ponto em copiar arquivos inúteis depois de tudo.)

• Para pacotes Linux, é o mesmo - uma pilha de pacotes .deb específicos do tipo arco, por exemplo .

• Desde a mudança do PowerPC para a Intel, muitos programas do OS X são construídos como "binários gordos", onde um único arquivo executável contém código para ambas as arquiteturas e, quando você "instala", tudo é copiado exatamente. (Então, sim, os programas tendem a ser duas vezes maiores do que poderiam ser.)

  No entanto, ouvi dizer que a iOS App Store mudou para aceitar somente o bitcode LLVM e compilá-lo automaticamente em versões separadas para todas as arquiteturas.