De Wikipedia, la enciclopedia libre
Saltar a navegación Saltar a búsqueda

Ilustración de una aplicación que usa libvorbisfile para reproducir un archivo Ogg Vorbis

En informática , una biblioteca es una colección de recursos no volátiles utilizados por programas informáticos , a menudo para el desarrollo de software . Estos pueden incluir datos de configuración, documentación, datos de ayuda, plantillas de mensajes, código preescrito y subrutinas , clases , valores o especificaciones de tipo . En el OS / 360 de IBM y sus sucesores se les conoce como conjuntos de datos particionados .

Una biblioteca es también una colección de implementaciones de comportamiento, escritas en términos de un lenguaje, que tiene una interfaz bien definida mediante la cual se invoca el comportamiento. Por ejemplo, las personas que desean escribir un programa de nivel superior pueden usar una biblioteca para realizar llamadas al sistema en lugar de implementar esas llamadas al sistema una y otra vez. Además, el comportamiento se proporciona para su reutilización por varios programas independientes. Un programa invoca el comportamiento proporcionado por la biblioteca a través de un mecanismo del lenguaje. Por ejemplo, en un lenguaje imperativo simplecomo C, el comportamiento en una biblioteca se invoca mediante la llamada de función normal de C. Lo que distingue la llamada a una función de biblioteca, frente a otra función en el mismo programa, es la forma en que el código está organizado en el sistema.

El código de la biblioteca está organizado de tal manera que puede ser utilizado por varios programas que no tienen conexión entre sí, mientras que el código que es parte de un programa está organizado para ser utilizado solo dentro de ese programa. Esta distinción puede adquirir una noción jerárquica cuando un programa crece, como un programa de varios millones de líneas. En ese caso, puede haber bibliotecas internas que sean reutilizadas por sub-partes independientes del programa grande. La característica distintiva es que una biblioteca está organizada con el propósito de ser reutilizada por programas o subprogramas independientes, y el usuario solo necesita conocer la interfaz y no los detalles internos de la biblioteca.

El valor de una biblioteca radica en la reutilización del comportamiento. Cuando un programa invoca una biblioteca, obtiene el comportamiento implementado dentro de esa biblioteca sin tener que implementar ese comportamiento por sí mismo. Las bibliotecas fomentan el intercambio de código de forma modular y facilitan la distribución del código.

El comportamiento implementado por una biblioteca se puede conectar al programa que invoca en diferentes fases del ciclo de vida del programa . Si se accede al código de la biblioteca durante la construcción del programa de invocación, la biblioteca se denomina biblioteca estática . [1] Una alternativa es construir el ejecutable del programa invocador y distribuirlo, independientemente de la implementación de la biblioteca. El comportamiento de la biblioteca se conecta después de que se haya invocado el ejecutable para su ejecución, ya sea como parte del proceso de inicio de la ejecución o en medio de la ejecución. En este caso, la biblioteca se denomina biblioteca dinámica (se carga en tiempo de ejecución). Una biblioteca dinámica puede ser cargado y ligado al preparar un programa para su ejecución, por el enlazador . Alternativamente, en medio de la ejecución, una aplicación puede solicitar explícitamente que se cargue un módulo .

La mayoría de los lenguajes compilados tienen una biblioteca estándar , aunque los programadores también pueden crear sus propias bibliotecas personalizadas. La mayoría de los sistemas de software modernos proporcionan bibliotecas que implementan la mayoría de los servicios del sistema. Estas bibliotecas han organizado los servicios que requiere una aplicación moderna. Como tal, la mayor parte del código utilizado por las aplicaciones modernas se proporciona en estas bibliotecas del sistema.

Historia [ editar ]

Una mujer que trabaja junto a un archivador que contiene la biblioteca de subrutinas en rollos de cinta perforada para la computadora EDSAC.

En 1947, Goldstine y von Neumann especularon que sería útil crear una "biblioteca" de subrutinas para su trabajo en la máquina IAS , una computadora temprana que aún no estaba operativa en ese momento. Ellos imaginaron una biblioteca física de grabaciones de cables magnéticos , con cada cable almacenando un código de computadora reutilizable. [2]

Inspirado por von Neumann, Wilkes y su equipo construyeron EDSAC . Un archivador de cinta perforada contenía la biblioteca de subrutinas de esta computadora. Los programas para EDSAC consistían en un programa principal y una secuencia de subrutinas copiadas de la biblioteca de subrutinas. [3] En 1951, el equipo publicó el primer libro de texto sobre programación, La preparación de programas para una computadora digital electrónica , que detallaba la creación y el propósito de la biblioteca. [4]

COBOL incluyó "capacidades primitivas para un sistema de biblioteca" en 1959, [5] pero Jean Sammet las describió como "instalaciones bibliotecarias inadecuadas" en retrospectiva. [6]

Otro contribuyente importante al concepto de biblioteca moderna llegó en forma de la innovación del subprograma de FORTRAN . Los subprogramas de FORTRAN se pueden compilar independientemente unos de otros, pero el compilador carecía de un enlazador . Entonces, antes de la introducción de módulos en Fortran-90, la verificación de tipos entre subprogramas de FORTRAN [NB 1] era imposible. [7]

A mediados de la década de 1960, las bibliotecas de copias y macros para ensambladores eran comunes. Afirmando la popularidad del IBM System / 360 , las bibliotecas que contienen otros tipos de elementos de texto, por ejemplo, parámetros del sistema, también se volvieron comunes.

Simula fue el primer lenguaje de programación orientado a objetos y sus clases eran casi idénticas al concepto moderno utilizado en Java , C ++ y C # . El concepto de clase de Simula también fue un progenitor del paquete en Ada y el módulo de Modula-2 . [8] Incluso cuando se desarrolló originalmente en 1965, las clases de Simula podrían incluirse en archivos de biblioteca y agregarse en tiempo de compilación. [9]

Vinculando [ editar ]

Las bibliotecas son importante en el programa de enlace o unión proceso, que resuelve las referencias conocidas como enlaces o símbolos a módulos de biblioteca. El proceso de vinculación generalmente lo realiza automáticamente un vinculador o programa de encuadernación que busca en un conjunto de bibliotecas y otros módulos en un orden determinado. Por lo general, no se considera un error si un destino de enlace se puede encontrar varias veces en un conjunto determinado de bibliotecas. La vinculación se puede realizar cuando se crea un archivo ejecutable o cuando el programa se usa en tiempo de ejecución .

Las referencias que se resuelven pueden ser direcciones para saltos y otras llamadas de rutina. Pueden estar en el programa principal o en un módulo dependiendo de otro. Se resuelven en direcciones fijas o reubicables (desde una base común) mediante la asignación de memoria en tiempo de ejecución para los segmentos de memoria de cada módulo referenciado.

Algunos lenguajes de programación pueden usar una característica llamada vinculación inteligente mediante la cual el vinculador conoce o se integra con el compilador, de modo que el vinculador sabe cómo se usan las referencias externas, y el código en una biblioteca que nunca se usa realmente , aunque se haga referencia internamente, puede descartarse de la aplicación compilada. Por ejemplo, un programa que solo usa números enteros para aritmética, o que no realiza ninguna operación aritmética, puede excluir las rutinas de biblioteca de coma flotante. Esta función de vinculación inteligente puede dar lugar a archivos de aplicación más pequeños y a un uso reducido de la memoria.

Reubicación [ editar ]

Algunas referencias en un programa o módulo de biblioteca se almacenan en una forma relativa o simbólica que no se puede resolver hasta que se asignen direcciones estáticas finales a todos los códigos y bibliotecas. La reubicación es el proceso de ajuste de estas referencias y lo realiza el vinculador o el cargador . En general, la reubicación no se puede realizar en bibliotecas individuales porque las direcciones en la memoria pueden variar según el programa que las utilice y otras bibliotecas con las que se combinen. El código independiente de la posición evita las referencias a direcciones absolutas y, por lo tanto, no requiere reubicación.

Bibliotecas estáticas [ editar ]

Cuando la vinculación se realiza durante la creación de un ejecutable u otro archivo de objeto, se conoce como vinculación estática o vinculación anticipada . En este caso, el enlace normalmente lo realiza un enlazador , pero también puede hacerlo el compilador . Una biblioteca estática , también conocida como archivo , es aquella destinada a estar vinculada estáticamente. Originalmente, solo existían bibliotecas estáticas. La vinculación estática se debe realizar cuando se recompila cualquier módulo.

Todos los módulos requeridos por un programa a veces están vinculados estáticamente y se copian en el archivo ejecutable. Este proceso, y el archivo independiente resultante, se conoce como una compilación estática del programa. Es posible que una compilación estática no necesite más reubicación si se usa memoria virtual y no se desea aleatorización del diseño del espacio de direcciones . [10]

Bibliotecas compartidas [ editar ]

Una biblioteca compartida o un objeto compartido es un archivo que está destinado a ser compartido por archivos ejecutables y otros archivos de objetos compartidos. Los módulos utilizados por un programa se cargan desde objetos compartidos individuales en la memoria en el tiempo de carga o en tiempo de ejecución , en lugar de ser copiados por un enlazador cuando crea un único archivo ejecutable monolítico para el programa.

Las bibliotecas compartidas se pueden vincular estáticamente durante el tiempo de compilación, lo que significa que las referencias a los módulos de la biblioteca se resuelven y a los módulos se les asigna memoria cuando se crea el archivo ejecutable. Pero a menudo la vinculación de bibliotecas compartidas se pospone hasta que se cargan. [ dudoso ]

La mayoría de los sistemas operativos modernos [NB 2] pueden tener archivos de biblioteca compartidos del mismo formato que los archivos ejecutables. Esto ofrece dos ventajas principales: primero, requiere hacer solo un cargador para ambos, en lugar de dos (tener el cargador único se considera que vale la pena su complejidad adicional). En segundo lugar, permite que los ejecutables también se utilicen como bibliotecas compartidas, si tienen una tabla de símbolos . Los formatos típicos de biblioteca compartida y ejecutable combinados son ELF y Mach-O (ambos en Unix) y PE (Windows).

En algunos entornos más antiguos, como Windows de 16 bits o MPE para HP 3000 , solo se permitían datos basados ​​en pilas (locales) en el código de biblioteca compartida, o se establecieron otras restricciones importantes en el código de biblioteca compartida.

Compartir memoria [ editar ]

El código de la biblioteca se puede compartir en la memoria por varios procesos , así como en el disco. Si se usa memoria virtual, los procesos ejecutarían la misma página física de RAM que está mapeada en los diferentes espacios de direcciones de los procesos. Esto tiene ventajas. Por ejemplo, en el sistema OpenStep , las aplicaciones a menudo tenían un tamaño de unos pocos cientos de kilobytes y se cargaban rápidamente; la mayor parte de su código se encontraba en bibliotecas que el sistema operativo ya había cargado para otros fines. [ cita requerida ]

Los programas pueden lograr compartir RAM usando código independiente de la posición , como en Unix , que conduce a una arquitectura compleja pero flexible, o usando direcciones virtuales comunes, como en Windows y OS / 2 . Estos sistemas se aseguran, mediante varios trucos como el mapeo previo del espacio de direcciones y la reserva de espacios para cada biblioteca compartida, que el código tenga una gran probabilidad de ser compartido. Una tercera alternativa es la tienda de un solo nivel , como la utilizan IBM System / 38 y sus sucesores. Esto permite el código dependiente de la posición, pero no impone restricciones significativas sobre dónde se puede colocar el código o cómo se puede compartir.

En algunos casos, diferentes versiones de bibliotecas compartidas pueden causar problemas, especialmente cuando las bibliotecas de diferentes versiones tienen el mismo nombre de archivo y las diferentes aplicaciones instaladas en un sistema requieren cada una de una versión específica. Tal escenario se conoce como el infierno de DLL , llamado así por el archivo DLL de Windows y OS / 2 . La mayoría de los sistemas operativos modernos posteriores a 2001 tienen métodos de limpieza para eliminar tales situaciones o utilizan bibliotecas "privadas" específicas de la aplicación. [11]

Vinculación dinámica [ editar ]

La vinculación dinámica o vinculación tardía se realiza mientras se carga un programa ( tiempo de carga ) o se ejecuta ( tiempo de ejecución ), en lugar de cuando se crea el archivo ejecutable. Una biblioteca vinculada dinámicamente (biblioteca de vínculo dinámico , o DLL, en Windows y OS / 2 ; imagen que se puede compartir en OpenVMS ; [12] objeto compartido dinámico, o DSO, en sistemas similares a Unix) es una biblioteca destinada a la vinculación dinámica. El enlazador solo realiza una cantidad mínima de trabajocuando se crea el archivo ejecutable; sólo registra qué rutinas de biblioteca necesita el programa y los nombres de índice o números de las rutinas en la biblioteca. La mayor parte del trabajo de vinculación se realiza en el momento en que se carga la aplicación (tiempo de carga) o durante la ejecución (tiempo de ejecución). Por lo general, el programa de vinculación necesario, llamado "vinculador dinámico" o "cargador de vinculación", es en realidad parte del sistema operativo subyacente . (Sin embargo, es posible, y no excesivamente difícil, escribir un programa que utilice enlaces dinámicos e incluya su propio enlazador dinámico, incluso para un sistema operativo que en sí mismo no proporciona soporte para enlaces dinámicos).

Los programadores desarrollaron originalmente la vinculación dinámica en el sistema operativo Multics , a partir de 1964, y el MTS ( Michigan Terminal System ), construido a finales de la década de 1960. [13]

Optimizaciones [ editar ]

Dado que las bibliotecas compartidas en la mayoría de los sistemas no cambian con frecuencia, los sistemas pueden calcular una dirección de carga probable para cada biblioteca compartida en el sistema antes de que sea necesaria y almacenar esa información en las bibliotecas y ejecutables. Si cada biblioteca compartida que se carga ha pasado por este proceso, entonces cada una se cargará en su dirección predeterminada, lo que acelera el proceso de vinculación dinámica. Esta optimización se conoce como vinculación previa en macOS y vinculación previa en Linux. Las desventajas de esta técnica incluyen el tiempo necesario para calcular previamente estas direcciones cada vez que cambian las bibliotecas compartidas, la incapacidad de utilizar la distribución aleatoria del diseño del espacio de direcciones y el requisito de suficiente espacio de direcciones virtuales para su uso (un problema que se aliviará con la adopción deArquitecturas de 64 bits , al menos por el momento).

Localización de bibliotecas en tiempo de ejecución [ editar ]

Los cargadores para bibliotecas compartidas varían ampliamente en funcionalidad. Algunos dependen de que el ejecutable almacene rutas explícitas a las bibliotecas. Cualquier cambio en el nombre de la biblioteca o en el diseño del sistema de archivos hará que estos sistemas fallen. Más comúnmente, solo el nombre de la biblioteca (y no la ruta) se almacena en el ejecutable, y el sistema operativo proporciona un método para encontrar la biblioteca en el disco, basado en algún algoritmo.

Si se elimina, mueve o cambia el nombre de una biblioteca compartida de la que depende un ejecutable, o si se copia una versión incompatible de la biblioteca en un lugar anterior en la búsqueda, el ejecutable no se cargará. A esto se le llama el infierno de la dependencia , que existe en muchas plataformas. La (infame) variante de Windows se conoce comúnmente como DLL Hell. Este problema no puede ocurrir si cada versión de cada biblioteca se identifica de forma única y cada programa hace referencia a las bibliotecas sólo por sus identificadores únicos completos. Los problemas del "infierno de las DLL" con las versiones anteriores de Windows surgieron por usar solo los nombres de las bibliotecas, que no se garantizaba que fueran únicas, para resolver los vínculos dinámicos en los programas. (Para evitar el "infierno de las DLL", las versiones posteriores de Windows dependen en gran medida de las opciones para que los programas instalen DLL privadas, esencialmente una retirada parcial del uso de bibliotecas compartidas, junto con mecanismos para evitar el reemplazo de las DLL del sistema compartido por versiones anteriores de ellas. )

Microsoft Windows [ editar ]

Microsoft Windows comprueba el registro para determinar el lugar adecuado para cargar archivos DLL que implementan objetos COM , pero para otros archivos DLL comprobará los directorios en un orden definido. Primero, Windows verifica el directorio donde cargó el programa ( DLL privada [11] ); cualquier directorio establecido llamando a la SetDllDirectory()función; los directorios System32, System y Windows; luego el directorio de trabajo actual; y finalmente los directorios especificados por la variable de entorno PATH . [14] Aplicaciones escritas para el marco .NET Framework (desde 2002), también verifique la caché de ensamblados globalcomo el almacén principal de archivos dll compartidos para eliminar el problema de DLL Hell .

OpenStep [ editar ]

OpenStep utilizó un sistema más flexible, recopilando una lista de bibliotecas de varias ubicaciones conocidas (similar al concepto PATH) cuando el sistema se inicia por primera vez. Mover las bibliotecas no causa ningún problema, aunque los usuarios incurren en un costo de tiempo al iniciar el sistema por primera vez.

Sistemas similares a Unix [ editar ]

La mayoría de los sistemas similares a Unix tienen una "ruta de búsqueda" que especifica los directorios del sistema de archivos en los que buscar bibliotecas dinámicas. Algunos sistemas especifican la ruta predeterminada en un archivo de configuración , otros la codifican en el cargador dinámico. Algunos formatos de archivos ejecutables pueden especificar directorios adicionales en los que buscar bibliotecas para un programa en particular. Esto generalmente se puede anular con una variable de entorno , aunque está deshabilitado para setuidy programas setgid, de modo que un usuario no pueda obligar a dicho programa a ejecutar código arbitrario con permisos de root. Se anima a los desarrolladores de bibliotecas a colocar sus bibliotecas dinámicas en lugares de la ruta de búsqueda predeterminada. En el lado negativo, esto puede hacer que la instalación de nuevas bibliotecas sea problemática, y estas ubicaciones "conocidas" se convierten rápidamente en el hogar de un número creciente de archivos de bibliotecas, lo que hace que la administración sea más compleja.

Carga dinámica [ editar ]

La carga dinámica, un subconjunto de la vinculación dinámica, implica la carga y descarga de una biblioteca vinculada dinámicamente en tiempo de ejecución a pedido. Tal solicitud puede hacerse implícita o explícitamente. Las solicitudes implícitas se realizan cuando un compilador o un enlazador estático agrega referencias de biblioteca que incluyen rutas de archivo o simplemente nombres de archivo. [ cita requerida ] Se realizan solicitudes explícitas cuando las aplicaciones realizan llamadas directas a la API de un sistema operativo.

La mayoría de los sistemas operativos compatibles con las bibliotecas de enlace dinámico también apoyan dinámicamente la carga de tales bibliotecas a través de un tiempo de ejecución enlazador API . Por ejemplo, Microsoft Windows utiliza las funciones API LoadLibrary , LoadLibraryEx , FreeLibrary y GetProcAddress con las bibliotecas de enlaces dinámicos de Microsoft ; Los sistemas basados ​​en POSIX , incluida la mayoría de los sistemas UNIX y similares a UNIX, utilizan dlopen , dlclose y dlsym . Algunos sistemas de desarrollo automatizan este proceso.

Bibliotecas de objetos y clases [ editar ]

Aunque originalmente fue pionero en la década de 1960, la vinculación dinámica no llegó a los sistemas operativos utilizados por los consumidores hasta finales de la década de 1980. En general, estaba disponible de alguna forma en la mayoría de los sistemas operativos a principios de la década de 1990. Durante este mismo período, la programación orientada a objetos(OOP) se estaba convirtiendo en una parte importante del panorama de la programación. La programación orientada a objetos con enlace en tiempo de ejecución requiere información adicional que las bibliotecas tradicionales no proporcionan. Además de los nombres y puntos de entrada del código que se encuentran dentro, también requieren una lista de los objetos de los que dependen. Este es un efecto secundario de una de las principales ventajas de la programación orientada a objetos, la herencia, lo que significa que partes de la definición completa de cualquier método pueden estar en diferentes lugares. Esto es más que simplemente enumerar que una biblioteca requiere los servicios de otra: en un verdadero sistema de programación orientada a objetos, las bibliotecas en sí pueden no ser conocidas en el momento de la compilación y varían de un sistema a otro.

Al mismo tiempo, muchos desarrolladores trabajaron en la idea de programas de varios niveles, en los que una "pantalla" que se ejecuta en una computadora de escritorio utilizaría los servicios de una computadora central o minicomputadora para el almacenamiento o procesamiento de datos. Por ejemplo, un programa en una computadora basada en GUI enviaría mensajes a una minicomputadora para devolver pequeñas muestras de un enorme conjunto de datos para su visualización. Las llamadas a procedimiento remoto (RPC) ya manejaban estas tareas, pero no existía un sistema RPC estándar.

Pronto, la mayoría de los proveedores de miniordenadores y mainframe instigaron proyectos para combinar los dos, produciendo un formato de biblioteca OOP que podría usarse en cualquier lugar. Dichos sistemas se conocían como bibliotecas de objetos u objetos distribuidos , si admitían el acceso remoto (no todos lo hicieron). COM de Microsoft es un ejemplo de un sistema de este tipo para uso local. DCOM, una versión modificada de COM, admite acceso remoto.

Durante algún tiempo, las bibliotecas de objetos mantuvieron el estatus de "la próxima gran novedad" en el mundo de la programación. Hubo una serie de esfuerzos para crear sistemas que se ejecutaran en todas las plataformas, y las empresas compitieron para intentar que los desarrolladores se encerraran en su propio sistema. Los ejemplos incluyen IBM 's Sistema Modelo de objetos (SOM / DSOM), Sun Microsystems ' objetos distribuidos por todas partes (DOE), NeXT 's objetos distribuidos portables (DOP), Digital ' s ObjectBroker , de Microsoft Component Object Model (COM / DCOM), y cualquier número de sistemas basados ​​en CORBA .

Después de que se enfrió el bombo publicitario, las bibliotecas de objetos continuaron utilizándose tanto en la programación orientada a objetos como en los sistemas de información distribuida. Las bibliotecas de clases son el equivalente aproximado de OOP de los tipos más antiguos de bibliotecas de código. Contienen clases , que describen características y definen acciones ( métodos ) que involucran objetos. Las bibliotecas de clases se utilizan para crear instancias u objetos con sus características establecidas en valores específicos. En algunos lenguajes de programación orientada a objetos, como Java , la distinción es clara, con las clases a menudo contenidas en archivos de biblioteca (como el formato de archivo JAR de Java ) y los objetos instanciados que residen solo en la memoria (aunque potencialmente pueden volverse persistentesen archivos separados). En otros, como Smalltalk , las bibliotecas de clases son simplemente el punto de partida para una imagen del sistema que incluye el estado completo del entorno, las clases y todos los objetos instanciados.

Bibliotecas remotas [ editar ]

Otra solución al problema de la biblioteca proviene del uso de ejecutables completamente separados (a menudo en alguna forma liviana) y llamarlos usando una llamada a procedimiento remoto (RPC) a través de una red a otra computadora. Este enfoque maximiza la reutilización del sistema operativo: el código necesario para admitir la biblioteca es el mismo código que se utiliza para brindar soporte y seguridad a las aplicaciones para todos los demás programas. Además, dichos sistemas no requieren que la biblioteca exista en la misma máquina, pero pueden reenviar las solicitudes a través de la red.

Sin embargo, este enfoque significa que cada llamada a la biblioteca requiere una cantidad considerable de gastos generales. Las llamadas RPC son mucho más caras que llamar a una biblioteca compartida que ya se ha cargado en la misma máquina. Este enfoque se usa comúnmente en una arquitectura distribuida que hace un uso intensivo de tales llamadas remotas, en particular, sistemas cliente-servidor y servidores de aplicaciones como Enterprise JavaBeans .

Bibliotecas de generación de código [ editar ]

Las bibliotecas de generación de código son API de alto nivel que pueden generar o transformar código de bytes para Java . Se utilizan en la programación orientada a aspectos , en algunos marcos de acceso a datos y para realizar pruebas para generar objetos proxy dinámicos. También se utilizan para interceptar el acceso al campo. [15]

Nombre de archivo [ editar ]

Más moderno de tipo Unix sistemas [ editar ]

El sistema almacena libfoo.ay libfoo.soarchivos en directorios como /lib, /usr/libo /usr/local/lib. Los nombres de archivo siempre comienzan liby terminan con un sufijo de .a( archivo , biblioteca estática) o de .so(objeto compartido, biblioteca vinculada dinámicamente). Algunos sistemas pueden tener varios nombres para una biblioteca vinculada dinámicamente. Estos nombres suelen compartir el mismo prefijo y tienen diferentes sufijos que indican el número de versión. La mayoría de los nombres son nombres de enlaces simbólicos a la última versión. Por ejemplo, en algunos sistemas libfoo.so.2sería el nombre de archivo de la segunda revisión principal de la interfaz de la biblioteca vinculada dinámicamente libfoo. Los .laarchivos que a veces se encuentran en los directorios de la biblioteca son libtool archivos, no utilizables por el sistema como tal.

macOS [ editar ]

El sistema hereda las convenciones de bibliotecas estáticas de BSD , con la biblioteca almacenada en un .aarchivo, y puede usar .sobibliotecas vinculadas dinámicamente de estilo (con el .dylibsufijo en su lugar). La mayoría de las bibliotecas en macOS, sin embargo, constan de "marcos", ubicados dentro de directorios especiales llamados " paquetes " que envuelven los archivos y metadatos requeridos por la biblioteca. Por ejemplo, un marco llamado MyFrameworkse implementaría en un paquete llamado MyFramework.framework, MyFramework.framework/MyFrameworksiendo el archivo de biblioteca vinculado dinámicamente o un enlace simbólico al archivo de biblioteca vinculado dinámicamente en MyFramework.framework/Versions/Current/MyFramework.

Microsoft Windows [ editar ]

Bibliotecas de vínculos dinámicos por lo general tienen el sufijo *.DLL, [16] aunque otras extensiones de nombre de archivo pueden identificar de propósito específico bibliotecas de enlace dinámico, por ejemplo *.OCXpara OLE bibliotecas. Las revisiones de la interfaz se codifican en los nombres de los archivos o se abstraen mediante interfaces de objetos COM . Dependiendo de cómo se compilen, los *.LIBarchivos pueden ser bibliotecas estáticas o representaciones de bibliotecas enlazables dinámicamente necesarias solo durante la compilación, conocidas como " bibliotecas de importación ". A diferencia del mundo UNIX , que utiliza diferentes extensiones de archivo, cuando se vincula con un .LIBarchivo en Windowsprimero hay que saber si se trata de una biblioteca estática regular o de una biblioteca de importación. En el último caso, .DLLdebe haber un archivo en tiempo de ejecución.

Ver también [ editar ]

  • Reutilización de código
  • Linker (informática)  : programa informático que combina varios archivos de objetos en un solo archivo
  • Cargador (informática)
  • Biblioteca de vínculos dinámicos
  • Archivo de objeto  : archivo que contiene código de máquina de formato reubicable
  • Complemento  : componente de software que agrega una función específica a una aplicación de software existente
  • Prevínculo , también conocido como Previnculación
  • Biblioteca estática
  • Biblioteca de ejecución
  • Biblioteca de componentes visuales (VCL)
  • Biblioteca de componentes para multiplataforma (CLX)
  • Biblioteca estándar C: biblioteca  estándar para el lenguaje de programación C
  • Biblioteca de clases de Java
  • Biblioteca de clases de Framework  : biblioteca estándar de .NET Framework de Microsoft
  • Programación genérica  : forma de diseñar y escribir programas donde los algoritmos se escriben en términos de tipos paramétricos que permiten una fácil reutilización (utilizado por la biblioteca estándar de C ++ )
  • soname  : campo de datos en un archivo de objeto compartido
  • Stub de método

Notas [ editar ]

  1. ^ Fue posible antes entre, por ejemplo, subprogramas de Ada.
  2. ^ Algunos sistemas más antiguos, por ejemplo, Burroughs MCP , Multics , también tienen un solo formato para los archivos ejecutables, independientemente de si se comparten.

Referencias [ editar ]

  1. ^ "Bibliotecas estáticas" . TLDP. Archivado desde el original el 3 de julio de 2013 . Consultado el 3 de octubre de 2013 .
  2. ^ Goldstine, Herman ; von Neumann, John (1947). Planificación y codificación de problemas para un instrumento informático electrónico (Informe). Instituto de Estudios Avanzados. pag. 3, 21-22. OCLC 26239859 . probablemente será muy importante desarrollar una "biblioteca" extensa de subrutinas 
  3. ^ Campbell-Kelly, Martin (septiembre de 2011). "En alabanza de 'Wilkes, Wheeler y Gill ' " . Comunicaciones de la ACM . 54 (9): 25-27. doi : 10.1145 / 1995376.1995386 .
  4. ^ Wilkes, Maurice ; Wheeler, David ; Gill, Stanley (1951). La preparación de programas para una computadora digital electrónica . Addison-Wesley. pag. 45, 80–91, 100. OCLC 641145988 . 
  5. ^ Wexelblat, Richard (1981). Historia de los lenguajes de programación . Serie de monografías ACM. Nueva York, NY: Academic Press (una subsidiaria de Harcourt Brace ). pag. 274 . ISBN 0-12-745040-8.
  6. ^ Wexelblat, op. cit. , pag. 258
  7. ^ Wilson, Leslie B .; Clark, Robert G. (1988). Lenguajes de programación comparativos . Wokingham, Inglaterra: Addison-Wesley. pag. 126. ISBN 0-201-18483-4.
  8. ^ Wilson y Clark, op. cit. , pag. 52
  9. ^ Wexelblat, op. cit. , pag. 716
  10. ^ Christian Collberg, John H. Hartman, Sridivya Babu, Sharath K. Udupa (2003). "SLINKY: Enlace estático recargado" . Departamento de Ciencias de la Computación, Universidad de Arizona . Archivado desde el original el 23 de marzo de 2016 . Consultado el 17 de marzo de 2016 .CS1 maint: uses authors parameter (link)
  11. ↑ a b Anderson, Rick (11 de enero de 2000). "El fin del infierno DLL" . microsoft.com. Archivado desde el original el 5 de junio de 2001 . Consultado el 15 de enero de 2012 . Las DLL privadas son DLL que se instalan con una aplicación específica y solo las usa esa aplicación.
  12. ^ "Manual de la utilidad VSI OpenVMS Linker" (PDF) . VSI. Agosto de 2019 . Consultado el 31 de enero de 2021 .
  13. ^ "Una historia de MTS". Compendio de tecnología de la información . 5 (5).
  14. ^ "Orden de búsqueda de biblioteca de vínculos dinámicos" . Biblioteca de Microsoft Developer Network . Microsoft. 2012-03-06. Archivado desde el original el 9 de mayo de 2012 . Consultado el 20 de mayo de 2012 .
  15. ^ "Biblioteca de generación de código" . Fuente Forge . Archivado desde el original el 12 de enero de 2010 . Consultado el 3 de marzo de 2010 . Byte Code Generation Library es una API de alto nivel para generar y transformar código de bytes JAVA. Es utilizado por AOP, pruebas, marcos de acceso a datos para generar objetos proxy dinámicos e interceptar el acceso al campo.
  16. ^ Bresnahan, Christine; Blum, Richard (27 de abril de 2015). LPIC-1 Linux Professional Institute Certification Study Guide: Examen 101-400 y Examen 102-400 . John Wiley & Sons (publicado en 2015). pag. 82. ISBN 9781119021186. Archivado desde el original el 24 de septiembre de 2015 . Consultado el 3 de septiembre de 2015 . Las bibliotecas compartidas de Linux son similares a las bibliotecas de vínculos dinámicos (DLL) de Windows. Las DLL de Windows generalmente se identifican mediante extensiones de nombre de archivo .dll .

Lectura adicional [ editar ]

  • Levine, John R. (2000) [octubre de 1999]. "Capítulo 9: Bibliotecas compartidas y Capítulo 10: Vinculación dinámica y carga". Enlazadores y cargadores . La Serie Morgan Kaufmann en Ingeniería de Software y Programación (1 ed.). San Francisco, Estados Unidos: Morgan Kaufmann . ISBN 1-55860-496-0. OCLC  42413382 . ISBN 978-1-55860-496-4 . Archivado desde el original el 5 de diciembre de 2012 . Consultado el 12 de enero de 2020 . Código: [1] [2] Errata: [3]
  • Artículo Guía para principiantes de enlazadores por David Drysdale
  • Artículo Inicio más rápido del programa C ++ al mejorar la eficiencia de la vinculación del tiempo de ejecución por Léon Bottou y John Ryland
  • Cómo crear bibliotecas de programas por Baris Simsek
  • BFD : la biblioteca de descriptores de archivos binarios
  • 1er Taller de diseño de software centrado en bibliotecas LCSD'05 en OOPSLA'05
  • 2do Taller de Diseño de Software Centrado en Bibliotecas LCSD'06 en OOPSLA'06
  • Cómo crear una biblioteca compartida por Ulrich Drepper (con mucha información de fondo)
  • Anatomía de las bibliotecas dinámicas de Linux en IBM.com