Anexo:Bibliotecas DLL de Windows

El sistema operativo Microsoft Windows soporta un tipo de biblioteca compartida conocido como «bibliotecas de enlace dinámico», o DLL, las cuales son bibliotecas de código que pueden ser usadas por múltiples procesos cargando una sola copia de esa biblioteca en memoria. Este anexo da una pequeña explicación de las principales DLLs que vienen incluidas en una instalación moderna de Windows, sobre las cuales dependen y son construidas la mayoría de aplicaciones Windows, y a veces, el mismo sistema.

Componentes internosEditar

Las siguientes bibliotecas no son usadas directamente por las aplicaciones; sino que son dependencias de otras bibliotecas que si son usadas por las aplicaciones, y en general, el sistema depende de ellas.

Hal.dllEditar

La capa de abstracción de hardware de Windows, o «Windows Hardware Abstraction Layer» (HAL) es implementada en el archivo Hal.dll.[1]​ HAL implementa varias funciones que son implementadas de diferentes maneras por diferentes plataformas, que en este contexto, se refiere mayormente al chipset. Otros componentes en el sistema operativo pueden llamar a estas funciones de la misma manera en todas las plataformas, sin importar la implementación actual.

Por ejemplo, responder a una interrupción es diferente en una máquina con Advanced Programmable Interrupt Controller (APIC) y en una sin ella. El HAL provee una sencilla función para este propósito para trabajar con varios tipos de interrupciones para varios chipsets, ya que los otros componentes no necesitan saber de las diferencias.

HAL es cargada dentro del espacio de direcciones del kernel y se ejecuta en modo kernel, algunas rutinas en el archivo HAL no pueden ser llamadas directamente por las aplicaciones, y los modos de usuario en la API no corresponden siempre con las rutinas de HAL. En vez de eso, HAL provee principalmente servicios a Windows, al kernel y a los controladores de dispositivo en modo kernel. Aunque los drivers para la myoría del hardware están contenidos en otros archivos, típicamente en formato .sys, algunos pocos controladores son compilados dentro de Hal.dll.

Los controladores de dispositivo en modo kernel para los dispositivos en buses como las PCI y las PCI Express llaman direcamente a las rutinas de HAL para acceder a los puertos de E/S y los registros de dichos dispositivos. Los controladores usan las rutinas de HAL porque las diferentes plataformas pueden requerir diferentes implementaciones de estas operaciones. HAL implementa las operaciones apropiadas para cada plataforma, así que el mismo controlador ejecutable puede ser usado para todas las plataformas de la misma arquitectura de CPU, y el código fuente es portable para todas las arquitecturas.

En los sistemas x86, hay muchas diferencias entre los archivos hal.dll de diferentes medios de instalación. El procedimiento de instalación de Windowscuáles son apropiados para la plataforma en cuestión, y lo copia al disco duro, renombrandolataformas el archivo a Hal.dll si es necesario. El criterio de selección es el siguiente:

  • La presencia de una BIOS compatible con ACP
  • La presencia de APIC
  • Si hay uno o varios procesadores instalados y activados.
  • En las plataformas x86-64 e Itanium solo es posible cargar un archivo Hal.dll para cada arquitectura de CPU.

NTDLL.DLLEditar

NTDLL.DLL exporta la Windows Native API. Native API ws una interfaz usada por los componentes de Windows que corren en modo usuario que deben ejecutarse sin el soporte de Win32 u otra API del sistema. La mayor parte de esta API es implementada en NTDLL.DLL, y la capa superior de ntoskrnl.exe (y sus variantes), y la mayoría de los símbolos exportados sin estas bibliotecas son prefijadas Nt, por ejemplo, NtDisplayString. Las Native APIs también son usadas para implementar muchas de las "kernel APIs" o "base APIs" exportadas por KERNEL32.DLL.[2][3][4]​ La gran mayoría de las aplicaciones Windows nunca llaman a NTDLL.DLL directamente.[5]

Las aplicaciones que son enlazadas con esta biblioteca son conocidas como aplicaciones nativas; la principal razón de su existencia es para mejorar el rendimiento de tareas que deben correr primero en la secuencia de arranque 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 el proceso csrss.exe exista no puede crearse ningún proceso Win32, por lo que el proceso que lo crea (smss.exe, el "gestor de sesiones") debe ser una aplicación nativa. csrss.exe en sí es una aplicación nativa.

Pese a tener la extensión de archivo ".exe", las aplicaciones nativas no pueden ser ejecutadas por el usuario (ni por algún programa en el subsistema Win32). Un ejemplo es la aplicación autochk.exe que ejecuta chkdsk durante la inicialización del sistema, o Blue Screen. Otros ejemplos podrían ser los servicios que ejecutan procesos del sistema, como csrss.exe.

Exceptuando a las aplicaciones Win32, las aplicaciones nativas se instancian sin las rutinas del código del kernel (ntoskrnl.exe) y tienen un punto de entrada distinto a las aplicaciones normales (NtProcessStartup, a diferencia de (w)(Win)MainCRTStartup como en las aplicaciones Win32),[3]​ obtienen sus argumentos de línea de comandos a través de un puntero en una estructura de memoria, administran su propia memoria usando la API Rtl, y retornan de la ejecución con una llamada a NtTerminateProcess (en oposición a ExitProcess). Una biblioteca común enlazada a una aplicación nativa es nt.lib, que contiene un código de inicio para las aicaciones nativas, similar a como las rutinas C proveen código de inicio a las aplicaciones Win32.[6]

La mayoría de las funciones de esta API no están documentadas, las aplicaciones nativas pueden ser construidas usando el Windows Driver Development Kit; algunos Antivirus incorporan aplicaciones nativas sin estos productos, usualmente para mejorar el rendimiento de algunas tareas realizadas durante el arranque que no pueden ser llevadas a cabo en el modo usuario.[cita requerida]

Win32 API (o WinAPI32)Editar

Las bibliotecas en esta sección implementan varias secciones de la Win32 API.

KERNEL32.DLLEditar

KERNEL32.DLL expone a las aplicaciones la mayoría de las APIs base de Win32, como la administración de memoria, operaciones de entrada/salida, creación de procesos e hilos, y funciones de sincronización. Muchas de estas funciones están implementadas sin el KERNEL32.DLL llamando las funciones correspondientes en la API nativa, expuesta en NTDLL.DLL.[7]

GDI32.DLLEditar

GDI32.DLL exporta las funciones Graphics Device Interface (GDI) que proveen las funciones primitivas de dibujo para la salida de video a pantallas e impresoras. Las aplicaciones llaman a las funciones GDI directamente para aprovechar las funciones de bajo nivel, salida de texto, administración de fuentes, y funciones similares.[7][8]

Inicialmente, las funciones GDI soportaban 16 y 256 colores de las tarjetas gráficas EGA/VGA e impresoras monocromáticas. Las funcionalidades fueron expandidas a través de los años, y ahora soportan varias cosas como las fuentes TrueType, canales alfa, y múltiples monitores.[9]

USER32.DLLEditar

USER32.DLL implementa el componente de Windows USER que crea y manipula los elementos estándares de la interfaz de usuario de Windows, como el Escritorio, las ventanas y el menú. Esto permite a los programas crear interfaces gráficas de usuario que coincidan con la apariencia visual de Windows. Los programas llaman a las funciones desde Windows USER para completar operaciones como crear y administrar ventanas, recibir mensajes de ventana (como los eventos de ratón y teclado, pero también notificaciones del sistema operativo), mostrar texto en la ventana, y mostrar cuadros de diálogo.

Muchas de las funciones en USER32.DLL llaman a las funciones GDI implementadas en GDI32.DLL para el renderizado actual de varios elementos de la interfaz de usuario. Algunos programas también llaman a las funciones del GDI directamente para operaciones de dibujo a un bajo nivel sin necesidad de una ventana creada con las funciones de USER32.

COMCTL32.DLLEditar

COMCTL32.DLL implementa una variedad de controles estándares de Windows, como los cuadros de diálogo Abrir archivo, Guardar, y Guardar como..., barras de progreso, y listas de vista. Llama funciones de los archivos USER32.DLL y GDI32.DLL para crear y administrar las ventanas para esos elementos UI, coloca los gráficos en su lugar, y recoge la información del usuario.

WS2_32.DLLEditar

WS2_32.DLL implementa la Winsock API, el cual provee funciones de red TCP/IP y provee compatibilidad parcial con otras APIs de red. wsock.dll y wsock32.dll son versiones antiguas para la compatibilidad con Win3.11 y Win95.

ADVAPI32.DLLEditar

ADVAPI32.DLL provee llamadas y funciones seguras para el manejo del Registro.

NETAPI32.DLLEditar

NETAPI32.DLL provee funcionalidades para las peticiones y la administración de interfaces de red.

Otras APIsEditar

SHSCRAP.DLLEditar

SHSCRAP.DLL es parte del mecanismo Object Linking and Embedding (OLE). Implementa el soporte a los archivos «shell scrap», que son creados automáticamente cuando se arrastra un contenido seleccionado desde una aplicación OLE a una ventana del Explorador o al escritorio,[10]​ pero también es posible usar el Object Packager para crearlos. Estos pueden ser arrastrados dentro de otra aplicación OLE-capable.

Esta funcionalidad fue eliminada en Windows Vista para mejorar la seguridad y limpiar el sistema operativo de funcionalidades no utilizadas.[11]​ Los archivos scrap (.shs) eran utilizados por los virus porque pueden contener una larga variedad de archivos (incluyendo código ejecutable), y la extensión de archivo no siempre era revelada cuando la opción "Ocultar extensiones de archivo de tipos de archivo conocidos" estaba desmarcada.[12]​ La funcionalidad puede ser restaurada copiando las correspondientes entradas del registro y la DLL desde un sistema Windows XP.[13]

WINMM.DLLEditar

WINMM.DLL provee acceso a la API de audio WinMM original.

Bibliotecas en tiempo de ejecuciónEditar

MSVCRT.DLL, MSVCP*.DLL and CRTDLL.DLLEditar

MSVCRT.DLL es la biblioteca Microsoft Visual C Run-Time Library para el compilador Visual C++ (MSVC) desde la versión 4.2 a la 6.0. Posee programas compilados por la versión de MSVC en curso con la mayoría de las funciones de la biblioteca estándar C. Se incluyen la manipulación de cadenas de texto, asignación de memoria, llamadas de entrada y salida al estilo de C, y otros. MSVCP*.DLL es la correspondiente biblioteca para C++.

Viene incluida en todas las versiones de Windows desde Windows 95 OSR2 para ser usado por otros componentes de Windows; las versiones más antiguas vienen con la biblioteca CRTDLL.DLL. En versiones más antiguas de Windows, programas que dependen de la biblioteca MSVCRT.DLL pueden instalar una copia compatible en la carpeta system32, pero contribuye a generar el problema de las DLL Hell porque algunos instaladores fallan al analizar la versión a instalar antes de reemplazarla.

Las versiones de MSVC anteriores a la 4.0 y desde la 7.0 a la 13.0 usan diferentes nombres para cada versión del DLL (MSVCR20.DLL, MSVCR70.DLL, MSVCR71.DLL, MSVCP110.DLL, etc.). Las aplicaciones requieren instalar la versión apropiada,[14]​ y Microsoft ofrece los paquetes Visual C++ Redistributable para este propósito, aunque Windows viene con una versión preinstalada.

En la versión 14.0, la mayoría de las rutinas C/C++ fueron movidas a un nuevo DLL, UCRTBASE.DLL. Por otra parte, los programas C/C++ que usaban UCRTBASE.DLL son forzados a enlazar a otra nueva DLL, la VCRuntime, cuyo nombre cambia con una nueva versión de MSVC (ej. VCRUNTIME140.DLL).

El código fuente para las bibliotecas está incluido en Visual C++[15]​para referencia y depuración (ej. en C:\Program Files\Microsoft Visual Studio 11.0\VC\crt\src).

Esta biblioteca es usada por programas escritos en Visual C++ y algunos otros compiladores (ej. MinGW). Otros compiladores poseen sus propias bibliotecas de rutinas.

Otras bibliotecas de rutinasEditar

Bibliotecas .NET FrameworkEditar

Los programas escritos en C#, Visual Basic.NET, C++/CLI y otros lenguajes de .NET dependen de .NET Framework. Posee varias bibliotecas, una de ellas es mscorlib.dll[16]​, o Multilanguage Standard Common Object Runtime Library (formalmente Microsoft Common Object Runtime Library[17]​), y ensambladores (por ejemplo, System.Windows.Forms.dll).

Véase tambiénEditar

ReferenciasEditar

  1. Blunden, Bill (2009). The Rootkit Arsenal: Escape and Evasion in the Dark Corners of the System. Jones & Bartlett Learning. p. 101. ISBN 978-1-59822-061-2. 
  2. Eilam, Eldad (2011). Reversing: Secrets of Reverse Engineering. John Wiley & Sons. pp. 68-69. ISBN 978-1-118-07976-8. 
  3. a b «Inside Native Windows Applications». Archivado desde el original el 12 de septiembre de 2010. Consultado el 14 de diciembre de 2011. 
  4. Russinovich, Mark A. & Solomon, David A. (2009). Windows® Internals. O'Reilly Media. p. 136. ISBN 978-0-7356-3796-2. 
  5. Marceau, Carla & Stillerman, Matt (2006). «Modular behavior profiles in systems with shared libraries». En Neng, Peng et al., ed. Information and Communications Security: 8th International Conference, ICICS 2006 – Raleigh, NC, USA, December 4–7, 2006 – proceedings. Springer. p. 371. ISBN 978-3-540-49496-6. 
  6. http://technet.microsoft.com/en-us/sysinternals/bb897447.aspx
  7. a b Visual Studio Developer Center: Identifying Functions in DLLs
  8. See also, the documentation for the Wine implementation of GDI32.DLL: Wine API: gdi32.dll
  9. Yuan, Feng (2001). Windows graphics programming: Win32 GDI and DirectDraw. Prentice Hall Professional. p. 71. ISBN 978-0-13-086985-2. 
  10. «WD: What is a Scrap (.shs) file?». Microsoft Knowledge Base. 
  11. Raymond Chen. «Windows Confidential: Scrapping the Scraps». Consultado el 14 de diciembre de 2011. 
  12. «VBS.Stages.A». symantec.com. 
  13. «How to open SHS files». Consultado el 14 de diciembre de 2011. 
  14. «C Run-Time Libraries». Consultado el 14 de diciembre de 2011. 
  15. http://msdn.microsoft.com/en-us/library/aa296413(v=vs.60).aspx
  16. «mscorlib-dll». WinPCWare.com. 
  17. http://weblogs.asp.net/mreynolds/archive/2004/01/31/65551.aspx