Biblioteca (computação)

Da Wikipédia, a enciclopédia livre
Ir para navegação Pular para pesquisar

Ilustração de um aplicativo que usa libvorbisfile para reproduzir um arquivo Ogg Vorbis

Na ciência da computação , uma biblioteca é uma coleção de recursos não voláteis usados ​​por programas de computador , geralmente para desenvolvimento de software . Isso pode incluir dados de configuração, documentação, dados de ajuda, modelos de mensagem, código pré-escrito e sub - rotinas , classes , valores ou especificações de tipo . No OS / 360 da IBM e seus sucessores, eles são chamados de conjuntos de dados particionados . [1]

Uma biblioteca também é uma coleção de implementações de comportamento, escritas em termos de uma linguagem, que possui uma interface bem definida pela qual o comportamento é invocado. Por exemplo, as pessoas que desejam escrever um programa de nível superior podem usar uma biblioteca para fazer chamadas de sistema em vez de implementá-las continuamente. Além disso, o comportamento é fornecido para reutilização por vários programas independentes. Um programa invoca o comportamento fornecido pela biblioteca por meio de um mecanismo da linguagem. Por exemplo, em uma linguagem imperativa simplescomo C, o comportamento em uma biblioteca é invocado usando a chamada de função normal de C. O que distingue a chamada como sendo para uma função de biblioteca, versus ser para outra função no mesmo programa, é a forma como o código é organizado no sistema. [2]

O código da biblioteca é organizado de forma que possa ser usado por vários programas que não têm conexão entre si, enquanto o código que faz parte de um programa é organizado para ser usado apenas naquele programa. Essa distinção pode ganhar uma noção hierárquica quando um programa se torna grande, como um programa de milhões de linhas. Nesse caso, pode haver bibliotecas internas que são reutilizadas por sub-partes independentes do grande programa. O diferencial é que uma biblioteca é organizada com o propósito de ser reutilizada por programas ou subprogramas independentes, e o usuário só precisa conhecer a interface e não os detalhes internos da biblioteca.

O valor de uma biblioteca está na reutilização de elementos de programa padronizados. Quando um programa invoca uma biblioteca, ele obtém o comportamento implementado dentro dessa biblioteca sem ter que implementar esse comportamento em si. As bibliotecas encorajam o compartilhamento de código de forma modular e facilitam a distribuição do código.

O comportamento implementado por uma biblioteca pode ser conectado ao programa de chamada em diferentes fases do ciclo de vida do programa . Se o código da biblioteca for acessado durante a construção do programa de chamada, a biblioteca é chamada de biblioteca estática . [3] Uma alternativa é construir o executável do programa invocador e distribuí-lo, independentemente da implementação da biblioteca. O comportamento da biblioteca é conectado após o executável ter sido chamado para ser executado, seja como parte do processo de início da execução ou no meio da execução. Neste caso a biblioteca é chamada de biblioteca dinâmica (carregada em tempo de execução) Uma biblioteca dinâmica pode ser carregada e vinculada ao preparar um programa para execução pelo vinculador . Como alternativa, no meio da execução, um aplicativo pode solicitar explicitamente que um módulo seja carregado .

A maioria das linguagens compiladas tem uma biblioteca padrão , embora os programadores também possam criar suas próprias bibliotecas personalizadas. A maioria dos sistemas de software modernos fornece bibliotecas que implementam a maioria dos serviços do sistema. Essas bibliotecas organizaram os serviços que uma aplicação moderna requer. Como tal, a maioria dos códigos usados ​​por aplicativos modernos é fornecida nessas bibliotecas de sistema.

História

Uma mulher trabalhando ao lado de um arquivo contendo a biblioteca de sub-rotinas em rolos de fita perfurada para o computador EDSAC.

Em 1947, Goldstine e von Neumann especularam que seria útil criar uma "biblioteca" de sub-rotinas para seu trabalho na máquina IAS , um dos primeiros computadores que ainda não estava operacional naquela época. [4] Eles imaginaram uma biblioteca física de gravações de fios magnéticos , com cada fio armazenando código de computador reutilizável. [5]

Inspirado por von Neumann, Wilkes e sua equipe construíram o EDSAC . Um arquivo de fita perfurada continha a biblioteca de sub-rotinas deste computador. [6] Os programas para EDSAC consistiam em um programa principal e uma sequência de sub-rotinas copiadas da biblioteca de sub-rotinas. [7] Em 1951, a equipe publicou o primeiro livro sobre programação, The Preparation of Programs for an Electronic Digital Computer , que detalhou a criação e o propósito da biblioteca. [8]

O COBOL incluiu "recursos primitivos para um sistema de biblioteca" em 1959, [9] mas Jean Sammet os descreveu como "recursos de biblioteca inadequados" em retrospecto. [10]

O JOVIAL tinha um Communication Pool (COMPOOL), quase uma biblioteca de arquivos de cabeçalho.

Outro grande contribuidor para o conceito de biblioteca moderna veio na forma da inovação de subprograma do FORTRAN . Os subprogramas FORTRAN podem ser compilados independentemente uns dos outros, mas o compilador não tinha um vinculador . Portanto, antes da introdução dos módulos no Fortran-90, a verificação de tipo entre os subprogramas FORTRAN [NB 1] era impossível. [11]

Em meados da década de 1960, as bibliotecas de cópia e macro para montadores eram comuns. Começando com a popularidade do IBM System / 360 , bibliotecas contendo outros tipos de elementos de texto, por exemplo, parâmetros do sistema, também se tornaram comuns.

Simula foi a primeira linguagem de programação orientada a objetos e suas classes eram quase idênticas ao conceito moderno usado em Java , C ++ e C # . O conceito de classe do Simula também foi um progenitor do pacote em Ada e do módulo de Modula-2 . [12] Mesmo quando desenvolvidas originalmente em 1965, as classes Simula podiam ser incluídas em arquivos de biblioteca e adicionadas em tempo de compilação. [13]

Vinculando

Bibliotecas são importantes para o programa de ligação ou de ligação processo, que resolve referências conhecidas como ligações ou símbolos para módulos de biblioteca. O processo de vinculação geralmente é feito automaticamente por um programa vinculador ou fichário que pesquisa um conjunto de bibliotecas e outros módulos em uma determinada ordem. Normalmente, não é considerado um erro se um destino de link pode ser encontrado várias vezes em um determinado conjunto de bibliotecas. A vinculação pode ser feita quando um arquivo executável é criado ou sempre que o programa é usado em tempo de execução .

As referências que estão sendo resolvidas podem ser endereços para saltos e outras chamadas de rotina. Eles podem estar no programa principal ou em um módulo dependendo do outro. Eles são resolvidos em endereços fixos ou relocáveis ​​(de uma base comum) alocando memória de tempo de execução para os segmentos de memória de cada módulo referenciado.

Algumas linguagens de programação usam um recurso chamado smart linking por meio do qual o vinculador está ciente ou integrado ao compilador, de forma que o vinculador saiba como as referências externas são usadas e o código em uma biblioteca que nunca é realmente usada , mesmo que referenciado internamente, pode ser descartado do aplicativo compilado. Por exemplo, um programa que usa apenas números inteiros para aritmética ou não faz nenhuma operação aritmética pode excluir rotinas de biblioteca de ponto flutuante. Esse recurso de smart-linking pode levar a tamanhos de arquivo de aplicativo menores e uso de memória reduzido.

Relocalização

Algumas referências em um programa ou módulo de biblioteca são armazenadas em uma forma relativa ou simbólica que não pode ser resolvida até que todos os códigos e bibliotecas tenham os endereços estáticos finais atribuídos. A realocação é o processo de ajustar essas referências e é feito pelo vinculador ou pelo carregador . Em geral, a realocação não pode ser feita para bibliotecas individuais porque os endereços na memória podem variar dependendo do programa que os usa e de outras bibliotecas com as quais estão combinados. O código independente de posição evita referências a endereços absolutos e, portanto, não requer realocação.

Bibliotecas estáticas

Quando a vinculação é realizada durante a criação de um executável ou de outro arquivo de objeto, ela é conhecida como vinculação estática ou vinculação antecipada . Nesse caso, a vinculação geralmente é feita por um vinculador , mas também pode ser feita pelo compilador . [14] Uma biblioteca estática , também conhecida como arquivo , é aquela que se destina a ser vinculada estaticamente. Originalmente, apenas bibliotecas estáticas existiam. A ligação estática deve ser executada quando qualquer módulo é recompilado.

Todos os módulos exigidos por um programa às vezes são vinculados estaticamente e copiados para o arquivo executável. Esse processo e o arquivo independente resultante são conhecidos como uma compilação estática do programa. Uma construção estática pode não precisar de nenhuma realocação adicional se a memória virtual for usada e nenhuma randomização de layout de espaço de endereço for desejada. [15]

Bibliotecas compartilhadas

Uma biblioteca compartilhada ou objeto compartilhado é um arquivo que se destina a ser compartilhado por arquivos executáveis e outros arquivos de objetos compartilhados. Módulos usados ​​por um programa são carregados de objetos compartilhados individuais na memória no tempo de carregamento ou tempo de execução , em vez de serem copiados por um vinculador quando ele cria um único arquivo executável monolítico para o programa.

As bibliotecas compartilhadas podem ser vinculadas estaticamente durante o tempo de compilação, o que significa que as referências aos módulos da biblioteca são resolvidas e os módulos são alocados na memória quando o arquivo executável é criado. Mas muitas vezes a vinculação de bibliotecas compartilhadas é adiada até que sejam carregadas. [ duvidoso ]

A maioria dos sistemas operacionais modernos [NB 2] pode ter arquivos de biblioteca compartilhados no mesmo formato dos arquivos executáveis. Isso oferece duas vantagens principais: primeiro, requer a criação de apenas um carregador para os dois, em vez de dois (ter um único carregador é considerado um fator que compensa sua complexidade adicional). Em segundo lugar, permite que os executáveis ​​também sejam usados ​​como bibliotecas compartilhadas, se tiverem uma tabela de símbolos . Os formatos de biblioteca compartilhada e executável combinados típicos são ELF e Mach-O (ambos em Unix) e PE (Windows).

Em alguns ambientes mais antigos, como o Windows de 16 bits ou MPE para o HP 3000 , apenas dados baseados em pilha (locais) eram permitidos no código da biblioteca compartilhada ou outras restrições significativas foram colocadas no código da biblioteca compartilhada.

Compartilhamento de memória

O código da biblioteca pode ser compartilhado na memória por vários processos , bem como no disco. Se a memória virtual for usada, os processos executariam a mesma página física da RAM mapeada nos diferentes espaços de endereço dos processos. Isso tem vantagens. Por exemplo, no sistema OpenStep , os aplicativos geralmente tinham apenas algumas centenas de kilobytes de tamanho e eram carregados rapidamente; a maior parte de seu código estava localizada em bibliotecas que já haviam sido carregadas para outros fins pelo sistema operacional. [ citação necessária ]

Os programas podem realizar o compartilhamento de RAM usando código independente de posição , como no Unix , o que leva a uma arquitetura complexa, mas flexível, ou usando endereços virtuais comuns, como no Windows e OS / 2 . Esses sistemas garantem, por meio de vários truques como pré-mapear o espaço de endereço e reservar slots para cada biblioteca compartilhada, que o código tenha uma grande probabilidade de ser compartilhado. Uma terceira alternativa é o armazenamento de nível único , usado pelo IBM System / 38 e seus sucessores. Isso permite o código dependente da posição, mas não impõe restrições significativas sobre onde o código pode ser colocado ou como pode ser compartilhado.

Em alguns casos, versões diferentes de bibliotecas compartilhadas podem causar problemas, especialmente quando bibliotecas de versões diferentes têm o mesmo nome de arquivo e diferentes aplicativos instalados em um sistema exigem uma versão específica. Tal cenário é conhecido como inferno DLL , nomeado após o arquivo DLL do Windows e OS / 2 . A maioria dos sistemas operacionais modernos após 2001 tem métodos de limpeza para eliminar tais situações ou usar bibliotecas "privadas" específicas de aplicativos. [16]

Vinculação dinâmica

A vinculação dinâmica ou tardia é a vinculação realizada enquanto um programa está sendo carregado ( tempo de carregamento ) ou executado ( tempo de execução ), em vez de quando o arquivo executável é criado. Uma biblioteca vinculada dinamicamente (biblioteca de vínculo dinâmico , ou DLL, no Windows e OS / 2 ; imagem compartilhável no OpenVMS ; [17] objeto compartilhado dinâmico, ou DSO, em sistemas semelhantes ao Unix) é uma biblioteca destinada à vinculação dinâmica. Apenas uma quantidade mínima de trabalho é realizada pelo vinculadorquando o arquivo executável é criado; ele apenas registra quais rotinas de biblioteca o programa precisa e os nomes ou números de índice das rotinas na biblioteca. A maior parte do trabalho de vinculação é feita no momento em que o aplicativo é carregado (tempo de carregamento) ou durante a execução (tempo de execução). Normalmente, o programa de vinculação necessário, denominado "vinculador dinâmico" ou "carregador de vinculação", é na verdade parte do sistema operacional subjacente . (No entanto, é possível, e não muito difícil, escrever um programa que usa vinculação dinâmica e inclui seu próprio vinculador dinâmico, mesmo para um sistema operacional que não oferece suporte para vinculação dinâmica.)

Os programadores desenvolveram originalmente a vinculação dinâmica no sistema operacional Multics , começando em 1964, e no MTS ( Michigan Terminal System ), construído no final dos anos 1960. [18]

Otimizações

Como as bibliotecas compartilhadas na maioria dos sistemas não mudam com frequência, os sistemas podem calcular um endereço de carregamento provável para cada biblioteca compartilhada no sistema antes que seja necessário e armazenar essas informações nas bibliotecas e executáveis. Se todas as bibliotecas compartilhadas carregadas passaram por esse processo, cada uma será carregada em seu endereço predeterminado, o que acelera o processo de vinculação dinâmica. Essa otimização é conhecida como pré-vinculação no macOS e pré - vinculação no Linux. As desvantagens desta técnica incluem o tempo necessário para pré-calcular esses endereços toda vez que as bibliotecas compartilhadas mudam, a incapacidade de usar a randomização do layout do espaço de endereço e o requisito de espaço de endereço virtual suficiente para uso (um problema que será aliviado pela adoção deArquiteturas de 64 bits , pelo menos por enquanto).

Localizando bibliotecas em tempo de execução

Os carregadores para bibliotecas compartilhadas variam amplamente em funcionalidade. Alguns dependem do arquivo executável que armazena caminhos explícitos para as bibliotecas. Qualquer mudança na nomenclatura da biblioteca ou layout do sistema de arquivos fará com que esses sistemas falhem. Mais comumente, apenas o nome da biblioteca (e não o caminho) é armazenado no executável, com o sistema operacional fornecendo um método para localizar a biblioteca em disco, baseado em algum algoritmo.

Se uma biblioteca compartilhada da qual depende um executável for excluída, movida ou renomeada, ou se uma versão incompatível da biblioteca for copiada para um local anterior na pesquisa, o executável falhará ao carregar. Isso é chamado de inferno de dependência , existente em muitas plataformas. A (infame) variante do Windows é comumente conhecida como DLL Hell. Esse problema não pode ocorrer se cada versão de cada biblioteca for identificada exclusivamente e cada programa fizer referência a bibliotecas apenas por seus identificadores exclusivos completos. Os problemas do "inferno das DLLs" com as versões anteriores do Windows surgiam do uso apenas de nomes de bibliotecas, que não eram garantidas como exclusivas, para resolver links dinâmicos em programas. (Para evitar o "inferno das DLLs", as versões posteriores do Windows contam em grande parte com as opções de programas para instalar DLLs privadas - essencialmente uma retirada parcial do uso de bibliotecas compartilhadas - junto com mecanismos para impedir a substituição de DLLs de sistema compartilhadas por versões anteriores delas. )

Microsoft Windows

O Microsoft Windows verifica o registro para determinar o local apropriado para carregar DLLs que implementam objetos COM , mas para outras DLLs, ele verificará os diretórios em uma ordem definida. Primeiro, o Windows verifica o diretório onde carregou o programa ( DLL privada [16] ); quaisquer diretórios definidos chamando a SetDllDirectory()função; os diretórios System32, System e Windows; em seguida, o diretório de trabalho atual; e finalmente os diretórios especificados pela variável de ambiente PATH . [19] Os aplicativos escritos para o .NET Framework (desde 2002), também verificam o Global Assembly Cache como o armazenamento principal de arquivos dll compartilhados para remover o problema deInferno DLL .

OpenStep

O OpenStep usou um sistema mais flexível, coletando uma lista de bibliotecas de vários locais conhecidos (semelhante ao conceito PATH) quando o sistema foi iniciado pela primeira vez. Mover as bibliotecas não causa nenhum problema, embora os usuários incorram em um custo de tempo ao iniciar o sistema pela primeira vez.

Unix-like sistemas

A maioria dos sistemas semelhantes ao Unix tem um "caminho de pesquisa" especificando os diretórios do sistema de arquivos nos quais procurar bibliotecas dinâmicas. Alguns sistemas especificam o caminho padrão em um arquivo de configuração , outros embutem-no no carregador dinâmico. Alguns formatos de arquivo executável podem especificar diretórios adicionais nos quais pesquisar bibliotecas para um programa específico. Isso geralmente pode ser substituído por uma variável de ambiente , embora seja desativado para setuide programas setgid, de forma que um usuário não possa forçar tal programa a executar um código arbitrário com permissões de root. Os desenvolvedores de bibliotecas são encorajados a colocar suas bibliotecas dinâmicas em locais no caminho de pesquisa padrão. Por outro lado, isso pode tornar a instalação de novas bibliotecas problemática, e esses locais "conhecidos" rapidamente se tornam o lar de um número crescente de arquivos de biblioteca, tornando o gerenciamento mais complexo.

Carregamento dinâmico

O carregamento dinâmico, um subconjunto do link dinâmico, envolve um carregamento e descarregamento de biblioteca vinculado dinamicamente no tempo de execução mediante solicitação. Tal solicitação pode ser feita implícita ou explicitamente. Solicitações implícitas são feitas quando um compilador ou vinculador estático adiciona referências de biblioteca que incluem caminhos de arquivo ou simplesmente nomes de arquivo. [ Carece de fontes? ] Solicitações explícitas são feitas quando os aplicativos fazer chamadas diretas para API de um sistema operativo.

A maioria dos sistemas operacionais que suportam bibliotecas vinculadas dinamicamente também suportam o carregamento dinâmico dessas bibliotecas por meio de uma API de vinculação em tempo de execução . Por exemplo, Microsoft Windows usa as funções da API , , e com o Microsoft bibliotecas de ligação dinâmica ; POSIX sistemas, incluindo a maioria UNIX e baseados em UNIX-like sistemas, utilização , e . Alguns sistemas de desenvolvimento automatizam esse processo. LoadLibraryLoadLibraryExFreeLibraryGetProcAddressdlopendlclosedlsym

Bibliotecas de objetos

Embora tenha sido originalmente lançado na década de 1960, o link dinâmico não alcançou os sistemas operacionais usados ​​pelos consumidores até o final da década de 1980. Ele estava geralmente disponível de alguma forma na maioria dos sistemas operacionais no início dos anos 1990. Durante este mesmo período, a programação orientada a objetos(OOP) estava se tornando uma parte significativa do cenário de programação. OOP com vinculação de tempo de execução requer informações adicionais que as bibliotecas tradicionais não fornecem. Além dos nomes e pontos de entrada do código localizado dentro, eles também exigem uma lista dos objetos dos quais dependem. Este é um efeito colateral de uma das principais vantagens da OOP, herança, o que significa que partes da definição completa de qualquer método podem estar em lugares diferentes. Isso é mais do que simplesmente listar que uma biblioteca requer os serviços de outra: em um sistema OOP verdadeiro, as próprias bibliotecas podem não ser conhecidas no momento da compilação e variar de sistema para sistema.

Ao mesmo tempo, muitos desenvolvedores trabalharam na ideia de programas multicamadas, nos quais um "monitor" rodando em um computador desktop usaria os serviços de um mainframe ou minicomputador para armazenamento ou processamento de dados. Por exemplo, um programa em um computador baseado em GUI enviaria mensagens a um minicomputador para retornar pequenas amostras de um enorme conjunto de dados para exibição. As chamadas de procedimento remoto (RPC) já tratavam dessas tarefas, mas não havia um sistema RPC padrão.

Logo a maioria dos fornecedores de minicomputadores e mainframes instigou projetos para combinar os dois, produzindo um formato de biblioteca OOP que poderia ser usado em qualquer lugar. Esses sistemas eram conhecidos como bibliotecas de objetos , ou objetos distribuídos , se suportassem acesso remoto (nem todos tinham). O COM da Microsoft é um exemplo de tal sistema para uso local. DCOM, uma versão modificada do COM, oferece suporte ao acesso remoto.

Por algum tempo, as bibliotecas de objetos mantiveram o status de "próxima grande novidade" no mundo da programação. Houve uma série de esforços para criar sistemas que funcionassem em várias plataformas, e as empresas competiram para tentar travar os desenvolvedores em seus próprios sistemas. Exemplos incluem IBM 's Sistema Object Model (SOM / DSOM), Sun Microsystems ' Objetos Distribuídos Everywhere (DOE), NeXT 's portáteis Objetos Distribuídos (DOP), Digital ' s ObjectBroker , da Microsoft Component Object modelo (COM / DCOM), e qualquer número de sistemas baseados em CORBA .

Bibliotecas de classes

Bibliotecas de classes são o equivalente OOP aproximado de tipos mais antigos de bibliotecas de código. Eles contêm classes , que descrevem características e definem ações ( métodos ) que envolvem objetos. Bibliotecas de classes são usadas para criar instâncias ou objetos com suas características definidas para valores específicos. Em algumas linguagens OOP, como Java , a distinção é clara, com as classes frequentemente contidas em arquivos de biblioteca (como o formato de arquivo JAR do Java ) e os objetos instanciados residindo apenas na memória (embora potencialmente possam ser tornados persistentes em arquivos separados). Em outros, como Smalltalk , as bibliotecas de classes são apenas o ponto de partida para umimagem do sistema que inclui todo o estado do ambiente, classes e todos os objetos instanciados.

Hoje, a maioria das bibliotecas de classes são armazenadas em um repositório de pacotes (como o Maven Central para Java). O código do cliente declara explicitamente as dependências para bibliotecas externas em arquivos de configuração de construção (como um Maven Pom em Java).

Bibliotecas remotas

Outra solução para o problema da biblioteca vem do uso de executáveis ​​completamente separados (geralmente em alguma forma leve) e chamando-os usando uma chamada de procedimento remoto (RPC) em uma rede para outro computador. Essa abordagem maximiza a reutilização do sistema operacional: o código necessário para dar suporte à biblioteca é o mesmo código usado para fornecer suporte de aplicativo e segurança para todos os outros programas. Além disso, esses sistemas não exigem que a biblioteca exista na mesma máquina, mas podem encaminhar as solicitações pela rede.

No entanto, essa abordagem significa que cada chamada de biblioteca requer uma quantidade considerável de sobrecarga. As chamadas RPC são muito mais caras do que chamar uma biblioteca compartilhada que já foi carregada na mesma máquina. Essa abordagem é comumente usada em uma arquitetura distribuída que faz uso intensivo de chamadas remotas, principalmente sistemas cliente-servidor e servidores de aplicativos , como Enterprise JavaBeans .

Bibliotecas de geração de código

Bibliotecas de geração de código são APIs de alto nível que podem gerar ou transformar código de bytes para Java . Eles são usados ​​por programação orientada a aspectos , algumas estruturas de acesso a dados e para testar a geração de objetos proxy dinâmicos. Eles também são usados ​​para interceptar o acesso ao campo. [20]

Nomeação de arquivos

Mais moderno Unix-like sistemas

O sistema armazena libfoo.ae libfoo.soarquivos em diretórios como /lib, /usr/libou /usr/local/lib. Os nomes de arquivo sempre começam libe terminam com um sufixo de .a( arquivo , biblioteca estática) ou de .so(objeto compartilhado, biblioteca vinculada dinamicamente). Alguns sistemas podem ter vários nomes para uma biblioteca vinculada dinamicamente. Esses nomes geralmente compartilham o mesmo prefixo e têm sufixos diferentes que indicam o número da versão. A maioria dos nomes são nomes de links simbólicos para a versão mais recente. Por exemplo, em alguns sistemas libfoo.so.2seria o nome do arquivo para a segunda revisão principal da interface da biblioteca vinculada dinamicamente libfoo. Os .laarquivos às vezes encontrados nos diretórios da biblioteca são libtool arquivos, não utilizáveis ​​pelo sistema como tal.

macOS

O sistema herda as convenções da biblioteca estática do BSD , com a biblioteca armazenada em um .aarquivo, e pode usar .sobibliotecas vinculadas dinamicamente no estilo -estilo (com o .dylibsufixo). A maioria das bibliotecas no macOS, no entanto, consiste em "estruturas", colocadas em diretórios especiais chamados " pacotes " que contêm os arquivos e metadados necessários da biblioteca. Por exemplo, uma estrutura chamada MyFrameworkseria implementada em um pacote chamado MyFramework.framework, MyFramework.framework/MyFrameworksendo o arquivo de biblioteca vinculado dinamicamente ou um link simbólico para o arquivo de biblioteca vinculado dinamicamente em MyFramework.framework/Versions/Current/MyFramework.

Microsoft Windows

Bibliotecas de vínculo dinâmico geralmente têm o sufixo *.DLL, [21] embora outras extensões de nome de arquivo possam identificar bibliotecas vinculadas dinamicamente para fins específicos, por exemplo, *.OCXpara bibliotecas OLE . As revisões de interface são codificadas nos nomes de arquivo ou abstraídas usando interfaces de objeto COM . Dependendo de como são compilados, os *.LIBarquivos podem ser bibliotecas estáticas ou representações de bibliotecas vinculáveis ​​dinamicamente, necessárias apenas durante a compilação, conhecidas como " bibliotecas de importação ". Ao contrário do mundo UNIX , que usa extensões de arquivo diferentes, ao vincular a .LIBarquivos no Windowsdeve-se primeiro saber se é uma biblioteca estática regular ou uma biblioteca de importação. No último caso, um .DLLarquivo deve estar presente no tempo de execução.

Veja também

Notas

  1. ^ Isso era possível antes, por exemplo, entre os subprogramas Ada.
  2. ^ Alguns sistemas mais antigos, por exemplo, Burroughs MCP , Multics , também têm apenas um único formato para arquivos executáveis, independentemente de serem ou não compartilhados.

Referências

  1. ^ dx.doi.org . doi : 10.1107 / s1600576715005518 / fs5094sup1.zip http://dx.doi.org/10.1107/s1600576715005518/fs5094sup1.zip . Página visitada em 2021-05-27 . Ausente ou vazio |title=( ajuda )
  2. ^ Deshpande, Prasad. Detecção metamórfica usando análise de gráfico de chamada de função (Tese). Biblioteca da San Jose State University. doi : 10.31979 / etd.t9xm-ahsc .
  3. ^ "Bibliotecas estáticas" . TLDP. Arquivado do original em 03/07/2013 . Retirado 2013-10-03 .
  4. ^ Goldstine, Herman H. (31/12/2008). O computador de Pascal a von Neumann . Princeton: Princeton University Press. doi : 10.1515 / 9781400820139 . ISBN 978-1-4008-2013-9.
  5. ^ Goldstine, Herman ; von Neumann, John (1947). Planejamento e codificação de problemas para um instrumento eletrônico de computação (Relatório). Instituto de Estudos Avançados. p. 3, 21–22. OCLC 26239859 . provavelmente será muito importante desenvolver uma extensa "biblioteca" de sub-rotinas 
  6. ^ Wilkes, MV (1951). O computador EDSAC . 1951 Workshop Internacional sobre Gerenciamento de Conhecimento de Requisitos. IEEE. doi : 10.1109 / afips.1951.13 .
  7. ^ Campbell-Kelly, Martin (setembro de 2011). "Em louvor de 'Wilkes, Wheeler e Gill ' " . Comunicações da ACM . 54 (9): 25–27. doi : 10.1145 / 1995376.1995386 . S2CID 20261972 . 
  8. ^ Wilkes, Maurício ; Wheeler, David ; Gill, Stanley (1951). A Preparação de Programas para um Computador Eletrônico Digital . Addison-Wesley. p. 45, 80–91, 100. OCLC 641145988 . 
  9. ^ Wexelblat, Richard (1981). História das Linguagens de Programação . Série de monografias ACM. New York, NY: Academic Press (uma subsidiária da Harcourt Brace ). p. 274 . ISBN 0-12-745040-8.
  10. ^ Wexelblat, op. cit. , p. 258
  11. ^ Wilson, Leslie B .; Clark, Robert G. (1988). Linguagens de programação comparativas . Wokingham, Inglaterra: Addison-Wesley. p. 126. ISBN 0-201-18483-4.
  12. ^ Wilson e Clark, op. cit. , p. 52
  13. ^ Wexelblat, op. cit. , p. 716
  14. ^ Kaminsky, Dan (2008), "Portable Executable and Executable and Linking Formats" , Reverse Engineering Code with IDA Pro , Elsevier, pp. 37–66, doi : 10.1016 / b978-1-59749-237-9.00003-x , ISBN 978-1-59749-237-9, recuperado em 2021-05-27
  15. ^ Christian Collberg, John H. Hartman, Sridivya Babu, Sharath K. Udupa (2003). "SLINKY: Link estático recarregado" . Departamento de Ciência da Computação da Universidade do Arizona . Arquivado do original em 23/03/2016 . Página visitada em 2016-03-17 .CS1 maint: usa o parâmetro de autores ( link )
  16. ^ a b Anderson, Rick (2000-01-11). "O fim do inferno DLL" . microsoft.com. Arquivado do original em 05/06/2001 . Recuperado em 15/01/2012 . DLLs privadas são DLLs instaladas com um aplicativo específico e usadas apenas por esse aplicativo.
  17. ^ "Manual do utilitário VSI OpenVMS Linker" (PDF) . VSI. Agosto de 2019 . Obtido em 2021-01-31 .
  18. ^ "A History of MTS". Resumo da tecnologia da informação . 5 (5).
  19. ^ "Ordem de pesquisa da biblioteca de link dinâmico" . Biblioteca do Microsoft Developer Network . Microsoft. 06-03-2012. Arquivado do original em 09/05/2012 . Página visitada em 2012-05-20 .
  20. ^ "Biblioteca de geração de código" . Source Forge . Arquivado do original em 12/01/2010 . Página visitada em 2010-03-03 . A Biblioteca de Geração de Código de Byte é uma API de alto nível para gerar e transformar código de byte JAVA. É usado por AOP, testes, estruturas de acesso a dados para gerar objetos proxy dinâmicos e interceptar o acesso ao campo.
  21. ^ Bresnahan, Christine; Blum, Richard (27/04/2015). Guia de estudo da certificação LPIC-1 Linux Professional Institute: Exame 101-400 e Exame 102-400 . John Wiley & Sons (publicado em 2015). p. 82. ISBN  9781119021186. Arquivado do original em 24/09/2015 . Página visitada em 03-09-2015 . As bibliotecas compartilhadas do Linux são semelhantes às bibliotecas de vínculo dinâmico (DLLs) do Windows. DLLs do Windows são geralmente identificados por .dllextensões de nome de arquivo.

Leitura adicional