DLL
Origem: Wikipédia, a enciclopédia livre.
Os sistemas de linkagem dinâmica utilizam a maioria do código linkador no sistema operacional sobre o qual ele está rodando. Neste caso, estes sistemas são chamados de “loaders”, ou seja, carregadores, no caso, de informações.
Sinta-se livre para editá-la para que esta possa atingir um nível de qualidade superior.
Índice |
[editar] Ligação dinâmica
No momento da compilação, o linkeditor simplesmente grava quais bibliotecas o executável precisará e verifica se as mesmas estão sendo chamadas corretamente. Quando o programa é executado, o loader acha essas bibliotecas e as linka no momento de carregamento, ou então no momento de execução, quando realmente houver referência à biblioteca em questão. O resultado é chamado de biblioteca de ligação dinamicamente, que são chamadas de DLL (Dynamically Linked Library), e também pelo fato das bibliotecas dinâmicas no Microsoft Windows usarem a extensão de arquivo .DLL. Em uma biblioteca dinâmica, a localização do código é desconhecida até o momento em que ele é armazenado na memória. Isso significa que guardar a localização do código no próprio executável é impossível. Seria possível examinar o programa no momento do carregamento e substituir todas as referências com ponteiros, uma vez que a localização é conhecida, mas isso é, teoricamente, um processo que consome muito tempo. Em vez disso, o sistema de biblioteca dinâmica inclui uma tabela do código que é ligada ao programa no momento da compilação. Essa tabela, o diretório do qual se importa os arquivos, está em um caminho conhecido ao qual o código executável está ligado. No momento em que é carregada, a tabela é modificada pelo linkador/carregador com a localização do código da biblioteca. A biblioteca em si contém uma tabela de todos os métodos, conhecidos como entry points. Chamadas à biblioteca pulam essa tabela, procurando a localização do código na memória para depois chamá-lo. Isso causa um pequeno delay no tempo de chamada, porém, é tão pequeno que pode ser ignorado, comparado ao poder de processamento dos computadores atuais. O momento exato no qual a biblioteca é carregada na memória varia de sistema para sistema. No sistema operacional Windows, toda a linkagem acontece quando o executável é primeiramente carregado. Este tipo de linkagem dinâmica é chamado linkagem em tempo de carregamento (loadtime linking). Outros sistemas operacionais resolvem essas dependências em tempo de execução. Nestes sistemas, o executável chama uma API (Application Programming Interface) do sistema operacional, passando o nome de um arquivo de biblioteca, um número de função da biblioteca e os parâmetros da função. O sistema operacional resolve a importação imediatamente, e chama a função apropriada para a aplicação. Este tipo de linkagem dinâmica é chamada de linkagem em tempo de execução (runtime linking). Pelo fato do delay adicionado a cada chamada, a linkagem em tempo de execução é lenta e afeta negativamente a performance de um executável. Como resultado, ela é pouco usada por sistemas operacionais modernos. Linkadores e loaders variam amplamente em termos de funcionalidade. Alguns escrevem caminhos explícitos para as bibliotecas, baseados na localização padrão de armazenamento de bibliotecas. Qualquer mudança na nomenclatura da biblioteca ou no leiaute do sistema de arquivos resultará em uma falha. Normalmente, somente o nome da biblioteca em si é guardado, com o sistema operacional disponibilizando a biblioteca no disco baseado em algum algoritmo. Sistemas baseados em UNIX usam uma variável de caminho (PATH) que contém os lugares em que se deve procurar. Esse tipo de aplicação tende a ser robusta, visto que o caminho raramente muda. Por outro lado, isso força os desenvolvedores a gravar suas bibliotecas em uma das várias posições conhecidas, que tendem a ficar cheias e tornar o trabalho um pouco mais complexo. Nos sistemas da Microsoft a variável PATH também é usada, mas somente após serem checados o diretório de trabalho atual, o diretório determinado no ajuste de SetDllDirectory() e os diretórios system32, system e windows. Contudo, em vários momentos as bibliotecas são gravadas fora desses locais, então o registro do Windows é usado para determinar a localização correta. Uma das maiores desvantagens da linkagem dinâmica é que os executáveis dependem de bibliotecas que são armazenadas separadamente para funcionarem normalmente. Se a biblioteca é apagada, movida, renomeada ou substituída por uma versão incompatível, o executável pode ter um mau funcionamento. No Windows isto é normalmente conhecido como “inferno” de DLL (DLL hell).
[editar] Carregando dinamicamente
Uma biblioteca pode também ser carregada dinamicamente durante a execução de um programa, em oposição a quando o programa é carregado para a memória principal ou começa a partir da memória principal. O carregamento da biblioteca é então atrasado até que a mesma seja necessária, e caso não haja a necessidade, a mesma não será carregada. Essas bibliotecas também são chamadas de DLL (dinamically loaded library), porém elas são diferentes das DLL's do Windows. Este tipo de biblioteca é tipicamente usada para módulos de plug-in e para interpretadores que precisem carregar certas funcionalidades conforme a demanda. A maioria dos sistemas que suportam bibliotecas dinâmicas também suportam carregamento dinâmico via API no sistema operacional sob o qual rodam. Em alguns sistemas, o programador precisa ser cauteloso para assegurar que a biblioteca seja carregada antes de ser chamada, enquanto outras também automatizam esse processo. Internamente as diferenças são invisíveis, as bibliotecas carregadas de qualquer uma das diferentes formas são tratadas identicamente.
[editar] Bibliotecas Remotas
Outra solução para o problema das bibliotecas é usar executáveis completamente separados e chamá-los usando uma chamada remota de procedimento (RPC). Essa maneira maximiza a reutilização do sistema operacional: o código necessário para dar suporte à biblioteca é o mesmo código que está sendo usado para fornecer suporte a aplicações e segurança para todos os outros programas. Adicionalmente, tais sistemas não requerem que a biblioteca exista na mesma máquina, podendo realizar requisições através da rede. O lado ruim é que toda chamada a uma biblioteca requer um tempo considerável, fazendo com que a operação se prolongue. Chamadas RPC são geralmente muito pesadas e quando possível, não utilizadas. No entanto esse enfoque se tornou popular em um grande número de áreas de domínios específicos, como sistemas cliente-servidor e servidores de aplicações tais como o Java EnterpriseBeans.
[editar] Bibliotecas compartilhadas
Além do fato de serem carregadas estaticamente ou dinamicamente, as bibliotecas também são freqüentemente classificadas de acordo com o modo pelo qual elas são compartilhadas entre os programas. Bibliotecas dinâmicas quase sempre oferecem alguma forma de compartilhamento, permitindo que a mesma biblioteca seja utilizada por vários programas ao mesmo tempo. Bibliotecas estáticas, por definição, não podem ser compartilhadas, apenas são ligadas a cada programa. A definição de biblioteca compartilhada é levemente ambígua porque ela cobre pelo menos dois conceitos diferentes. O primeiro desses conceitos é o compartilhamento de código localizado no disco por programas não relacionados entre si. O segundo é o compartilhamento de código localizado na memória, quando programas executam a mesma página física da RAM, mapeados em diferentes endereços. Pode parecer que o segundo conceito seja o mais apropriado, e realmente ele tem inúmeras vantagens. Como exemplo pode-se citar o sistema OpenStep, no qual muitas aplicações tinham apenas algumas centenas de kilobytes de tamanho e eram carregadas quase que instantaneamente, porque a vasta maioria de seus códigos estava localizado em bibliotecas que já haviam sido carregadas pelo sistema operacional. Há, porém, um custo: o código compartilhado precisa ser especificamente escrito para rodar em um ambiente multi-tarefa, e isso tem efeitos em sua performance. Compartilhamento de RAM pode ser conseguido usando código de posição independente como no Unix, o que leva a uma arquitetura complexa porém flexível, ou usando código normal como no Windows e no OS/2. Estes sistemas se asseguram que o código tenha uma grande possibilidade de ser compartilhado atráves de variados “truques” como remapeamento do endereço de memória e reserva de slots para cada DLL. As DLL's do Windows não são bibliotecas compartilhadas como as do Unix. Na maioria dos sistemas operacionais modernos, as bibliotecas compartilhadas podem ser do mesmo formato que executáveis “normais”. Isso permite duas vantagens principais: a primeira é que é preciso somente um loader tanto para o executável quanto para a biblioteca, ao invés de dois. A maior complexidade de se usar apenas um loader é considerada um custo que acaba valendo a pena. A segunda vantagem é que é possível usar o executável também como DLL se ele possuir uma tabela de símbolos. Formatos típicos de executável/DLL são os formatos ELF (Unix) e PE (Windows). No windows, o conceito foi levado a um nível acima, sendo que até recursos do sistema como as fontes também são integradas no formato DLL de arquivo. O mesmo ocorre no sistema OpenStep, onde o formato universal integrado é usado para quase todos os recursos do sistema. O termo DLL é principalmente usado nos produtos Windows e OS/2. Nas plataformas Unix, o termo biblioteca compartilhada (shared library) é mais comum. Isso é tecnicamente justificado na diferença entre as semânticas. Em alguns casos, um sistema operacional pode ficar sobrecarregado com diferentes versões de DLL's, o que atrapalha sua performance e estabilidade. Esse cenário também é informalmente chamado de “inferno” de DLL (DLL hell), assim como no caso de erros na linkagem dinâmica.
[editar] Object Libraries
A linkagem dinâmica foi desenvolvida no fim dos anos 80 e foi disponibilizada na maioria dos sistemas operacionais no começo dos anos 90. Foi durante esse mesmo período que a programação orientada a objetos (POO) começou a entrar no mercado de programação pela primeira vez. Este tipo de programação requer informações adicionais que as bibliotecas tradicionais não fornecem; além da necessidade de que os nomes e pontos de entrada (entry points) do código estejam contidos dentro do mesmo, ela também requer uma lista dos objetos dos quais eles dependem. Isso é um efeito colateral de uma das principais vantagens da POO, herança, o que significa que a definição de qualquer método pode ser usada em inúmeros lugares. Isso é mais do que simplesmente listar que uma biblioteca necessita do serviço de outra, num verdadeiro sistema orientado a objetos, as bibliotecas por si só podem não ser conhecidas no momento da compilação, e variar de sistema para sistema. Ao mesmo tempo outra área comum de desenvolvimento se baseia na idéia de programas multitier, nos quais um “display” rodando em um computador de mesa usaria os serviços de um mainframe ou minicomputador para armazenamento de dados ou processamento. Por exemplo, um programa em um computador baseado em uma interface gráfica para o usuário mandaria mensagens para um mini-computador para que este por sua vez retorne pequenas amostras de um grande arranjo de dados. Chamadas remotas de procedimentos (RPC) já haviam lidado com essas tarefas, porém não havia um sistema RPC padrão. Não demorou muito para que a maioria de vendedores de mini/mainframes estivessem trabalhando em projetos para combinar os dois, produzindo uma biblioteca de formato POO que pudessem ser usadas em qualquer lugar. Tais sistemas eram conhecidos como bibliotecas de objetos (object libraries), ou objetos distribuídos (distributed objects) se eles suportassem acesso remoto (nem todos suportavam). O sistema COM da Microsoft é um exemplo de tal sistema para uso local, e o DCOM é uma versão modificada que suporta acesso remoto. Por algum tempo as bibliotecas de objetos foram a promessa do momento no mundo da programação. Haviam inúmeros esforços para criar sistemas que rodariam em multi-plataformas, e companhias competiram para tentar deixar os desenvolvedores trancados em seus sistemas. Exemplos incluem o System Object Model da IBM (SOM/DSOM), o Distributed Objects Everywhere da Sun Microsystems (DOE), o Portable Distributed Objects da NeXT (PDO), o ObjectBroker da Digital, o Component Object Model da Microsoft (COM/DCOM), e inúmeros sistemas baseados no CORBA. No final, revelou-se que as bibliotecas POO não eram tão atraentes o quanto prometiam ser. Com exceção da COM da Microsoft e da DO da NeXT (agora Apple Computer), todos as outras tentativas foram finalizadas.
[editar] Conclusão
As DLLs, hoje largamente utilizadas pelo sistema operacional Windows, apresentam muitas vantagens, como diminuir o tamanho do executável final, porém também apresentam desvantagens como acarretar em algum erro se o caminho indicado estiver errado. Na hora da programação o desenvolvedor necessita tomar alguns cuidados para não prejudicar o usuário final do aplicativo. Ao lado das DLLs ainda existem outros tipos de bibliotecas, como bibliotecas remotas e Object Libraries.
