Biblioteca (informática)
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 escrito previamente y subrutinas, clases, valores o especificaciones de tipo. En OS/360 de IBM y sus sucesores, se los denomina 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 simple como 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 forma 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 subporciones 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 de elementos de programas estandarizados. 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 lo invoca en diferentes fases del ciclo de vida del programa. Si se accede al código de la biblioteca durante la compilación del programa que invoca, entonces la biblioteca se denomina biblioteca estática. 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 ejecutarlo, 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 (cargada en tiempo de ejecución). El enlazador puede cargar y vincular una biblioteca dinámica al preparar un programa para su ejecución. 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. Tales bibliotecas han organizado los servicios que requiere una aplicación moderna. Como tal, la mayoría del código utilizado por las aplicaciones modernas se proporciona en estas bibliotecas del sistema.
Historia
La idea de una biblioteca informática se remonta a las primeras computadoras creadas por Charles Babbage. Un artículo de 1888 sobre su motor analítico sugirió que las operaciones de la computadora podrían perforarse en tarjetas separadas de la entrada numérica. Si estas tarjetas perforadas de operaciones se guardaran para su reutilización, "poco a poco el motor tendría una biblioteca propia".
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 de las primeras computadoras que aún no estaba operativa en ese momento. Imaginaron una biblioteca física de grabaciones de cables magnéticos, con cada cable almacenando código de computadora reutilizable.
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. 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.
COBOL incluía "capacidades primitivas para un sistema de biblioteca" en 1959, pero Jean Sammet los describió como "instalaciones bibliotecarias inadecuadas" en retrospectiva.
JOVIAL tenía un Grupo de Comunicación (COMPOOL), más o menos una biblioteca de archivos de encabezado.
Otro importante contribuyente al concepto de biblioteca moderna vino en forma de la innovación del subprograma de FORTRAN. Los subprogramas 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 los subprogramas de FORTRAN era imposible.
A mediados de la década de 1960, las bibliotecas de copias y macros para ensambladores eran comunes. Comenzando con la popularidad de 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 que se usa 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. Incluso cuando se desarrollaron originalmente en 1965, las clases de Simula podrían incluirse en archivos de biblioteca y agregarse en el momento de la compilación.
Enlace
Las bibliotecas son importantes en el proceso de vinculación o enlace del programa, que resuelve las referencias conocidas como enlaces o símbolos a los módulos de la biblioteca. El proceso de vinculación generalmente lo realiza automáticamente un programa linker o binder que busca 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 (vinculación estática) o cuando el programa se utiliza en tiempo de ejecución (vinculación dinámica).
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 (a partir de una base común) mediante la asignación de memoria de tiempo de ejecución para los segmentos de memoria de cada módulo al que se hace referencia.
Algunos lenguajes de programación usan una función llamada enlace inteligente mediante la cual el enlazador conoce o se integra con el compilador, de modo que el enlazador sabe cómo se usan las referencias externas y codifica en una biblioteca que nunca realmente utilizado, aunque se haga referencia internamente, se puede descartar de la aplicación compilada. Por ejemplo, un programa que solo usa números enteros para la aritmética, o que no realiza ninguna operación aritmética, puede excluir las rutinas de la biblioteca de punto flotante. Esta función de vinculación inteligente puede generar archivos de aplicaciones más pequeños y un uso de memoria reducido.
Reubicación
Algunas referencias en un programa o módulo de biblioteca se almacenan en forma relativa o simbólica que no se puede resolver hasta que se asignan direcciones estáticas finales a todo el código y las bibliotecas. Reubicación es el proceso de ajuste de estas referencias, y lo realiza el enlazador 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 use 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
Cuando la vinculación se realiza durante la creación de un archivo ejecutable u otro objeto, se conoce como vinculación estática o vinculación anticipada. En este caso, el enlace generalmente lo realiza un enlazador, pero también puede hacerlo el compilador. Una biblioteca estática, también conocida como archivo, está destinada a estar vinculada de forma estática. Originalmente, solo existían bibliotecas estáticas. El enlace estático se debe realizar cuando se vuelve a compilar cualquier módulo.
Todos los módulos requeridos por un programa a veces se vinculan estáticamente y se copian en el archivo ejecutable. Este proceso y el archivo independiente resultante se conocen como compilación estática del programa. Es posible que una compilación estática no necesite ninguna reubicación adicional si se usa memoria virtual y no se desea la aleatorización del diseño del espacio de direcciones.
Bibliotecas compartidas
Una biblioteca compartida u objeto compartido es un archivo 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 a la memoria en el momento de la carga o en el 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 se asigna memoria a los módulos cuando se crea el archivo ejecutable. Pero, a menudo, la vinculación de bibliotecas compartidas se pospone hasta que se cargan.
La mayoría de los sistemas operativos modernos 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 (se considera que vale la pena tener el cargador único por 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 combinados de biblioteca compartida y ejecutable 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 impusieron otras restricciones significativas al código de biblioteca compartida.
Compartir memoria
El código de la biblioteca puede ser compartido en la memoria por varios procesos y en el disco. Si se utiliza la memoria virtual, los procesos ejecutarían la misma página física de RAM que se asigna a los diferentes espacios de direcciones de los procesos. Esto tiene ventajas. Por ejemplo, en el sistema OpenStep, las aplicaciones a menudo tenían solo unos pocos cientos de kilobytes de tamaño y se cargaban rápidamente; la mayor parte de su código estaba ubicado en bibliotecas que el sistema operativo ya había cargado para otros fines.
Los programas pueden compartir la RAM mediante el uso de código independiente de la posición, como en Unix, que conduce a una arquitectura compleja pero flexible, o mediante el uso de direcciones virtuales comunes, como en Windows y OS/2. Estos sistemas aseguran, por varios medios, como el mapeo previo del espacio de direcciones y la reserva de ranuras para cada biblioteca compartida, que el código tiene una alta probabilidad de ser compartido. Una tercera alternativa es la tienda de un solo nivel, como la utilizada por 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 una versión específica. Tal escenario se conoce como DLL hell, 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 aplicaciones "privadas" bibliotecas
Enlace dinámico
La vinculación dinámica o vinculación tardía es la vinculación realizada 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ínculos dinámicos, o DLL, en Windows y OS/2; imagen compartible en OpenVMS; objeto compartido dinámico, o DSO, en sistemas similares a Unix) es una biblioteca destinada a la vinculación dinámica. El vinculador solo realiza una cantidad mínima de trabajo cuando se crea el archivo ejecutable; solo registra qué rutinas de biblioteca necesita el programa y los nombres o números de índice 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 enlace necesario, llamado "enlazador dinámico" o "cargador de enlaces", es en realidad parte del sistema operativo subyacente. (Sin embargo, es posible, y no excesivamente difícil, escribir un programa que use enlaces dinámicos e incluya su propio enlazador dinámico, incluso para un sistema operativo que 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), creado a fines de la década de 1960.
Optimizaciones
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 se necesite y almacenar esa información en las bibliotecas y ejecutables. Si cada biblioteca compartida que se carga ha pasado por este proceso, cada una se cargará en su dirección predeterminada, lo que acelera el proceso de enlace dinámico. Esta optimización se conoce como vinculación previa o vinculación previa en macOS y Linux, respectivamente. IBM z/VM utiliza una técnica similar, denominada "Segmentos guardados discontinuos" (DCSS). Las desventajas de esta técnica incluyen el tiempo requerido para precalcular estas direcciones cada vez que cambian las bibliotecas compartidas, la incapacidad de utilizar la aleatorización 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 de 64 -arquitecturas de bits, al menos por el momento).
Ubicar bibliotecas en tiempo de ejecución
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 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á. Esto se llama infierno de dependencia y 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 solo por sus identificadores únicos completos. El "infierno DLL" Los problemas con las versiones anteriores de Windows surgieron al usar solo los nombres de las bibliotecas, que no se garantizaba que fueran únicos, para resolver los enlaces dinámicos en los programas. (Para evitar el 'infierno de las DLL', las versiones posteriores de Windows se basan en gran medida en 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 con versiones anteriores de ellos).
Microsoft Windows
Microsoft Windows verifica el registro para determinar el lugar adecuado para cargar DLL que implementan objetos COM, pero para otras DLL verificará los directorios en un orden definido. Primero, Windows verifica el directorio donde cargó el programa (DLL privado); cualquier directorio establecido llamando a la función SetDllDirectory(); los directorios System32, System y Windows; luego el directorio de trabajo actual; y finalmente los directorios especificados por la variable de entorno PATH. Las aplicaciones escritas para.NET Framework (desde 2002), también verifican la Caché de ensamblaje global como el almacén principal de archivos dll compartidos para eliminar el problema del infierno DLL.
Paso abierto
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 cuando inician el sistema por primera vez.
Sistemas similares a Unix
La mayoría de los sistemas similares a Unix tienen una "ruta de búsqueda" especificando 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. Por lo general, esto se puede anular con una variable de entorno, aunque está deshabilitado para los programas setuid y setgid, por lo que un usuario no puede obligar a dicho programa a ejecutar código arbitrario con permisos de raíz. Se recomienda a los desarrolladores de bibliotecas que coloquen sus bibliotecas dinámicas en lugares de la ruta de búsqueda predeterminada. Como desventaja, esto puede hacer que la instalación de nuevas bibliotecas sea problemática, y estas "conocidas" las ubicaciones se convierten rápidamente en el hogar de un número cada vez mayor de archivos de biblioteca, lo que hace que la gestión sea más compleja.
Carga dinámica
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 vinculador estático agrega referencias de biblioteca que incluyen rutas de archivo o simplemente nombres de archivo. Las solicitudes explícitas se realizan cuando las aplicaciones realizan llamadas directas a la API de un sistema operativo.
La mayoría de los sistemas operativos que admiten bibliotecas vinculadas dinámicamente también admiten la carga dinámica de dichas bibliotecas a través de una API de vinculación en tiempo de ejecución. Por ejemplo, Microsoft Windows utiliza las funciones API LoadLibrary, LoadLibraryEx, FreeLibrary y GetProcAddress con las bibliotecas de Microsoft Dynamic Link; Los sistemas basados en POSIX, incluidos la mayoría de los sistemas UNIX y similares a UNIX, usan dlopen, dlclose y dlsym. Algunos sistemas de desarrollo automatizan este proceso.
Bibliotecas de objetos
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. Por lo 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 (POO) se estaba convirtiendo en una parte importante del panorama de la programación. OOP con enlace de 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 ubicado dentro, también requieren una lista de los objetos de los que dependen. Este es un efecto secundario de uno de los conceptos centrales de OOP, 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 OOP, es posible que las bibliotecas en sí mismas no se conozcan en el momento de la compilación y varíen de un sistema a otro.
Al mismo tiempo, muchos desarrolladores trabajaron en la idea de programas de varios niveles, en los que una "pantalla" ejecutarse en una computadora de escritorio usarí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 gran conjunto de datos para su visualización. Las llamadas a procedimientos remotos (RPC) ya manejaban estas tareas, pero no había un sistema RPC estándar.
Pronto, la mayoría de los proveedores de minicomputadoras y mainframes 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 admitían). El COM de Microsoft es un ejemplo de dicho sistema para uso local. DCOM, una versión modificada de COM, admite acceso remoto.
Durante algún tiempo, las bibliotecas de objetos tuvieron el estatus de "próxima gran cosa" 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 quedaran encerrados en su propio sistema. Los ejemplos incluyen IBM's System Object Model (SOM/DSOM), Sun Microsystems' Distributed Objects Everywhere (DOE), Portable Distributed Objects (PDO) de NeXT, ObjectBroker de Digital, Component Object Model (COM/DCOM) de Microsoft y cualquier cantidad de sistemas basados en CORBA.
Bibliotecas de clases
Las bibliotecas de clases son el equivalente aproximado de programación orientada a objetos de los tipos más antiguos de bibliotecas de códigos. 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 OOP, 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 se pueden hacer persistentes en archivos separados). archivos). 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.
Hoy en día, la mayoría de las bibliotecas de clases se almacenan en un repositorio de paquetes (como Maven Central para Java). El código del cliente declara explícitamente las dependencias de las bibliotecas externas en los archivos de configuración de compilación (como Maven Pom en Java).
Bibliotecas remotas
Otra técnica de biblioteca utiliza ejecutables completamente separados (a menudo en una forma ligera) y los llama mediante una llamada de procedimiento remoto (RPC) a través de una red a otra computadora. Esto maximiza la reutilización del sistema operativo: el código necesario para respaldar la biblioteca es el mismo código que se usa para brindar soporte de aplicaciones y seguridad 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 costosas 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 este tipo de llamadas remotas, en particular, los sistemas cliente-servidor y los servidores de aplicaciones como Enterprise JavaBeans.
Bibliotecas de generación de código
Las bibliotecas de generación de código son API de alto nivel que pueden generar o transformar código de bytes para Java. Son utilizados por la programación orientada a aspectos, algunos marcos de acceso a datos y para pruebas para generar objetos proxy dinámicos. También se utilizan para interceptar el acceso al campo.
Nombre de archivo
La mayoría de los sistemas similares a Unix modernos
El sistema almacena archivos libfoo.a y libfoo.so en directorios como /lib, /usr/lib< /código> o . Los nombres de archivo siempre comienzan con lib y terminan con un sufijo de .a (archivo, biblioteca estática) o de .so (objeto compartido, biblioteca enlazada 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.2 sería el nombre de archivo para la segunda revisión principal de la interfaz de la biblioteca enlazada dinámicamente libfoo. Los archivos .la que a veces se encuentran en los directorios de la biblioteca son archivos libtool, no utilizables por el sistema como tales.
MacOS
El sistema hereda las convenciones de bibliotecas estáticas de BSD, con la biblioteca almacenada en un archivo .a, y puede usar bibliotecas enlazadas dinámicamente al estilo .so (con el < sufijo code>.dylib en su lugar). Sin embargo, la mayoría de las bibliotecas en macOS consisten en "frameworks", ubicados dentro de directorios especiales llamados "bundles" que envuelven los archivos y metadatos necesarios de la biblioteca. Por ejemplo, un marco llamado MyFramework se implementaría en un paquete llamado MyFramework.framework, siendo MyFramework.framework/MyFramework el enlace dinámico archivo de biblioteca o ser un enlace simbólico al archivo de biblioteca vinculado dinámicamente en MyFramework.framework/Versions/Current/MyFramework.
Microsoft Windows
Las bibliotecas de enlaces dinámicos suelen tener el sufijo *.DLL, aunque otras extensiones de nombre de archivo pueden identificar bibliotecas de enlaces dinámicos con fines específicos, p. *.OCX para bibliotecas OLE. 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 archivos *.LIB pueden ser bibliotecas estáticas o representaciones de bibliotecas enlazables dinámicamente necesarias solo durante la compilación, conocidas como "importar bibliotecas". A diferencia del mundo UNIX, que usa diferentes extensiones de archivo, cuando se vincula con el archivo .LIB en Windows, primero se debe saber si se trata de una biblioteca estática normal o una biblioteca de importación. En el último caso, un archivo .DLL debe estar presente en tiempo de ejecución.
Contenido relacionado
Memoria dinámica de acceso aleatorio
Tru64 UNIX
Red de área de almacenamiento