ti-enxame.com

O que há em um DLL e como ele funciona?

Estou sempre referenciando DLLs no meu código C #, mas elas continuam sendo um mistério que eu gostaria de esclarecer. Esse é um tipo de despejo cerebral de perguntas sobre DLLs.

Entendo que DLL é uma biblioteca vinculada dinamicamente, o que significa que outro programa pode acessar essa biblioteca em tempo de execução para obter "funcionalidade". No entanto, considere o seguinte projeto do ASP.NET com Web.dll E Business.dll (Web.dll É a funcionalidade de front-end e faz referência a Business.dll Para tipos e métodos).

  1. Em que momento Web.dll Se vincula dinamicamente a Business.dll? Você percebe muito no HDD do Windows se debatendo em tarefas aparentemente pequenas ao usar o Word (etc.) e eu acho que o Word está disparando e vinculando dinamicamente a funcionalidade de outras DLLs?

    1a. Além disso, o que carrega e vincula o DLL - o SO ou alguma estrutura de tempo de execução, como a estrutura .NET?

    1b. Qual é o processo de "vinculação"? As verificações de compatibilidade são feitas? Carregando na mesma memória? O que significa realmente vincular?

  2. O que realmente executa o código na DLL? Ele é executado pelo processador ou existe outro estágio de tradução ou compilação antes que o processador entenda o código dentro da DLL?

    2a No caso de um DLL incorporado no C # .NET, o que está executando isso: a estrutura .NET ou o sistema operacional diretamente?

  3. Um DLL do Linux funciona em um sistema Windows (se isso existir), ou eles são específicos do sistema operacional?

  4. As DLLs são específicas para uma estrutura específica? Um DLL criado usando o C # .NET pode ser usado por um DLL criado com, por exemplo, o Borland C++?

    4a Se a resposta para 4 for "não", qual é o sentido de uma DLL? Por que as várias estruturas não usam seus próprios formatos para arquivos vinculados? Por exemplo: um .exe embutido no .NET sabe que um tipo de arquivo .abc é algo que pode ser vinculado ao seu código.

  5. Voltando ao exemplo Web.dll/Business.dll - para obter um tipo de classe de cliente, preciso fazer referência a Business.dll Em Web.dll. Isso deve significar que Business.dll Contém algum tipo de especificação sobre o que realmente é uma classe de cliente. Se eu tivesse compilado meu arquivo Business.dll, Digamos, Delphi: o C # o entenderia e seria capaz de criar uma classe de cliente, ou há algum tipo de informação de cabeçalho ou algo que diz "ei, desculpe, você só pode usar me de outra DLL Delphi "?

    5a O mesmo se aplica aos métodos; posso escrever um método CreateInvoice() em uma DLL, compilá-lo em C++ e acessar e executá-lo em C #? O que para ou me permite fazer isso?

  6. Sobre o assunto do seqüestro DLL, certamente a substituição (incorreta) DLL deve conter as assinaturas e os tipos exatos do método como aquele que está sendo seqüestrado. Suponho que isso não seria difícil de fazer se você descobrisse quais métodos estavam disponíveis na DLL original.

    6a O que no meu programa C # está decidindo se posso acessar outra DLL? Se meu seqüestrado DLL contivesse exatamente os mesmos métodos e tipos que o original, mas fosse compilado em outro idioma, funcionaria?

O que é DLL importando e DLL registro?

76
Remotec

Primeiro de tudo, você precisa entender a diferença entre dois tipos muito diferentes de DLLs. A Microsoft decidiu usar as mesmas extensões de arquivo (.exe e .dll) com .NET (código gerenciado) e código nativo; no entanto, DLLs de código gerenciado e DLLs nativas são muito diferentes por dentro.

1) Em que momento o web.dll vincula dinamicamente ao business.dll? Você percebe muita coisa no Windows HDD se debatendo em tarefas aparentemente pequenas ao usar o Word etc. e eu acho que esse Word dispara e vincula dinamicamente a funcionalidade de outras DLLs?

1) No caso do .NET, as DLLs geralmente são carregadas sob demanda quando o primeiro método que tenta acessar qualquer coisa do DLL é executado. É por isso que você pode obter TypeNotFoundExceptions em qualquer lugar do seu código, se a DLL não pode ser carregada. Quando algo como o Word de repente começa a acessar muito o disco rígido, é provável que ele troque (obter dados que foram trocados no disco para liberar espaço na RAM))

1a) Além disso, o que carrega e vincula a DLL - O/S ou alguma estrutura de tempo de execução, como a estrutura .Net?

1a) No caso de DLLs gerenciadas, a estrutura .NET é o que carrega, o JIT compila (compila o bytecode .NET no código nativo) e vincula as DLLs. No caso de DLLs nativas, é um componente do sistema operacional que carrega e vincula o DLL (nenhuma compilação é necessária porque as DLLs nativas já contêm código nativo)).

1b) Qual é o processo de "vinculação"? São feitas verificações de compatibilidade? Carregando na mesma memória? O que significa realmente vincular?

1b) Vinculação ocorre quando referências (por exemplo, chamadas de método) no código de chamada a símbolos (por exemplo, métodos) no DLL são substituídas pelos endereços reais das coisas na DLL. Isso é necessário porque os endereços eventuais dos itens no DLL não podem ser conhecidos antes de serem carregados na memória.

2) O que realmente executa o código na DLL? Ele é executado pelo processador ou existe outro estágio de tradução ou compilação antes que o processador entenda o código dentro da DLL?

2) No Windows, os arquivos .exe e .dll são bastante idênticos. Arquivos .exe e .dll nativos contêm código nativo (o mesmo material que o processador executa), portanto, não há necessidade de traduzir. Os arquivos .exe e .dll gerenciados contêm o bytecode do .NET, que é o primeiro compilado pelo JIT (convertido em código nativo).

2a) No caso de uma DLL criada a partir do C # .net, o que está executando isso? A estrutura .Net ou o sistema operacional diretamente?

2a) Depois que o código foi compilado pelo JIT, ele é executado exatamente da mesma maneira que qualquer código.

3) Um DLL do Linux, por exemplo, funciona em um sistema Windows (se existe algo assim)) ou eles são específicos do sistema operacional?

3) As DLLs gerenciadas podem funcionar como estão, desde que as estruturas das duas plataformas estejam atualizadas e quem escreveu o DLL não quebrou deliberadamente a compatibilidade usando chamadas nativas. As DLLs nativas serão não funciona como in-as, pois os formatos são diferentes (mesmo que o código da máquina seja o mesmo, se ambos forem da mesma plataforma de processador). Aliás, no Linux, "DLLs" são conhecidas como .so ( objeto compartilhado).

4) Eles são específicos para uma estrutura específica? Pode um DLL criado com C # .Net ser usado por um DLL criado com Borland C++ (apenas exemplo))?

4) As DLLs gerenciadas são específicas da estrutura .NET, mas naturalmente elas funcionam com qualquer idioma compatível. As DLLs nativas são compatíveis desde que todos usem as mesmas convenções (convenções de chamada (como argumentos de função são passados ​​no nível do código da máquina), nomeação de símbolos etc.)

5) Voltando ao exemplo web.dll/business.dll. Para obter um tipo de classe de cliente, preciso fazer referência ao business.dll de web.dll. Isso deve significar que business.dll contém uma especificação de algum tipo do que realmente é uma classe de cliente. Se eu tivesse compilado meu arquivo business.dll, o Delphi o entenderia e conseguiria criar uma classe de cliente - ou há algum tipo de informação de cabeçalho ou algo que diga "ei, desculpe, você só pode me usar de outra DLL do delphi" .

5) As DLLs gerenciadas contêm uma descrição completa de todas as classes, métodos, campos etc. O AFAIK Delphi não suporta .NET, por isso criaria DLLs nativas, que não podem ser usadas diretamente no .NET. Você provavelmente poderá chamar funções com o PInvoke, mas as definições de classe não serão encontradas. Como não uso o Delphi, não sei como ele armazena informações de tipo com DLLs. C++, por exemplo, depende de arquivos de cabeçalho (.h) que contêm as declarações de tipo e devem ser distribuídos com a DLL.

6) Sobre o assunto DLL seqüestro, certamente a substituição (incorreta) DLL deve conter as assinaturas exatas do método, tipos como o que está sendo seqüestrado). Suponho que isso não seria difícil de fazer se você descobrisse quais métodos estavam disponíveis na DLL original.

6) Na verdade, não é difícil de fazer se você pode alternar facilmente a DLL. A assinatura de código pode ser usada para evitar isso. Para alguém substituir uma DLL assinada, eles precisariam conhecer a chave de assinatura, que era mantida em segredo.

6a) Um pouco de pergunta repetida aqui, mas isso remonta ao que no meu programa C # está decidindo se eu posso acessar outra DLL? Se meu seqüestrado DLL contivesse exatamente os mesmos métodos e tipos que o original, mas fosse compilado em outra linguagem), funcionaria?

6a) Funcionaria desde que seja uma DLL gerenciada, criada com qualquer linguagem .NET.

  • O que é DLL importando? E registro dll?

"Importação de DLL" pode significar muitas coisas, geralmente significa fazer referência a um arquivo DLL e usar coisas nele.

O registro da DLL é algo que é feito no Windows para registrar globalmente os arquivos DLL como componentes COM para disponibilizá-los para qualquer software no sistema.

66
Matti Virkkunen

Um arquivo .dll contém código compilado que você pode usar em seu aplicativo.

Às vezes, a ferramenta usada para compilar o arquivo .dll é importante, às vezes não. Se você pode fazer referência à .dll no seu projeto, não importa qual ferramenta foi usada para codificar as funções expostas da .dll.

A vinculação acontece no tempo de execução, diferentemente das bibliotecas vinculadas estaticamente, como suas classes, que são vinculadas no momento da compilação.

Você pode pensar em uma DLL como uma caixa preta que fornece algo que seu aplicativo precisa e que você não deseja escrever sozinho. Sim, alguém que entenda a assinatura do .dll pode criar outro arquivo .dll com um código diferente e o aplicativo de chamada não saberá a diferença.

HTH

7
Beth

1) Em que momento o web.dll vincula dinamicamente ao business.dll? Você percebe muita coisa no Windows HDD se debatendo em tarefas aparentemente pequenas ao usar o Word etc. e eu acho que esse Word dispara e vincula dinamicamente a funcionalidade de outras DLLs?

1) Eu acho que você está confuso vinculando com o carregamento. O link é quando todas as verificações e saldos são testados para garantir que o que é solicitado esteja disponível. No momento do carregamento, partes da dll são carregadas na memória ou trocadas para o arquivo de paginação. Esta é a atividade de HD que você está vendo.

A vinculação dinâmica é diferente da vinculação estática. Na vinculação estática, todo o código do objeto é colocado no .exe principal no momento da vinculação. Com a vinculação dinâmica, o código do objeto é colocado em um arquivo separado (a dll) e carregado em um horário diferente do .exe.

A vinculação dinâmica pode estar implícita (ou seja, o aplicativo vincula-se a uma lib de importação) ou explícita (ou seja, o aplicativo usa LoadLibrary (ex) para carregar a dll).

No caso implícito,/DELAYLOAD pode ser usado para adiar o carregamento da dll até que o aplicativo realmente precise. Caso contrário, pelo menos algumas partes dele serão carregadas (mapeadas no espaço de endereço do processo) como parte da inicialização do processo. A dll também pode solicitar que nunca seja descarregada enquanto o processo estiver ativo.

COM usa LoadLibrary para carregar DLLs. Observe que, mesmo no caso implícito, o sistema está usando algo semelhante ao LoadLibrary para carregar a dll na inicialização do processo ou no primeiro uso.

2) O que realmente executa o código na DLL? Ele é executado pelo processador ou existe outro estágio de tradução ou compilação antes que o processador entenda o código dentro da DLL?

2) DLLs contêm código de objeto como .exes. O formato do arquivo dll é quase idêntico ao formato de um arquivo exe. Ouvi dizer que há apenas um bit diferente nos cabeçalhos dos dois arquivos.

No caso de um DLL criado a partir do C # .net, a estrutura .Net está executando-o.

3) Um DLL do Linux, por exemplo, funciona em um sistema Windows (se existe algo assim)) ou eles são específicos do sistema operacional?

3) DLLs são específicas da plataforma.

4) Eles são específicos para uma estrutura específica? Pode um DLL criado com C # .Net ser usado por um DLL criado com Borland C++ (apenas exemplo))?

4) As DLLs podem interoperar com outras estruturas se forem tomados cuidados especiais ou se algum código de cola adicional for escrito.

As DLLs são muito úteis quando uma empresa vende vários produtos com recursos sobrepostos. Por exemplo, mantenho uma DLL de E/S de varredura usada por mais de 30 produtos diferentes na empresa. Se você tiver vários produtos instalados, uma atualização da DLL poderá atualizar todos os produtos para novos formatos de varredura.

5) Voltando ao exemplo web.dll/business.dll. Para obter um tipo de classe de cliente, preciso fazer referência ao business.dll de web.dll. Isso deve significar que business.dll contém uma especificação de algum tipo do que realmente é uma classe de cliente. Se eu tivesse compilado meu arquivo business.dll, o Delphi o entenderia e conseguiria criar uma classe de cliente - ou há algum tipo de informação de cabeçalho ou algo que diga "ei, desculpe, você só pode me usar de outra DLL do delphi" .

5) Dependendo da plataforma, os recursos de uma dll são apresentados de várias maneiras, através de arquivos .h, arquivos .tlb ou outras formas .net.

6) Sobre o assunto DLL seqüestro, certamente a substituição (incorreta) DLL deve conter as assinaturas exatas do método, tipos como o que está sendo seqüestrado). Suponho que isso não seria difícil de fazer se você descobrisse quais métodos estavam disponíveis na DLL original.

6) dumpbin/exportações e dumbin/importações são ferramentas interessantes para usar em .exe e .dlls

5
edgman