O compilador cria os chamados arquivos objeto a partir do código-fonte. Estes objetos contém instruções de máquina e dados.

O linker serve para juntar todos os objetos num único arquivo, realocar seus endereços e resolver seus símbolos (nomes de função importadas, por exemplo).

O processo de compilação é a transformação do código-fonte em texto em código de máquina. Como saída, ele um arquivo chamado de objeto.

No que diz respeito ao processo de linking, estes executáveis podem ser de dois tipos:

Estáticos

Todo o código das funções externas ao executável principal é compilado junto a ele. O resultado é um executável livre de dependências, porém grande. É raro encontrar executáveis assim para Windows.

Dinâmicos

O executável vai depender de bibliotecas externas (DLLs, no caso do Windows) para funcionar e fará uso da Import Table conforme estudamos no capítulo anterior.

Como exemplo, vamos checar as dependências do binário da calculadora:

Mas e as DLLs, como "rodam"? Vejamos agora.

Programas rodando em user mode tampouco possuem acesso ao hardware do computador. Essencialmente, todos estes fatores combinados fazem com que os programas rodando neste privilégio de execução não gerem erros fatais como a famosa "tela azul", também chamada de BSOD - Blue Screen Of Death.

Passa que toda a parte legal acontece em kernel mode, sendo assim, um processo (na verdade uma thread) rodando em user mode pode executar tarefas em kernel mode através da API do Windows, que funciona como uma interface para tal. Essa comunicação é ilustrada no diagrama a seguir:

Dependências

Quando alguém cria um programa, em muitos casos se utiliza de funções de bibliotecas (ou libraries em inglês), também chamadas de DLLs (Dynamic-Link Library). Sendo assim, analise o seguinte simples programa em C:

Este programa utiliza a função printf(), que não precisou ser implementada por quem o programou. Quem escreveu o código só precisou chamar a função, já que esta está definida no arquivo stdio.h.

Quando compilado, este programa terá uma dependência da biblioteca de C (arquivo msvcrt.dll no Windows) pois o código da printf() está nela.

Esta arquitetura garante que diferetens programadores e programadoras usem tal função e que ela terá sempre o mesmo comportamento se usada da mesma forma. Mas você já parou para pensar como a função printf() de fato escreve na tela? Como ela lidaria com as diferentes placas de vídeo, por exemplo?

O fato é que a printf() não escreve diretamente na tela. Na verdade, a biblioteca de C, que contém a implementação da printf(), pede ao kernel através de uma função de sua API para que ele escreva na tela. O kernel, por sua vez, utiliza o driver da placa de vídeo que conhece a placa e a escrita acontece. Sendo assim, temos, neste caso um EXE que chama uma função de uma DLL que chama o kernel. Estudaremos mais a frente como essas chamadas acontecem.

Loader

Quando um programa é executado (por exemplo, com um duplo-clique no Windows), ele é copiado para a memória e um processo é criado para ele. Dizemos então que um processo está rodando, mas esta afirmação não é muito precisa: na verdade, todo processo no Windows possui pelo menos uma thread e ela sim é que roda. O processo funciona como um "contêiner" que contém várias informações sobre o programa rodando e suas threads.

Quem cria esse processo em memória é um componente do sistema operacional Windows chamado de image loader, presente na biblioteca ntdll.dll.

O código do loader roda antes do código do programa a ser carregado. É um código comum a todos os processos executados no Windows.

Dentre as funções do loader estão:

• Ler os cabeçalhos do arquivo PE a ser executado e alocar a memória necessária para a imagem como um todo, suas seções, etc.

  • As seções são mapeadas para a memória, respeitando-se suas permissões.

• Ler a tabela de importações do arquivo PE a fim de carregar as DLLs requeridas por este e que ainda não foram carregadas em memória. Esse processo também é chamado de resolução de dependências.

• Preencher a IAT com os endereços das funções importadas.

• Carregar módulos adicionais em tempo de execução, se assim for pedido pelo executável principal (também chamado de módulo principal).

• Manter uma lista de módulos carregados por um processo.

• Transferir a execução para o entrypoint (EP) do programa, que é quando ele de fato começa a rodar.