El sistema operativo Microsoft Windows admite una forma de bibliotecas compartidas conocidas como " bibliotecas de vínculos dinámicos ", que son bibliotecas de código que pueden ser utilizadas por múltiples procesos mientras solo se carga una copia en la memoria . Este artículo proporciona una descripción general de las bibliotecas principales que se incluyen con cada instalación moderna de Windows, sobre las cuales se crean la mayoría de las aplicaciones de Windows.
HAL.DLL es un archivo de biblioteca en modo kernel y no puede ser utilizado por ningún programa en modo usuario. NTDLL.DLL solo lo utilizan algunos programas, pero es una dependencia de la mayoría de las bibliotecas Win32 utilizadas por los programas.
La capa de abstracción de hardware (HAL) de Windows se implementa en hal.dll . [1] HAL implementa una serie de funciones que se implementan de diferentes maneras según las diferentes plataformas de hardware, lo que en este contexto se refiere principalmente al chipset . Otros componentes del sistema operativo pueden entonces llamar a estas funciones de la misma manera en todas las plataformas, sin tener en cuenta la implementación real.
Por ejemplo, responder a una interrupción es bastante diferente en una máquina con un Controlador de Interrupciones Programable Avanzado (APIC) que en una que no lo tiene. HAL proporciona una única función para este propósito que funciona con todo tipo de interrupciones mediante varios conjuntos de chips, de modo que otros componentes no necesitan preocuparse por las diferencias.
HAL se carga en el espacio de direcciones del kernel y se ejecuta en modo kernel, por lo que las aplicaciones no pueden llamar directamente a las rutinas en HAL y ninguna API en modo de usuario se corresponde directamente con las rutinas HAL. En cambio, HAL proporciona servicios principalmente al ejecutivo y al kernel de Windows y a los controladores de dispositivos en modo kernel. Aunque los controladores para la mayor parte del hardware están contenidos en otros archivos, comúnmente del tipo de archivo .sys , algunos controladores principales se compilan en hal.dll .
Los controladores de dispositivos en modo kernel para dispositivos en buses como PCI y PCI Express llaman directamente a rutinas en HAL para acceder a los puertos de E/S y a los registros de sus dispositivos. Los controladores utilizan rutinas HAL porque diferentes plataformas pueden requerir diferentes implementaciones de estas operaciones. HAL implementa las operaciones de forma adecuada para cada plataforma, por lo que se puede utilizar el mismo archivo ejecutable del controlador en todas las plataformas utilizando la misma arquitectura de CPU , y el archivo fuente del controlador puede ser portátil en todas las arquitecturas.
En sistemas x86 anteriores a Windows 8 , hay varios archivos HAL diferentes en los medios de instalación. El procedimiento de instalación de Windows determina cuáles son apropiados para la plataforma actual y los copia en el disco duro, renombrándolos a hal.dll si es necesario. Entre los criterios para esta selección se encuentran: la presencia de un BIOS compatible con ACPI , la presencia de un APIC y si hay o no varios procesadores presentes y habilitados. (Los múltiples núcleos de una CPU de múltiples núcleos , e incluso los "procesadores lógicos" implementados por una CPU con hyperthreading , cuentan como "procesadores" para este propósito). En las plataformas x86-64 e Itanium solo hay un posible hal.dll para cada arquitectura de CPU. En Windows 8 y posteriores, la versión x86 también tiene solo un HAL.
HAL se fusiona (o se vincula estáticamente) en ntoskrnl.exe [2] a partir de la versión 2004 de Windows 10, y el dll solo sirve como código auxiliar para compatibilidad con versiones anteriores.
NTDLL.DLL exporta la API nativa de Windows . La API nativa es la interfaz utilizada por los componentes en modo de usuario del sistema operativo que deben ejecutarse sin soporte de Win32 u otros subsistemas API. La mayor parte de esta API se implementa en NTDLL.DLL y en el borde superior de ntoskrnl.exe (y sus variantes), y la mayoría de los símbolos exportados dentro de estas bibliotecas tienen el prefijo Nt , por ejemplo NtDisplayString . Las API nativas también se utilizan para implementar muchas de las "API del kernel" o "API base" exportadas por KERNEL32.DLL. [3] [4] [5] La gran mayoría de las aplicaciones de Windows no llaman directamente a NTDLL.DLL. [6]
Se dice que las aplicaciones que están vinculadas directamente a esta biblioteca utilizan el subsistema nativo ; la razón principal de su existencia es realizar tareas que deben ejecutarse temprano en la secuencia de inicio del sistema antes de que el subsistema Win32 esté disponible. Un ejemplo obvio pero importante es la creación del proceso del subsistema Win32, csrss.exe . Antes de que exista el proceso csrss.exe, no se pueden crear procesos Win32, por lo tanto, el proceso que lo crea (Smss.exe, el "administrador de sesiones") debe utilizar el subsistema nativo. csrss.exe en sí es una aplicación de este tipo.
A pesar de tener una extensión de archivo ".exe", el usuario no puede ejecutar aplicaciones nativas (ni ningún programa en Win32 u otros subsistemas). Un ejemplo es el binario autochk.exe que ejecuta chkdsk durante la "pantalla azul" de inicialización del sistema. Otros ejemplos destacados son los servicios que implementan los distintos subsistemas, como csrss.exe .
A diferencia de las aplicaciones Win32 , las aplicaciones nativas crean instancias dentro del código de tiempo de ejecución del Kernel ( ntoskrnl.exe ) y, por lo tanto, deben tener un punto de entrada diferente ( NtProcessStartup , en lugar de (w)(Win)MainCRTStartup como se encuentra en una aplicación Win32), [4] obtenga sus argumentos de línea de comandos a través de un puntero a una estructura en memoria, administre su propia memoria usando la API del montón Rtl (que las API del montón de Win32 son solo envoltorios, no hay una diferencia real allí) y devuelva la ejecución con una llamada a RtlExitUserProcess (a diferencia de ExitProcess ). Una biblioteca común vinculada con aplicaciones nativas es nt.lib, que contiene código de inicio para aplicaciones nativas, similar a cómo el tiempo de ejecución C proporciona código de inicio para aplicaciones Win32. [7]
Aunque la mayor parte de la API no está documentada, las aplicaciones nativas se pueden crear utilizando el kit de desarrollo de controladores de Windows; Muchos proveedores de software antivirus y otros software de utilidad incorporan aplicaciones nativas en sus productos, generalmente para realizar alguna tarea durante el arranque que no se puede realizar en el espacio de usuario . [ cita necesaria ]
Cada una de las bibliotecas de esta sección implementa varios subconjuntos de la API de Win32.
KERNEL32.DLL expone a las aplicaciones la mayoría de las API base de Win32, como administración de memoria , operaciones de entrada/salida (E/S) , creación de procesos y subprocesos y funciones de sincronización. Muchos de estos se implementan dentro de KERNEL32.DLL llamando a las funciones correspondientes en la API nativa , expuesta por NTDLL.DLL. [8] [ verificación fallida ]
GDI32.DLL exporta funciones de interfaz de dispositivo gráfico (GDI) que realizan funciones de dibujo primitivas para su salida a pantallas de vídeo e impresoras. Se utiliza, por ejemplo, en la versión XP de Paint. Las aplicaciones llaman directamente a funciones GDI para realizar dibujos de bajo nivel (línea, rectángulo, elipse), salida de texto, administración de fuentes y funciones similares. [8] [9]
Inicialmente, GDI admitía tarjetas de visualización EGA / VGA de 16 y 256 colores e impresoras monocromáticas . La funcionalidad se ha ampliado a lo largo de los años y ahora incluye soporte para cosas como fuentes TrueType , canales alfa y monitores múltiples . [10]
USER32.DLL implementa el componente USER de Windows que crea y manipula los elementos estándar de la interfaz de usuario de Windows, como el escritorio, las ventanas y los menús. Por lo tanto, permite que los programas implementen una interfaz gráfica de usuario (GUI) que coincida con la apariencia de Windows. Los programas llaman a funciones del USUARIO de Windows para realizar operaciones como crear y administrar ventanas, recibir mensajes de ventana (que en su mayoría son entradas del usuario, como eventos del mouse y el teclado, pero también notificaciones del sistema operativo), mostrar texto en una ventana y mostrar mensajes. cajas.
Muchas de las funciones de USER32.DLL recurren a funciones GDI exportadas por GDI32.DLL para realizar la representación real de los distintos elementos de la interfaz de usuario. Algunos tipos de programas también llamarán a funciones GDI directamente para realizar operaciones de dibujo de nivel inferior dentro de una ventana creada previamente mediante funciones USER32.
COMDLG32.DLL , la biblioteca de cuadros de diálogo comunes, implementa una amplia variedad de cuadros de diálogo de Windows destinados a realizar lo que Microsoft considera "tareas de aplicaciones comunes". A partir del lanzamiento de Windows Vista, Microsoft considera que los cuadros de diálogo "Abrir" y "Guardar como" proporcionados por esta biblioteca están obsoletos y reemplazados por la 'API de diálogo de elementos comunes'. [11]
WS2_32.DLL implementa la API de Winsock , que proporciona funciones de red TCP/IP y proporciona compatibilidad parcial e interrumpida con otras API de red. wsock.dll y wsock32.dll son versiones anteriores para compatibilidad con Win3.11 y Win95.
ADVAPI32.DLL , la DLL API básica avanzada de Windows 32, [12] proporciona llamadas de seguridad y funciones para manipular el Registro de Windows .
NETAPI32.DLL proporciona funciones para consultar y administrar interfaces de red.
OLE32.DLL proporciona el modelo de objetos componentes , así como la vinculación e incrustación de objetos .
SHSCRAP.DLL es parte del mecanismo de vinculación e incrustación de objetos (OLE) . Implementa soporte para archivos de recorte de shell , que se crean automáticamente cuando arrastra contenido seleccionado desde una aplicación compatible con OLE a una ventana o escritorio del Explorador, [13] pero también puede usar el Empaquetador de objetos para crearlos. Luego se pueden arrastrar a otra aplicación compatible con OLE.
Esta funcionalidad se eliminó de Windows Vista (y, por lo tanto, de versiones posteriores) para mejorar la seguridad y eliminar del sistema operativo funciones generalmente no utilizadas. [14] Los virus han utilizado archivos de desecho (.shs) porque pueden contener una amplia variedad de archivos (incluido el código ejecutable) y la extensión del archivo no se muestra incluso cuando "Ocultar extensiones de archivo de tipos de archivos conocidos" está deshabilitado. [15] La funcionalidad se puede restaurar copiando las entradas del registro y la DLL de un sistema Windows XP . [dieciséis]
WINMM.DLL proporciona acceso a la API de audio original de WinMM .
IMM32 es responsable de invocar e interactuar con el Editor de métodos de entrada .
MSVCRT.DLL es la biblioteca estándar de C para el compilador de Visual C++ (MSVC) desde la versión 4.2 a 6.0. Proporciona programas compilados por estas versiones de MSVC con la mayoría de las funciones de la biblioteca C estándar. Estos incluyen manipulación de cadenas, asignación de memoria, llamadas de entrada/salida estilo C y otros. MSVCP*.DLL es la biblioteca C++ correspondiente.
Se envía con versiones de Windows desde Windows 95 OSR2.5 para que lo utilicen otros componentes de Windows; En su lugar , las versiones anteriores se enviaban con la biblioteca CRTDLL.DLL . En versiones anteriores de Windows, se esperaba que los programas vinculados con MSVCRT.DLL instalaran una copia compatible en la carpeta System32, pero esto contribuyó al DLL Hell porque muchos instaladores no pudieron comparar la versión de la biblioteca con la versión instalada antes de reemplazarla.
Las versiones de MSVC anteriores a la 4.0 y de la 7.0 a la 12.0 usaban archivos DLL con nombres diferentes para cada versión (MSVCR20.DLL, MSVCR70.DLL, MSVCR71.DLL, MSVCP110.DLL, etc.). Se requieren aplicaciones para instalar la versión apropiada, [17] y Microsoft ofrece paquetes redistribuibles de Visual C++ para este propósito, aunque Windows generalmente viene con una versión ya instalada.
Esta biblioteca de tiempo de ejecución es utilizada por programas escritos en Visual C++ y algunos otros compiladores (por ejemplo, MinGW ). Algunos compiladores tienen sus propias bibliotecas de ejecución.
Con la versión 14.0 ( Visual Studio 2015 ), la mayor parte del tiempo de ejecución de C/C++ se trasladó a una nueva DLL, UCRTBASE.DLL, que cumple estrictamente con C99[1]. Universal C Run Time (UCRT) desde Windows 10 en adelante se convierte en un componente de Windows[2], por lo que cada compilador (ya sea que no sea MS, como GCC o Clang / LLVM ) puede vincularse con UCRT[3]. Sin embargo, los programas C/C++ que utilizan UCRTBASE.DLL se ven obligados a vincularse con otra DLL nueva, VCRuntime. En la versión 14.0, era VCRUNTIME140.DLL. [18] El nombre tiene el potencial de cambiar en versiones futuras, pero no lo ha hecho hasta la versión 17.0.
El código fuente de las bibliotecas en tiempo de ejecución se incluye en Visual C++ [19] para referencia y depuración (por ejemplo, en C:\Program Files\Microsoft Visual Studio 11.0\VC\crt\src).
Los programas escritos en C# , Visual Basic.NET , C++/CLI y otros lenguajes .NET requieren .NET Framework . Tiene muchas bibliotecas (una de ellas es mscorlib.dll – Biblioteca de tiempo de ejecución de objetos comunes estándar multilenguaje, anteriormente Biblioteca de tiempo de ejecución de objetos comunes de Microsoft [20] ) y los llamados ensamblados (por ejemplo, System.Windows.Forms.dll ).
