Biblioteca de vínculos dinámicos

En la API de Windows , los archivos DLL se organizan en secciones . Cada sección tiene su propio conjunto de atributos, como ser editable o de solo lectura, ejecutable (para código) o no ejecutable (para datos), etc.

El código de una DLL suele ser compartido entre todos los procesos que la utilizan; es decir, ocupa un único lugar en la memoria física y no ocupa espacio en el archivo de paginación . Windows no utiliza código independiente de la posición para sus DLL; en su lugar, el código se reubica al cargarse, fijando las direcciones de todos sus puntos de entrada en ubicaciones libres en el espacio de memoria del primer proceso que carga la DLL. En versiones anteriores de Windows, en las que todos los procesos en ejecución ocupaban un único espacio de direcciones común, una sola copia del código de la DLL siempre era suficiente para todos los procesos. Sin embargo, en versiones más recientes de Windows, que utilizan espacios de direcciones separados para cada programa, solo es posible usar la misma copia reubicada de la DLL en varios programas si cada programa tiene las mismas direcciones virtuales libres para alojar el código de la DLL. Si algunos programas (o su combinación de DLL ya cargadas) no tienen esas direcciones libres, será necesario crear una copia física adicional del código de la DLL, utilizando un conjunto diferente de puntos de entrada reubicados. Si se necesita recuperar la memoria física ocupada por una sección de código, su contenido se descarta y posteriormente se vuelve a cargar directamente desde el archivo DLL según sea necesario.

A diferencia de las secciones de código, las secciones de datos de una DLL suelen ser privadas; es decir, cada proceso que utiliza la DLL tiene su propia copia de todos sus datos. Opcionalmente, las secciones de datos pueden ser compartidas, lo que permite la comunicación entre procesos a través de esta área de memoria compartida. Sin embargo, dado que las restricciones de usuario no se aplican al uso de la memoria compartida de la DLL, esto crea una vulnerabilidad de seguridad : un proceso puede corromper los datos compartidos, lo que probablemente provocará que todos los demás procesos que la comparten se comporten de forma anómala. Por ejemplo, un proceso que se ejecuta con una cuenta de invitado puede corromper de esta manera a otro proceso que se ejecuta con una cuenta privilegiada. Esta es una razón importante para evitar el uso de secciones compartidas en las DLL.

Si una DLL se comprime con ciertos empaquetadores de ejecutables (por ejemplo , UPX ), todas sus secciones de código se marcan como de lectura y escritura, y no se comparten. Las secciones de código de lectura y escritura, al igual que las secciones de datos privados, son privadas para cada proceso. Por lo tanto, las DLL con secciones de datos compartidas no deben comprimirse si se pretende que las utilicen simultáneamente varios programas, ya que cada instancia del programa tendría que tener su propia copia de la DLL, lo que aumentaría el consumo de memoria.

Al igual que las bibliotecas estáticas, las bibliotecas de importación para DLL se identifican por la .libextensión del archivo. Por ejemplo, kernel32.dll , la biblioteca dinámica principal para las funciones básicas de Windows, como la creación de archivos y la gestión de memoria, se enlaza mediante kernel32.lib. La forma habitual de distinguir una biblioteca de importación de una biblioteca estática propiamente dicha es por su tamaño: la biblioteca de importación es mucho más pequeña, ya que solo contiene símbolos que hacen referencia a la DLL real, que se procesa en tiempo de enlace. Sin embargo, ambas son archivos en formato Unix ar .

La vinculación con bibliotecas dinámicas generalmente se realiza mediante la vinculación a una biblioteca de importación al compilar o vincular para crear un archivo ejecutable. El ejecutable resultante contiene una tabla de direcciones de importación (IAT) que referencia todas las llamadas a funciones de la DLL (cada función de la DLL referenciada contiene su propia entrada en la IAT). En tiempo de ejecución, la IAT se completa con las direcciones apropiadas que apuntan directamente a una función en la DLL cargada por separado. ^{[ 3 ]}

En Cygwin/MSYS y MinGW, las bibliotecas de importación reciben convencionalmente el sufijo .dll.a, que combina el sufijo DLL de Windows y el sufijo ar de Unix. El formato de archivo es similar, pero los símbolos utilizados para marcar las importaciones son diferentes ( _head_foo_dllvs __IMPORT_DESCRIPTOR_foo). ^{[ 4 ]} Aunque su conjunto de herramientas GNU Binutils puede generar bibliotecas de importación y enlazarlas, es más rápido enlazar directamente con la DLL. ^{[ 5 ]} Una herramienta experimental en MinGW llamada genlib puede utilizarse para generar bibliotecas de importación con símbolos al estilo MSVC.

Cada función exportada por una DLL se identifica mediante un ordinal numérico y, opcionalmente, un nombre. Del mismo modo, las funciones pueden importarse desde una DLL mediante su ordinal o su nombre. El ordinal representa la posición del puntero de dirección de la función en la tabla de direcciones de exportación de la DLL. Es común que las funciones internas se exporten únicamente mediante su ordinal. Para la mayoría de las funciones de la API de Windows, solo se conservan los nombres entre las distintas versiones de Windows; los ordinales pueden cambiar. Por lo tanto, no es fiable importar funciones de la API de Windows mediante sus ordinales.

La importación de funciones por ordinal ofrece un rendimiento solo ligeramente superior al de importarlas por nombre: las tablas de exportación de las DLL están ordenadas por nombre, por lo que se puede usar una búsqueda binaria para encontrar una función. El índice del nombre encontrado se utiliza para consultar el ordinal en la tabla de ordinales de exportación. En Windows de 16 bits, la tabla de nombres no estaba ordenada, por lo que la sobrecarga de la búsqueda de nombres era mucho más notable.

También es posible vincular un ejecutable a una versión específica de una DLL, es decir, resolver las direcciones de las funciones importadas en tiempo de compilación. Para las importaciones vinculadas, el enlazador guarda la marca de tiempo y la suma de comprobación de la DLL a la que está vinculada la importación. En tiempo de ejecución, Windows comprueba si se está utilizando la misma versión de la biblioteca y, de ser así, omite el procesamiento de las importaciones. De lo contrario, si la biblioteca es diferente de la vinculada, Windows procesa las importaciones de forma normal.

Los ejecutables vinculados se cargan algo más rápido si se ejecutan en el mismo entorno para el que se compilaron, y exactamente al mismo tiempo si se ejecutan en un entorno diferente, por lo que no hay inconveniente en vincular las importaciones. Por ejemplo, todas las aplicaciones estándar de Windows están vinculadas a las DLL del sistema de su respectiva versión de Windows. Una buena oportunidad para vincular las importaciones de una aplicación a su entorno de destino es durante la instalación de la aplicación. Esto mantiene las bibliotecas "vinculadas" hasta la siguiente actualización del sistema operativo. Sin embargo, cambia la suma de comprobación del ejecutable, por lo que no es algo que se pueda hacer con programas firmados o programas administrados por una herramienta de administración de configuración que utiliza sumas de comprobación (como las sumas de comprobación MD5 ) para administrar las versiones de los archivos. A medida que las versiones más recientes de Windows han dejado de tener direcciones fijas para cada biblioteca cargada (por razones de seguridad), la oportunidad y el valor de vincular un ejecutable están disminuyendo.

Los archivos DLL se pueden cargar explícitamente en tiempo de ejecución, un proceso que Microsoft denomina simplemente enlace dinámico en tiempo de ejecuciónLoadLibrary , mediante la función API (o LoadLibraryEx). La GetProcAddressfunción API se utiliza para buscar símbolos exportados por nombre, y FreeLibrary– para descargar la DLL. Estas funciones son análogas a dlopen, dlsym, y dlcloseen la API estándar POSIX .

El procedimiento para la vinculación explícita en tiempo de ejecución es el mismo en cualquier lenguaje que admita punteros a funciones , ya que depende de la API de Windows y no de las construcciones del lenguaje.

Normalmente, una aplicación vinculada a la biblioteca de importación de una DLL no se iniciará si no encuentra la DLL, ya que Windows no la ejecutará a menos que encuentre todas las DLL que pueda necesitar. Sin embargo, una aplicación puede vincularse a una biblioteca de importación para permitir la carga diferida de la biblioteca dinámica. ^{[ 6 ]} En este caso, el sistema operativo no intentará encontrar ni cargar la DLL al iniciar la aplicación; en su lugar, el enlazador incluye un fragmento de código en la aplicación que intentará encontrar y cargar la DLL LoadLibrarycuando GetProcAddressse llame a una de sus funciones. Si no se encuentra o no se carga la DLL, o si la función llamada no existe, la aplicación generará una excepción , que puede ser capturada y gestionada adecuadamente. Si la aplicación no gestiona la excepción, el sistema operativo la capturará y finalizará el programa con un mensaje de error.

El mecanismo de carga diferida también proporciona puntos de notificación , lo que permite a la aplicación realizar un procesamiento adicional o gestionar errores cuando se carga la DLL o se llama a cualquier función de la DLL.

En un archivo fuente, libraryse utiliza la palabra clave en lugar de program. Al final del archivo, las funciones que se exportarán se enumeran en exportsla cláusula.

Delphi no necesita LIBarchivos para importar funciones de DLL; para vincularse a una DLL, externalse utiliza la palabra clave en la declaración de la función para indicar el nombre de la DLL, seguido de namepara nombrar el símbolo (si es diferente) o indexpara identificar el índice.

En Visual Basic (VB), solo se admite la vinculación en tiempo de ejecución; pero además de usar funciones LoadLibraryAPI GetProcAddress, se permiten declaraciones de funciones importadas.

Al importar funciones DLL mediante declaraciones, VB generará un error en tiempo de ejecución si DLLno se encuentra el archivo. El desarrollador puede capturar el error y gestionarlo adecuadamente.

Al crear DLL en VB, el IDE solo permite la creación de DLL ActiveX; sin embargo, se han creado métodos ^{[ 7 ]} para que el usuario pueda indicarle explícitamente al enlazador que incluya un archivo .DEF que define la posición ordinal y el nombre de cada función exportada. Esto permite al usuario crear una DLL estándar de Windows usando Visual Basic (versión 6 o inferior) a la que se puede hacer referencia mediante una instrucción "Declare".

Microsoft Visual C++ (MSVC) proporciona varias extensiones al estándar C++ que permiten especificar funciones como importadas o exportadas directamente en el código C++; estas han sido adoptadas por otros compiladores de C y C++ para Windows, incluidas las versiones de GCC para Windows . Estas extensiones utilizan el atributo __declspecantes de la declaración de una función. Cabe destacar que, cuando se accede a funciones C desde C++, también deben declararse como extern "C"en el código C++, para informar al compilador de que debe utilizarse el enlace C. ^{[ 8 ]}

Además de especificar las funciones importadas o exportadas mediante __declspecatributos, estas pueden aparecer en la sección IMPORT o EXPORTS del DEFarchivo utilizado por el proyecto. DEFEl enlazador, en lugar del compilador, procesa este archivo, por lo que no es específico de C++.

La compilación de la DLL generará archivos de importación DLL. LIBEl LIBarchivo (biblioteca de importación) se utiliza para enlazar con una DLL en tiempo de compilación; no es necesario para el enlace en tiempo de ejecución. A menos que la DLL sea un servidor del Modelo de Objetos Componentes (COM), el DLLarchivo debe ubicarse en uno de los directorios listados en la variable de entorno PATH, en el directorio predeterminado del sistema o en el mismo directorio que el programa que lo utiliza. Las DLL de servidor COM se registran mediante regsvr32.exe, que coloca la ubicación de la DLL y su identificador único global ( GUID ) en el registro. Los programas pueden entonces usar la DLL buscando su GUID en el registro para encontrar su ubicación o crear una instancia del objeto COM indirectamente utilizando su identificador de clase e identificador de interfaz.

Los siguientes ejemplos muestran cómo usar enlaces específicos del lenguaje para importar símbolos para la vinculación con una DLL en tiempo de compilación.

Delfos

{$APPTYPE CONSOLE}Ejemplo de programa ;// Importar función que suma dos números function AddNumbers ( a , b : Double ) : Double ; StdCall ; external 'Example.dll' ;// programa principal var R : Double ;begin R := AddNumbers ( 1 , 2 ) ; Writeln ( 'El resultado fue: ' , R ) ; end .

do

El archivo 'Example.lib' debe incluirse (suponiendo que se genere Example.dll) en el proyecto antes del enlace estático. El compilador genera automáticamente el archivo 'Example.lib' al compilar la DLL. Si no se ejecuta la instrucción anterior, se producirá un error de enlace, ya que el enlazador no sabrá dónde encontrar la definición AddNumbers. También es posible que sea necesario copiar el archivo DLL 'Example.dll' a la ubicación donde se generará el archivo .exe mediante el siguiente código:

#include <windows.h> #include <stdio.h>// Importa la función que suma dos números extern "C" __declspec ( dllimport ) double AddNumbers ( double a , double b );int main ( int argc , char * argv []) { double result = AddNumbers ( 1 , 2 ); printf ( "El resultado fue: %f \n " , result ); return 0 ; }

Los siguientes ejemplos muestran cómo utilizar las funciones de carga y vinculación en tiempo de ejecución mediante enlaces de API de Windows específicos del lenguaje.

Tenga en cuenta que las cuatro muestras son vulnerables a ataques de precarga de DLL , ya que example.dll puede resolverse en una ubicación no prevista por el autor (el directorio de trabajo actual precede a las ubicaciones de las bibliotecas del sistema) y, por lo tanto, en una versión maliciosa de la biblioteca. Consulte la referencia para obtener la guía de Microsoft sobre la carga segura de bibliotecas: se debe usar SetDllDirectoryWpara kernel32eliminar la búsqueda del directorio actual antes de que se carguen las bibliotecas. ^{[ 9 ]}

Option Explicit Declare Function AddNumbers Lib "Example.dll" _ ( ByVal a As Double , ByVal b As Double ) As DoubleSub Main () Dim Resultado As Double Resultado = AgregarNúmeros ( 1 , 2 ) Debug.Print "El resultado fue : " & Resultado End Sub

programa Ejemplo ; {$APPTYPE CONSOLE} usa Windows ; var AddNumbers : function ( a , b : integer ) : Double ; StdCall ; LibHandle : HMODULE ; begin LibHandle := LoadLibrary ( 'example.dll' ) ; if LibHandle <> 0 then AddNumbers := GetProcAddress ( LibHandle , 'AddNumbers' ) ; if Assigned ( AddNumbers ) then Writeln ( '1 + 2 = ' , AddNumbers ( 1 , 2 ) ) ; Readln ; end .

#include <windows.h> #include <stdio.h>// Firma de la función DLL typedef double ( * importFunction )( double , double );int main ( int argc , char ** argv ) { importFunction addNumbers ; double result ; HINSTANCE hinstLib ;// Cargar archivo DLL hinstLib = LoadLibrary ( TEXT ( "Example.dll" )); if ( hinstLib == NULL ) { printf ( "ERROR: no se pudo cargar la DLL \n " ); return 1 ; }// Obtener puntero a función addNumbers = ( importFunction ) GetProcAddress ( hinstLib , "AddNumbers" ); if ( addNumbers == NULL ) { printf ( "ERROR: no se pudo encontrar la función DLL \n " ); FreeLibrary ( hinstLib ); return 1 ; }// Llamar a la función. resultado = agregarNúmeros ( 1 , 3 );// Descargar el archivo DLL FreeLibrary ( hinstLib );// Mostrar resultado printf ( "El resultado fue: %f \n " , resultado );devolver 0 ; }

importar ctypesmy_dll = ctipos . cdll . LoadLibrary ( "Ejemplo.dll" )# La siguiente especificación del método "restype" es necesaria para que # Python entienda qué tipo devuelve la función. my_dll . AddNumbers . restype = ctypes . c_doublep = my_dll.AddNumbers ( ctypes.c_double ( 1.0 ) , ctypes.c_double ( 2.0 ) )​​​​imprimir ( "El resultado fue:" , p )