Una biblioteca compartida u objeto compartido es un archivo de computadora que contiene código ejecutable diseñado para ser utilizado por múltiples programas de computadora u otras bibliotecas en tiempo de ejecución .
Al ejecutar un programa que está configurado para utilizar una biblioteca compartida, el sistema operativo carga la biblioteca compartida desde un archivo (distinto del archivo ejecutable del programa) en la memoria en el momento de la carga o en el tiempo de ejecución . Para tener una perspectiva, un programa puede ser monolítico, es decir, puede estar diseñado para incluir el código ejecutable de la biblioteca en su archivo ejecutable, pero el código de la biblioteca integrado en el archivo ejecutable del programa no puede ser utilizado por otros programas.
Las bibliotecas compartidas se pueden vincular estáticamente en tiempo de compilación, lo que significa que las referencias a la biblioteca se resuelven y se le asigna memoria a la biblioteca cuando se crea el archivo ejecutable. [ cita requerida ] Pero a menudo la vinculación de bibliotecas compartidas se pospone hasta que se cargan. [ dudoso – discutir ]
La mayoría de los sistemas operativos modernos utilizan el mismo formato tanto para bibliotecas compartidas como para archivos ejecutables. [NB 1] Esto ofrece dos ventajas principales: primero, requiere solo un cargador (se considera que vale la pena cualquier complejidad adicional construir y mantener un solo cargador). [ cita requerida ] En segundo lugar, permite que un archivo ejecutable se use como una biblioteca compartida (si tiene una tabla de símbolos ). Algunos ejemplos de formatos de archivo que se usan tanto para bibliotecas compartidas como para archivos ejecutables incluyen ELF , Mach-O y PE .
En algunos entornos más antiguos, como Windows de 16 bits o MPE para HP 3000 , solo se permitían datos basados en pila (locales) en el código de biblioteca compartida, o se aplicaban otras restricciones significativas al código de biblioteca compartida.
El código de la biblioteca puede ser compartido en la memoria por varios procesos y en el disco. Si se utiliza memoria virtual, los procesos ejecutarían la misma página física de RAM que está asignada a 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 solo unos pocos cientos de kilobytes y se cargaban rápidamente; la mayor parte de su código se encontraba en bibliotecas que ya habían sido cargadas para otros fines por el sistema operativo. [ cita requerida ]
Los programas pueden compartir la RAM mediante código independiente de la posición , como en Unix , lo que conduce a una arquitectura compleja pero flexible, o mediante el uso de direcciones virtuales comunes, como en Windows y OS/2 . Estos sistemas garantizan, por diversos medios, como el mapeo previo del espacio de direcciones y la reserva de ranuras para cada biblioteca compartida, que el código tenga una alta probabilidad de ser compartido. Una tercera alternativa es el almacenamiento de un solo nivel , como el utilizado 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, las distintas versiones de bibliotecas compartidas pueden causar problemas, especialmente cuando las bibliotecas de distintas versiones tienen el mismo nombre de archivo y las distintas aplicaciones instaladas en un sistema requieren cada una una versión específica. Este tipo de 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 estas situaciones o utilizan bibliotecas "privadas" específicas de la aplicación. [1]
El enlace dinámico o enlace tardío es un enlace que 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 enlazada dinámicamente ( biblioteca de enlace dinámico , o DLL, en Windows y OS/2 ; imagen compartible en OpenVMS ; [2] objeto compartido dinámico, o DSO, en sistemas tipo Unix ) es una biblioteca destinada al enlace dinámico. El enlazador 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 enlace 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 utilice enlaces dinámicos e incluya su propio enlazador dinámico, incluso para un sistema operativo que no ofrece soporte para enlaces dinámicos).
Los programadores desarrollaron originalmente el enlace dinámico en el sistema operativo Multics , a partir de 1964, y en el MTS ( Michigan Terminal System ), construido a fines de la década de 1960. [3]
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 enlace dinámico. Esta optimización se conoce como preenlace o preenlace en macOS y Linux, respectivamente. IBM z/VM utiliza una técnica similar, llamada "Segmentos guardados discontinuos" (DCSS). [4] Las desventajas de esta técnica incluyen el tiempo necesario 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 arquitecturas de 64 bits , al menos por el momento).
Los cargadores de bibliotecas compartidas varían ampliamente en cuanto a su 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 provocará que estos sistemas fallen. Lo más común es que solo se almacene el nombre de la biblioteca (y no la ruta) en el ejecutable, y el sistema operativo proporciona un método para encontrar la biblioteca en el disco, según 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 denomina " infierno de dependencias" , que existe en muchas plataformas. La variante de Windows (infame) se conoce comúnmente como " infierno de DLL" . 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. Los problemas del "infierno de DLL" 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 vínculos dinámicos en los programas. (Para evitar el "infierno de DLL", las versiones posteriores de Windows se basan en gran medida en opciones para que los programas instalen DLL privadas (esencialmente, un retiro parcial del uso de bibliotecas compartidas) junto con mecanismos para evitar el reemplazo de DLL de sistema compartido con versiones anteriores de ellas).
Microsoft Windows comprueba el registro para determinar el lugar adecuado para cargar las DLL que implementan objetos COM , pero para otras DLL comprobará los directorios en un orden definido. Primero, Windows comprueba el directorio donde cargó el programa ( DLL privada [1] ); cualquier directorio establecido al llamar 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 . [5] Las aplicaciones escritas para .NET Framework (desde 2002), también comprueban la caché de ensamblados global como el almacén principal de archivos dll compartidos para eliminar el problema del infierno de DLL .
OpenStep utilizó un sistema más flexible, que recopila una lista de bibliotecas de varias ubicaciones conocidas (similar al concepto PATH) cuando se inicia el sistema por primera vez. Mover bibliotecas de un lado a otro no causa ningún problema, aunque los usuarios incurren en un gasto de tiempo cuando inician el sistema por primera vez.
La mayoría de los sistemas tipo Unix tienen una "ruta de búsqueda" que especifica los directorios del sistema de archivos en los que se deben buscar las 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 se deben buscar bibliotecas para un programa en particular. Esto generalmente se puede anular con una variable de entorno , aunque está deshabilitada para los programas setuid y setgid, de modo que un usuario no puede forzar a un programa de este tipo a ejecutar código arbitrario con permisos de root. Se recomienda a los desarrolladores de bibliotecas que coloquen sus bibliotecas dinámicas en lugares en 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 una cantidad cada vez mayor de archivos de biblioteca, lo que hace que la administración sea más compleja.
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 petición. Dicha solicitud puede realizarse de forma implícita o explícita. Las solicitudes implícitas se realizan cuando un compilador o un enlazador estático añade referencias de biblioteca que incluyen rutas de archivos o simplemente nombres de archivos. [ cita requerida ] 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 enlace en tiempo de ejecución . Por ejemplo, Microsoft Windows utiliza las funciones de API , y con las bibliotecas de vínculos dinámicos de Microsoft ; los sistemas basados en POSIX , incluida la mayoría de los sistemas UNIX y similares, utilizan , y . Algunos sistemas de desarrollo automatizan este proceso.LoadLibraryLoadLibraryExFreeLibraryGetProcAddressdlopendlclosedlsym
DLL privadas son DLL que se instalan con una aplicación específica y que solo utiliza esa aplicación.