El sistema operativo Microsoft Windows admite una forma de bibliotecas compartidas conocidas como " bibliotecas de vínculo dinámico ", que son bibliotecas de código que pueden ser utilizadas por múltiples procesos mientras que solo una copia se carga 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 que utilizan los programas.
La capa de abstracción de hardware de Windows (HAL) se implementa en hal.dll . [1] La HAL implementa una serie de funciones que se implementan de diferentes maneras en diferentes plataformas de hardware, lo que en este contexto se refiere principalmente al chipset . Otros componentes del sistema operativo pueden llamar a estas funciones de la misma manera en todas las plataformas, sin tener en cuenta la implementación real.
Por ejemplo, la respuesta 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. El HAL proporciona una única función para este propósito que funciona con todo tipo de interrupciones de varios chipsets, de modo que los demás componentes no tienen que preocuparse por las diferencias.
La HAL se carga en el espacio de direcciones del núcleo y se ejecuta en modo núcleo, por lo que las rutinas de la HAL no pueden ser llamadas directamente por las aplicaciones y ninguna API de modo de usuario corresponde directamente a las rutinas de la HAL. En cambio, la HAL proporciona servicios principalmente al ejecutivo y al núcleo de Windows y a los controladores de dispositivos de modo núcleo. Aunque los controladores para la mayoría del hardware están contenidos en otros archivos, normalmente de tipo .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 la HAL para acceder a los puertos de E/S y registros de sus dispositivos. Los controladores utilizan rutinas HAL porque diferentes plataformas pueden requerir diferentes implementaciones de estas operaciones. La HAL implementa las operaciones de forma adecuada para cada plataforma, por lo que el mismo archivo ejecutable del controlador se puede utilizar en todas las plataformas que utilicen la misma arquitectura de CPU , y el archivo fuente del controlador se puede transferir a todas las arquitecturas.
En los sistemas x86 anteriores a Windows 8 , hay varios archivos HAL diferentes en el medio de instalación. El procedimiento de instalación de Windows determina cuáles son apropiados para la plataforma actual y los copia al disco duro, renombrándolos como 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 multinúcleo , e incluso los "procesadores lógicos" implementados por una CPU con hiperprocesamiento , todos cuentan como "procesadores" para este propósito). En las plataformas x86-64 e Itanium , solo hay un hal.dll posible 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 un código auxiliar para compatibilidad con versiones anteriores.
NTDLL.DLL exporta la API nativa de Windows . La API nativa es la interfaz que utilizan los componentes en modo usuario del sistema operativo que deben ejecutarse sin soporte de Win32 u otros subsistemas de 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 núcleo" o "API base" exportadas por KERNEL32.DLL. [3] [4] [5] La gran mayoría de las aplicaciones de Windows no llaman a NTDLL.DLL directamente. [6]
Se dice que las aplicaciones que están vinculadas directamente con esta biblioteca utilizan el subsistema nativo ; la razón principal de su existencia es realizar tareas que deben ejecutarse al principio de 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. El propio csrss.exe es una de esas aplicaciones.
A pesar de tener una extensión de archivo ".exe", las aplicaciones nativas no pueden ser ejecutadas por el usuario (ni por 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 se instancian dentro del código de ejecución del núcleo ( 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] obtienen sus argumentos de línea de comandos a través de un puntero a una estructura en memoria, administran su propia memoria utilizando la API de montón Rtl (que las API de montón Win32 son solo envoltorios, no hay una diferencia real allí) y devuelven la ejecución con una llamada a RtlExitUserProcess (a diferencia de ExitProcess ). Una biblioteca común vinculada con las aplicaciones nativas es nt.lib, que contiene código de inicio para aplicaciones nativas, similar a cómo el entorno de ejecución C proporciona código de inicio para aplicaciones Win32. [7]
Aunque la mayor parte de la API no está documentada, se pueden crear aplicaciones nativas utilizando el Kit de desarrollo de controladores de Windows; muchos proveedores de software antivirus y otros programas de utilidad incorporan aplicaciones nativas dentro de sus productos, generalmente para realizar alguna tarea de arranque que no se puede llevar a cabo en el espacio de usuario . [ cita requerida ]
Las bibliotecas de esta sección implementan 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. [8]
GDI32.DLL exporta funciones de Interfaz de Dispositivo Gráfico (GDI) que realizan funciones de dibujo primitivas para la salida a pantallas de vídeo e impresoras. Se utiliza, por ejemplo, en la versión XP de Paint. Las aplicaciones llaman a las funciones GDI directamente para realizar dibujos de bajo nivel (líneas, rectángulos, elipses), salida de texto, gestión de fuentes y funciones similares. [8] [9]
Inicialmente, GDI admitía tarjetas gráficas EGA / VGA de 16 y 256 colores e impresoras monocromáticas . La funcionalidad se ha ampliado con el paso de los años y ahora incluye compatibilidad con elementos como fuentes TrueType , canales alfa y varios monitores . [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. De este modo, permite que los programas implementen una interfaz gráfica de usuario (GUI) que coincida con el aspecto de Windows. Los programas invocan funciones de USER de Windows para realizar operaciones como crear y administrar ventanas, recibir mensajes de ventana (que son principalmente entradas del usuario, como eventos del mouse y del teclado, pero también notificaciones del sistema operativo), mostrar texto en una ventana y mostrar cuadros de mensajes.
Muchas de las funciones de USER32.DLL invocan 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 invocarán funciones GDI directamente para realizar operaciones de dibujo de nivel inferior dentro de una ventana creada previamente mediante funciones USER32.
COMCTL32.DLL implementa una amplia variedad de controles estándar de Windows, como los cuadros de diálogo Abrir archivo, Guardar y Guardar como, barras de progreso y vistas de lista. Llama a funciones de USER32.DLL y GDI32.DLL para crear y administrar las ventanas de estos elementos de la interfaz de usuario, colocar varios elementos gráficos dentro de ellas y recopilar la información del usuario.
COMDLG32.DLL , la biblioteca de cuadros de diálogo comunes, implementa una amplia variedad de cuadros de diálogo de Windows diseñados para realizar lo que Microsoft considera "tareas de aplicación 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 han sido reemplazados por la "API de diálogo de elementos comunes". [11]
WS2_32.DLL implementa la API 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 la compatibilidad con Win3.11 y Win95.
ADVAPI32.DLL , la DLL de la API base 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 compatibilidad con archivos de chatarra de shell , que se crean automáticamente cuando arrastra contenido seleccionado desde una aplicación compatible con OLE a una ventana del Explorador o al escritorio, [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 fue eliminada de Windows Vista (y por lo tanto de versiones posteriores) para mejorar la seguridad y liberar al sistema operativo de funcionalidades generalmente no utilizadas. [14] Los archivos scrap (.shs) han sido utilizados por virus porque pueden contener una amplia variedad de archivos (incluido código ejecutable) y la extensión del archivo no se muestra incluso cuando la opción "Ocultar extensiones de archivo de tipos de archivo conocidos" está deshabilitada. [15] La funcionalidad se puede restaurar copiando las entradas del registro y la DLL desde un sistema Windows XP . [16]
WINMM.DLL proporciona acceso a la API de audio WinMM original .
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 Visual C++ (MSVC) de la versión 4.2 a la 6.0. Proporciona a los programas compilados por estas versiones de MSVC la mayoría de las funciones estándar de la biblioteca de C. Entre ellas se incluyen la manipulación de cadenas, la asignación de memoria, las llamadas de entrada/salida al estilo C y otras. MSVCP*.DLL es la biblioteca de C++ correspondiente.
Se incluye en las versiones de Windows desde Windows 95 OSR2.5 para su uso por parte de otros componentes de Windows; las versiones anteriores se entregaban con la biblioteca CRTDLL.DLL en su lugar. En versiones anteriores de Windows, se esperaba que los programas que se vinculaban con MSVCRT.DLL instalaran una copia compatible en la carpeta System32, pero esto contribuía al problema de las DLL porque muchos instaladores no comprobaban 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 utilizaban archivos DLL con nombres diferentes para cada versión (MSVCR20.DLL, MSVCR70.DLL, MSVCR71.DLL, MSVCP110.DLL, etc.). Las aplicaciones deben instalar la versión adecuada [17] y Microsoft ofrece paquetes redistribuibles de Visual C++ para este propósito, aunque Windows normalmente viene con una versión ya instalada.
Esta biblioteca de tiempo de ejecución la utilizan los programas escritos en Visual C++ y algunos otros compiladores (por ejemplo, MinGW ). Algunos compiladores tienen sus propias bibliotecas de tiempo de ejecución.
Con la versión 14.0 ( Visual Studio 2015 ), la mayor parte del entorno de ejecución de C/C++ se trasladó a una nueva DLL, UCRTBASE.DLL, que se ajusta estrechamente a C99[1]. Universal C Run Time ( UCRT ) a partir de Windows 10 se convirtió 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 usan UCRTBASE.DLL se ven obligados a vincularse con otra nueva DLL, VCRuntime. En la versión 14.0, esta 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 – Multilanguage Standard Common Object Runtime Library, anteriormente Microsoft Common Object Runtime Library [20] ) y los llamados ensamblajes (por ejemplo, System.Windows.Forms.dll ).
