Arquivos DLL e LIB - o que e por quê?


214

Eu sei muito pouco sobre DLL e LIB, exceto que elas contêm código vital necessário para que um programa seja executado corretamente - bibliotecas. Mas por que os compiladores os geram? Não seria mais fácil incluir apenas todo o código em um único executável? E qual é a diferença entre DLL e LIB?


Respostas:


296

Existem bibliotecas estáticas (LIB) e dinâmicas (DLL) - mas observe que os arquivos .LIB podem ser bibliotecas estáticas (contendo arquivos de objetos) ou importar bibliotecas (contendo símbolos para permitir que o vinculador vincule a uma DLL).

Bibliotecas são usadas porque você pode ter o código que deseja usar em muitos programas. Por exemplo, se você escrever uma função que conte o número de caracteres em uma string, essa função será útil em muitos programas. Depois de conseguir que a função funcione corretamente, você não precisará recompilar o código toda vez que a usar, para colocar o código executável dessa função em uma biblioteca, e o vinculador poderá extrair e inserir o código compilado no seu programa. . Bibliotecas estáticas às vezes são chamadas de 'arquivos' por esse motivo.

As bibliotecas dinâmicas levam esse passo adiante. Parece um desperdício ter várias cópias das funções da biblioteca ocupando espaço em cada um dos programas. Por que eles não podem compartilhar uma cópia da função? É para isso que servem as bibliotecas dinâmicas. Em vez de criar o código da biblioteca no seu programa quando ele é compilado, ele pode ser executado mapeando-o no programa à medida que é carregado na memória. Vários programas em execução ao mesmo tempo que usam as mesmas funções podem compartilhar uma cópia, economizando memória. De fato, você pode carregar bibliotecas dinâmicas apenas conforme necessário, dependendo do caminho através do seu código. Não faz sentido que as rotinas da impressora ocupem memória se você não estiver imprimindo. Por outro lado, isso significa que você precisa ter uma cópia da biblioteca dinâmica instalada em todas as máquinas em que seu programa é executado.

Como exemplo, quase todos os programas escritos em 'C' precisarão de funções de uma biblioteca chamada 'biblioteca de tempo de execução C', embora poucos programas precisem de todas as funções. O tempo de execução C vem nas versões estática e dinâmica, para que você possa determinar qual versão seu programa usa, dependendo de necessidades específicas.


80
Acontece que os .LIBarquivos podem ser bibliotecas estáticas (contendo arquivos de objeto) ou bibliotecas de importação (contendo símbolos para permitir que o vinculador vincule a uma DLL). Eu estou querendo saber por que isso é assim.
Lumi

2
boa explicação! O código é compartilhado e os dados (por padrão) não são compartilhados entre os aplicativos que consomem uma DLL.
Moxo

4
@Lumi: Bom ponto. Em termos de DLLs, temos dois tipos de vinculação. Vinculação implícita , quando temos um .libarquivo fornecido pelo criador da DLL junto com os cabeçalhos apropriados; este .libé apenas um descritor da DLL de destino, contém endereços, ponto de entrada, etc., mas nenhum código. Isso .libdeve ser passado para o vinculador. O segundo é a vinculação explícita quando usamos a DLL, carregando-a manualmente com a LoadLibraryfunção. Nesse tipo, não precisamos desse .libarquivo, mas devemos nos esforçar um pouco para encontrar exportações de DLL, seus endereços e chamar essas funções por meio de ponteiros.
itachi #

37

Outro aspecto é a segurança (ofuscação). Depois que um pedaço de código é extraído do aplicativo principal e colocado em uma biblioteca de vínculo dinâmico "separada", é mais fácil atacar, analisar (fazer engenharia reversa) o código, pois ele foi isolado. Quando o mesmo trecho de código é mantido em uma Biblioteca LIB, ele faz parte do aplicativo de destino compilado (vinculado) e, portanto, é mais difícil isolar (diferenciar) esse trecho de código do restante dos binários de destino.


O aspecto da segurança era novo para mim. O raciocínio acima é verdadeiro no caso de um aplicativo C # que chama uma dll C ++ não gerenciada nativa?
5273 Martin

1
Mas o LIB também está isolado, não é? Assim, um atacante pode simplesmente analisar o LIB. Ou é um cenário comum que o LIB não seja acessível ao público?
precisa saber é o seguinte

8
o LIB também é "isolado", no que diz respeito ao processo do compilador, mas depois que o vinculador junta as partes, o LIB faz parte do EXE e não pode ser diferenciado do seu próprio código.
Mx2

17

Um motivo importante para criar uma DLL / LIB em vez de apenas compilar o código em um executável é a reutilização e a realocação. O aplicativo Java ou .NET médio (por exemplo) provavelmente usará várias bibliotecas de terceiros (ou estrutura). É muito mais fácil e rápido compilar em uma biblioteca pré-criada, em vez de precisar compilar todo o código de terceiros em seu aplicativo. Compilar seu código em bibliotecas também incentiva boas práticas de design, por exemplo, projetar suas classes para serem usadas em diferentes tipos de aplicativos.


7

Uma DLL é uma biblioteca de funções que são compartilhadas entre outros programas executáveis. Basta procurar no diretório windows / system32 e você encontrará dezenas deles. Quando o programa cria uma DLL, ele também normalmente cria um arquivo lib para que o programa application * .exe possa resolver os símbolos declarados na DLL.

Um .lib é uma biblioteca de funções vinculadas estaticamente a um programa - elas NÃO são compartilhadas por outros programas. Cada programa vinculado a um arquivo * .lib tem todo o código nesse arquivo. Se você tiver dois programas A.exe e B.exe vinculados ao C.lib, cada A e B conterão o código no C.lib.

Como você cria DLLs e bibliotecas depende do compilador que você usa. Cada compilador faz isso de maneira diferente.


4

Uma outra diferença está no desempenho.

Como a DLL é carregada no tempo de execução pelos .exe, os .exe e a DLL funcionam com o conceito de memória compartilhada e, portanto, o desempenho é baixo em relação à vinculação estática.

Por outro lado, um .lib é um código vinculado estaticamente no momento da compilação a todos os processos solicitados. Portanto, os arquivos .exe terão memória única, aumentando assim o desempenho do processo.

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.