Cómo cargar de forma dinámica las bibliotecas de vínculos dinámicos (DLL) en Windows NT

IMPORTANTE: Este artículo ha sido traducido por un software de traducción automática de Microsoft (http://support.microsoft.com/gp/mtdetails) en lugar de un traductor humano. Microsoft le ofrece artículos traducidos por un traductor humano y artículos traducidos automáticamente para que tenga acceso en su propio idioma a todos los artículos de nuestra base de conocimientos (Knowledge Base). Sin embargo, los artículos traducidos automáticamente pueden contener errores en el vocabulario, la sintaxis o la gramática, como los que un extranjero podría cometer al hablar el idioma. Microsoft no se hace responsable de cualquier imprecisión, error o daño ocasionado por una mala traducción del contenido o como consecuencia de su utilización por nuestros clientes. Microsoft suele actualizar el software de traducción frecuentemente.

Haga clic aquí para ver el artículo original (en inglés): 100635
Resumen
Cuando utiliza la función LoadLibrary() en Windows de 16 bits o en OS/2, el sistema operativo carga la biblioteca de vínculos dinámicos (DLL) especificada sólo una vez. Por lo tanto, el archivo DLL tiene la misma dirección en cada proceso. Sin embargo, la carga dinámica de archivos DLL funciona de forma diferente en Windows NT.

El sistema operativo carga un archivo DLL por separado para cada proceso, ya que cada aplicación tiene su propio espacio de direcciones de Windows NT; se comparte el espacio de direcciones en Windows de 16 bits y en OS/2. Dado que el sistema operativo debe asignar páginas en el espacio de direcciones para cada proceso, se puede cargar la DLL en diferentes direcciones en diferentes procesos. El Administrador de memoria optimiza cargar archivos DLL de modo que si dos procesos comparten las mismas páginas desde la misma imagen DLL, comparten la misma memoria física.

Cada archivo DLL tiene una dirección base preferida, especificada en el momento de la vinculación. Si el intervalo de espacio de direcciones de la dirección base preferida a la dirección base más el tamaño de la imagen no está disponible, el sistema operativo carga el archivo DLL en otro lugar de la memoria y se aplica a las reparaciones en sus direcciones. No hay ningún método para especificar la dirección de carga en tiempo de carga.

En resumen, el sistema realiza los pasos siguientes en tiempo de carga:
  1. Examina la imagen y determina su dirección base preferida y el tamaño necesario.
  2. Busca el espacio de direcciones requerido y asigna la imagen de copia por escritura del archivo.
  3. Aplica las correcciones internas si la imagen no está en la dirección base de itspreferred.
  4. Revisiones de seguridad de todas las importaciones de enlace dinámico colocando el correctaddress para cada función importada en la entrada correspondiente de la tabla ImportAddress. Esta tabla almacena las direcciones de 32 bits de forma contigua; para almacenar hasta to1024 funciones importadas requiere sucio sólo una memoria de página.
Más información
Se comparten las páginas que contienen código, mediante un esquema de protección de copia por escritura. Copy-on-write significa que una página es de sólo lectura; Sin embargo, si un proceso se escribe en la infracción de acceso y la página no se produce. En su lugar, el Administrador de memoria realiza una copia privada de la página para el uso de la aplicación y permite la escritura continuar. Por ejemplo, si dos procesos de inician de la misma. Archivo EXE, cada proceso tiene inicialmente todas las páginas asignadas de la. EXE file copy-on-write. Los dos procesos de continuar para modificar páginas, cada uno recibe una copia privada de las páginas modificadas. El Administrador de memoria es gratuito para optimizar las páginas sin modificar y asignar la misma memoria física en el espacio de direcciones de ambos procesos. Se intercambian las páginas modificadas a y desde el archivo de paginación en lugar de la. Archivo EXE.

Existen dos tipos de reparaciones. La primera se utiliza para la dirección de una función importada. Según la especificación de archivo ejecutable Portable, este tipo de corrección se almacena en Import Address Table (IAT), una matriz de punteros a función de 32 bits, uno para cada función importada. La tabla IAT tiene su propia página o páginas porque siempre se ha modificado. Una llamada a una función importada es en realidad una llamada indirecta a través de la entrada correspondiente en la tabla IAT. Cuando se carga una imagen en su dirección base preferida, las correcciones de la función importada son las reparaciones sólo requeridas.

Tenga en cuenta que una optimización está disponible según el cual cada biblioteca de importación exporta un número de 32 bits que se corresponde con cada función además de cualquier nombre o número ordinal. Esto actúa como una "indicación" a la velocidad que las correcciones se realizan en tiempo de carga. Si no coinciden las sugerencias en la aplicación y en la DLL cargada, el cargador realiza una búsqueda binaria basada en el nombre de la función.

El otro tipo de corrección es necesario para las referencias al código o datos de la imagen cuando la imagen cargan en otra que en su dirección base preferida. Cuando el Administrador de memoria quita una página de la memoria, comprueba que se ha modificado ver de la página. Si no es así, la página conserva su asignación de copia por escritura y pueden ser desechado de la memoria. De lo contrario, se deben escribirse en el archivo de página para que la página modificada se pueden recuperar desde el archivo de paginación en lugar del archivo de imagen ejecutable.

Incluso si una aplicación llama a LoadLibrary() más de una vez para un archivo DLL, el punto de entrada DLL, DllMain(), se llama sólo una vez y se crea sólo una entrada DLL_PROCESS_ATTACH. De forma similar, si la aplicación llama FreeLibrary() más de una vez, DLL_PROCESS_DETACH sólo se produce para la llamada en que la referencia a la DLL cuenta vuelve a cero.

Datos de instancia global para el archivo DLL se almacenan en una base por proceso (sólo un conjunto de datos por proceso). Si es necesario almacenar los datos de instancia global de cada llamada a LoadLibrary() realizada en un proceso, considere la posibilidad de utilizar almacenamiento local de subprocesos (TLS) como alternativa. Si utiliza varios subprocesos de ejecución, TLS proporciona almacenamiento de datos únicos para cada valor ThreadID. Este proceso requiere muy poca sobrecarga para el archivo DLL; sólo debe crear un índice TLS global en el proceso de inicialización. En la inicialización de subproceso, utilice GlobalAlloc(), HeapAlloc(), LocalAlloc(), las funciones de la biblioteca de tiempo de ejecución de C, u otro método para asignar un bloque de memoria y llamar a la función TlsSetValue() para almacenar un puntero a la memoria con el valor de índice global de TLS. Win32 almacena internamente puntero de cada subproceso indizada por índice TLS y ThreadID para proporcionar almacenamiento de información específica de subprocesos.

Advertencia: este artículo se tradujo automáticamente

Propiedades

Id. de artículo: 100635 - Última revisión: 09/05/2015 05:29:00 - Revisión: 8.0

Microsoft Visual C++ 2.0 Professional Edition, Microsoft Visual C++ 5.0 Enterprise Edition, Microsoft Visual C++ 5.0 Professional, Microsoft Visual C++ .NET 2002 Standard, Microsoft Visual C++ .NET 2003 Standard, Microsoft Visual C++ 2005 Express Edition

  • kbdll kbhowto kbinfo kblangc kbmt KB100635 KbMtes
Comentarios