Biblioteca (computação)
Origem: Wikipédia, a enciclopédia livre.
Biblioteca, na Ciência da computação, é uma coleção de subprogramas utilizados no desenvolvimento de software. Bibliotecas contém código e dados auxiliares, que provém serviços a programas independentes, o que permite o compartilhamento e a alteração de código e dados de forma modular. Alguns executáveis são tanto programas independentes quanto bibliotecas, mas a maioria das bibliotecas não são executáveis. Executáveis e bibliotecas fazem referências mútuas conhecidas como ligações através do processo conhecido como ligação, que é tipicamente realizado por um linker.
A maior parte dos sistemas operacionais modernos provê bibliotecas que implementam a maioria dos serviços do sistema. Tais bibliotecas transformaram em comodidades os serviços que uma aplicação moderna espera que sejam providos pelo sistema operacional. Assim sendo, a maior parte do código utilizado em aplicações modernas é fornecido por estas bibliotecas.
Índice |
[editar] Visão geral
Bibliotecas podem ser classificadas pela maneira como são compartilhadas, pela maneira como são ligadas, e por quando são ligadas.
[editar] Bibliotecas tradicionais
Historicamente, as bibliotecas consistiam de um conjunto de rotinas que eram copiadas para uma aplicação-alvo pelo compilador, linker ou binder, produzindo uma aplicação executável independente, ou standalone. Os fabricantes de compiladores proviam bibliotecas-padrão (por exemplo, a Biblioteca Padrão de C), mas os programadores também podiam criar suas próprias bibliotecas para uso próprio ou distribuição.
[editar] Ligação dinâmica
Ligação dinâmica significa que os dados em uma biblioteca não são copiados para um novo executável ou biblioteca em tempo de compilação, mas permanece em um arquivo separado no disco. O linker realiza uma quantidade mínima de trabalho em tempo de compilação -- ele apenas grava quais bibliotecas são necessárias para o executável e seus nomes ou números em um índice. A maior parte do trabalho é feita quando a aplicação é carregada em memória (tempo de carregamento) ou durante a execução do processo (tempo de execução). O código de ligação necessário, chamado de loader, é na verdade parte do sistema operacional subjacente. Na hora apropriada, o loader encontra as bibliotecas relevantes no disco e adiciona os dados relevantes da biblioteca ao espaço de memória do processo.
Alguns sistemas operacionais são apenas capazes de ligar uma biblioteca em tempo de carregamento, antes que a execução do processo se inicie; outros podem ser capazes de esperar até depois do início da execução e apenas ligar a biblioteca quando ela for referenciada (ou seja, durante o tempo de execução). Este último é freqüentemente chamado de "carregamento atrasado". Em ambos os casos, tal biblioteca é chamada de biblioteca de ligação dinâmica.
Plugins são uma utilização comum de bibliotecas de ligação dinâmica, algo especialmente útil quando as bibliotecas podem ser substituídas por outras com interfaces similares, mas funcionalidades diferentes. Diz-se que um software possui uma "arquitetura de plugins" se ele utiliza bibliotecas para funcionalidades essenciais com a intenção de que elas possam ser substituídas. Note, entretanto, que o uso de bibliotecas de ligação dinâmica na arquitetura de uma aplicação não necessariamente significa que elas possam ser substituídas.
A ligação dinâmica foi originalmente desenvolvida no sistema operacional Multics, a partir de 1964. Ela também era uma característica do MTS (o Michigan Terminal System), construído no final dos anos 1960. ("A History of MTS", Information Technology Digest, Vol. 5, No. 5). No Microsoft Windows, bibliotecas de ligação dinâmica são chamadas dynamic-link libraries ou "DLLs".
[editar] Realocação
Uma sutileza com a qual o loader tem que lidar é que a localização real dos dados da biblioteca não é conhecida até que o executável e todas as bibliotecas a ele associadas sejam carregadas para a memória. Isto se deve ao fato de que as localizações de memória utilizadas dependerão de quais bibliotecas foram carregadas. Não é possível armazenar uma localização absoluta para os dados dentro do próprio executável, nem mesmo na biblioteca, uma vez que isto resultaria em conflitos entre diferentes bibliotecas, isto é, se duas bibliotecas distintas alocacem espaços de memória iguais ou sobrepostos, seria impossível usar as duas no mesmo programa. Isto pode vir a mudar com a adoção de arquiteturas de 64-bits, pois elas oferecem endereços de memória virtual suficientes para garantir que cada biblioteca escrita receba sua faixa de endereços única.
Seria possível, em teoria, examinar o programa durante o tempo de carregamento e substituir cada referência a dados na biblioteca por ponteiros para as posições de memória apropriadas uma vez que todas as bibliotecas tivessem sido carregadas. Contudo, este método consumiria quantidades inaceitáveis de tempo ou memória. Em vez disso, a maioria dos sistemas de bibliotecas dinâmicas cria uma tabela de símbolos com endereços vazios no programa em tempo de compilação. Todas as referências ao código ou dados na biblioteca passam por esta tabela, chamada diretório de importação (import directory). Durante o tempo de carregamento esta tabela é modificada com a localização dos códigos e dados na biblioteca pelo loader/linker. Este processo ainda é lento a ponto de comprometer a performance de programas que façam uso de outros programas a uma taxa muito alta, como é o caso de alguns shell scripts.
A biblioteca, por sua vez, contém uma tabela com todos os métodos que a compõem, conhecida como pontos de entrada (entry points). Chamadas à biblioteca passam por esta tabela, procurando pela localização do código na memória e então os executando. Isto introduz uma sobrecarga (overhead) na chamada de biblioteca, mas o atraso é, em geral, tão pequeno que pode ser negligenciado.
[editar] Localizando bibliotecas em tempo de execução
Linkers e loaders dinâmicos variam amplamente em funcionalidade. Alguns dependem de caminhos (path) explícitos armazenados no arquivo executável. Qualquer modificação no nome da biblioteca ou layout do sistema de arquivos causará falha nestes sistemas. Mais comumente, apenas um nome da biblioteca (e não do caminho) é armazenado no executável, e o sistema operacional provê um sistema para encontrar a biblioteca no disco, baseado em algum algoritmo.
- A maioria de sistemas Unix-like possuem uma "busca de caminho" especificando o sistema de arquivos no qual procurar as bibliotecas dinâmicas. Em outros sistemas, o caminho padrão (default path) é especificado em um arquivo de configuração; em outros, é codificado no loader dinâmico (dynamic loader). Alguns formatos de arquivos executáveis podem especificar diretorios adicionais nos quais procurar por bibliotecas de um programa em particular. Ele pode geralmente ser re-lido com uma variável de ambiente, embora ela esteja desabilitada para programas setuid e setgid, então o usuário não pode forçar tal programa para rodar código arbitrário. Desenvolvedores de bibliotecas são encorajados a colocar suas bibliotecas dinâmicas em locais no caminho de busca padrão. Por outro lado, isto pode tornar a instalação de novas bibliotecas problemática, e estes caminhos conhecidos rapidamente se tornarem padrào para um número crescente de arquivos de biblioteca, tornando o gerenciamento mais complexo.
- O Windows verifica o registro do windows para determinar o lugar próprio para achar uma DLL ActiveX, mas para outras [[DLL]s ele checa o diretório de onde o programa foi carregado; o diretório corrente de trabalho (somente nas antigas versões de Windows); quaisquer diretórios selecionados pela chamada da função
SetDllDirectory(); os diretórios System32, System e Windows; e finalmente os diretórios especificados pela variável de ambiente PATH.[1]
- OpenStep usa um sistema mais flexível, coletando uma lista de bibliotecas de um número conhecido de loclizações (similar ao conceito de PATH) quando o sistema se inicia. O deslocamento de alguma biblioteca não causa problemas, no entanto um tempo maior será necessário durante o primeiro início do sistema.
Uma das grandes desvantagens da ligação dinâmica é que os executáveis dependem de bibliotecas armazenadas separadamente para o correto funcionamento. Se uma biblioteca é apagada, movida, ou renomeada, ou ainda se uma versão incompatível de uma DLL é copiada para o lugar onde é procurada, o executável pode ter mal funcionamento ou mesmo falhar no carregamento; danificando arquivos/ficheiros vitais vitais usados por quase todos os executáveis do sistema (como biblioteca C libc.so nos sistemas Unix) fazendo o sistema inoperável. No Windows isso é comumente chamado de DLL hell.
 |
Este artigo encontra-se parcialmente em língua estrangeira. Ajude e colabore com a tradução. |
