Infierno DLL

En informática, DLL Hell es un término que se refiere a las complicaciones que surgen cuando se trabaja con bibliotecas de vínculos dinámicos (DLL) utilizadas con los sistemas operativos Microsoft Windows, en particular las ediciones heredadas de 16 bits, que se ejecuta en un solo espacio de memoria.

DLL Hell puede manifestarse de muchas maneras diferentes en las que las aplicaciones no se inician ni funcionan correctamente.

DLL Hell es la forma específica del ecosistema de Windows del infierno de dependencia del concepto general.

Problemas

Las DLL son la implementación de bibliotecas compartidas de Microsoft. Las bibliotecas compartidas permiten que el código común se empaquete en un contenedor, el DLL, que utiliza cualquier software de aplicación en el sistema sin cargar varias copias en la memoria. Un ejemplo simple podría ser el editor de texto GUI, que es ampliamente utilizado por muchos programas. Al colocar este código en una DLL, todas las aplicaciones del sistema pueden usarlo sin usar más memoria. Esto contrasta con las bibliotecas estáticas, que son funcionalmente similares pero copian el código directamente en la aplicación. En este caso, cada aplicación crece según el tamaño de todas las bibliotecas que utiliza, y esto puede ser bastante grande para los programas modernos.

El problema surge cuando la versión de la DLL en la computadora es diferente a la versión que se usó cuando se creó el programa. Las DLL no tienen un mecanismo incorporado para la compatibilidad con versiones anteriores, e incluso los cambios menores en la DLL pueden hacer que su estructura interna sea tan diferente de las versiones anteriores que intentar usarlas generalmente hará que la aplicación se bloquee. Las bibliotecas estáticas evitan este problema porque la versión que se usó para construir la aplicación está incluida dentro de ella, por lo que incluso si existe una versión más nueva en otra parte del sistema, esto no afecta a la aplicación.

Un motivo clave de la incompatibilidad de versiones es la estructura del archivo DLL. El archivo contiene un directorio de los métodos individuales (procedimientos, rutinas, etc.) contenidos dentro de la DLL y los tipos de datos que toman y devuelven. Incluso los cambios menores en el código DLL pueden hacer que este directorio se reorganice, en cuyo caso una aplicación que llama a un método en particular creyendo que es el cuarto elemento en el directorio podría terminar llamando a una rutina completamente diferente e incompatible, lo que normalmente hace que la aplicación se bloquee.

Hay varios problemas que se encuentran comúnmente con las DLL, especialmente después de que se hayan instalado y desinstalado numerosas aplicaciones en un sistema. Las dificultades incluyen conflictos entre las versiones de DLL, dificultad para obtener las DLL requeridas y tener muchas copias de DLL innecesarias.

Las soluciones a estos problemas se conocían incluso cuando Microsoft estaba escribiendo el sistema DLL. Estos se han incorporado en el reemplazo de.NET, "ensamblajes".

Versiones incompatibles

Una versión particular de una biblioteca puede ser compatible con algunos programas que la usan e incompatible con otros. Windows ha sido particularmente vulnerable a esto debido a su énfasis en la vinculación dinámica de bibliotecas de C++ y objetos de vinculación e incrustación de objetos (OLE). Las clases de C++ exportan muchos métodos, y un solo cambio en la clase, como un nuevo método virtual, puede hacer que sea incompatible con los programas creados con una versión anterior. La vinculación e incrustación de objetos tiene reglas muy estrictas para evitar esto: se requiere que las interfaces sean estables y los administradores de memoria no se comparten. Sin embargo, esto es insuficiente porque la semántica de una clase puede cambiar. Una corrección de errores para una aplicación puede resultar en la eliminación de una característica de otra. Antes de Windows 2000, Windows era vulnerable a esto porque la tabla de clases COM se compartía entre todos los usuarios y procesos. Solo un objeto COM en un archivo DLL/EXE podría declararse con una ID de clase COM global específica en un sistema. Si algún programa necesitaba crear una instancia de esa clase, obtenía la implementación actual registrada centralmente. Como resultado, la instalación de un programa que instaló una nueva versión de un objeto común podría romper inadvertidamente otros programas que se instalaron previamente.

Aplastamiento de DLL

Un problema común y problemático ocurre cuando un programa recién instalado sobrescribe una DLL del sistema en funcionamiento con una versión anterior incompatible. Los primeros ejemplos de esto fueron las bibliotecas ctl3d.dll y ctl3dv2.dll para Windows 3.1: bibliotecas creadas por Microsoft que los editores de terceros distribuirían con su software, pero cada una distribuyendo la versión con la que desarrollaron en lugar de la versión más reciente. El pisoteo de DLL ocurre porque:

• Microsoft en el pasado distribuyó DLLs de tiempo de ejecución como componentes del sistema compartido (originally C:WINDOWS y C:WINDOWSSYSTEM), como una forma de compartir eficientemente el código en un sistema operativo de memoria compartida con RAM y espacio de disco limitado. En consecuencia, los desarrolladores de terceros también distribuyeron éstos de esa manera.
• Los instaladores de aplicaciones se ejecutan normalmente en un contexto de seguridad privilegiado que tiene acceso a instalar DLLs en los directorios del sistema y para editar el registro del sistema para registrar nuevos DLLs como objetos COM. Un instalador mal escrito o mal configurado puede por lo tanto reducir una biblioteca del sistema en versiones heredadas de Windows, en las que Windows File Protection o Windows Resource Protection no retrocede el cambio. En Windows Vista y más tarde, sólo la cuenta de "instalador confiable" puede hacer cambios en las bibliotecas centrales del sistema operativo.
• Se permitió que las aplicaciones de Windows incluyeran actualizaciones del sistema operativo en sus propios programas de instalación. Eso es, muchos DLL de Microsoft son redistribución, lo que significa que las aplicaciones pueden incluirlas si necesitan los servicios de las bibliotecas particulares.
• Antes de Windows Installer, instaladores de Windows históricamente eran productos comerciales; muchas personas trataron de escribir sus propios instaladores, con vistas o mal manejo de problemas de versión en el proceso.
• Algunos entornos de desarrollo no agregaron automáticamente un recurso de versión en sus bibliotecas compiladas, por lo que muchos desarrolladores pasaron por alto este aspecto. Compruebe las fechas de archivo, sobreescribir los archivos existentes o saltar la operación de copia si el DLL ya estaba instalado eran las únicas opciones disponibles en lugar de la versión correcta.
• A veces, el propio sistema operativo removió o reemplazó DLLs con versiones antiguas o obsoletas. Por ejemplo, Windows 2000 instalaría DLLs de impresora en blanco y negro en la parte superior de DLLs de color, si una impresora en blanco y negro fue instalada después de la impresora de color.

Registro COM incorrecto

En COM y otras partes de Windows, antes de la introducción de ensamblados sin registro en paralelo, el Registro se usaba para determinar qué DLL subyacente usar. Si se registrara una versión diferente de un módulo, se cargaría esta DLL en lugar de la esperada. Este escenario podría ser causado por instalaciones en conflicto que registran diferentes versiones de las mismas bibliotecas, en cuyo caso prevalecería la última instalación.

Módulos en memoria compartidos

Las versiones de 16 bits de Windows (y Windows en Windows) cargan solo una instancia de cualquier archivo DLL; todas las aplicaciones hacen referencia a la misma copia en memoria, hasta que ninguna aplicación la esté utilizando y se descargue de la memoria. (Para las versiones de Windows de 32 y 64 bits, el uso compartido entre procesos se produce solo cuando diferentes ejecutables cargan un módulo desde exactamente el mismo directorio; el código, pero no la pila, se comparte entre procesos a través de un proceso denominado "memoria). mapeo"). Por lo tanto, incluso cuando la DLL deseada se encuentra en un directorio donde se espera que se encuentre, como en el directorio del sistema o en el directorio de la aplicación, ninguna de estas instancias se utilizará si se ha iniciado otra aplicación. con una versión incompatible de un tercer directorio. Este problema puede manifestarse como un error de aplicación de 16 bits que ocurre solo cuando las aplicaciones se inician en un orden específico.

Falta de servicio

En conflicto directo con el problema de pisoteo de DLL: si las actualizaciones de una DLL no afectan a todas las aplicaciones que la usan, entonces se vuelve mucho más difícil "mantener" la DLL, es decir, para eliminar los problemas que existen en las versiones actuales de la DLL. (Las correcciones de seguridad son un caso particularmente convincente y doloroso). En lugar de corregir solo la última versión de la DLL, el implementador debe idealmente hacer sus correcciones y probar su compatibilidad en cada versión lanzada de la DLL.

Causas

La incompatibilidad de DLL ha sido causada por:

• Limitaciones de memoria, combinadas con la falta de separación del espacio de memoria de proceso en versiones de 16 bits de Windows;
• Falta de versión estándar forzada, nombre y localización del sistema de archivos para DLL;
• Falta de un método estándar aplicado para la instalación y eliminación de software (gestión de paquetes);
• Falta de apoyo autorizado centralizado para la gestión y las salvaguardias de la interfaz binaria de aplicación DLL, lo que permite la liberación de DLL incompatibles con el mismo nombre de archivo y números de versión interna;
• Herramientas de gestión simplificadas, evitando la identificación de DLLs cambiados o problemáticos por usuarios y administradores;
• Los desarrolladores rompen la compatibilidad de funciones en módulos compartidos;
• Microsoft libera actualizaciones fuera de banda a componentes de tiempo de funcionamiento del sistema;
• Incapacidad de versiones anteriores de Windows para ejecutar versiones conflictivas lado a lado de la misma biblioteca;
• Confianza en el directorio actual o %PATH% variable ambiente, ambos varían con el tiempo y del sistema al sistema, para encontrar DLLs dependientes (en lugar de cargarlos de un directorio configurado explícitamente);
• Desarrolladores reutilizando la clase IDs from sample applications for the COM interfaces of their applications, rather than generating their own new GUIDs.

El infierno de DLL era un fenómeno muy común en las versiones anteriores a Windows NT de los sistemas operativos de Microsoft, y la causa principal era que los sistemas operativos de 16 bits no restringían los procesos a su propio espacio de memoria, por lo que no les permitían cargar sus propios versión de un módulo compartido con el que eran compatibles. Se esperaba que los instaladores de aplicaciones fueran buenos ciudadanos y verificaran la información de la versión de DLL antes de sobrescribir las DLL existentes del sistema. Microsoft y otros proveedores de herramientas de terceros proporcionaron herramientas estándar para simplificar la implementación de aplicaciones (lo que siempre implica el envío de archivos DLL dependientes del sistema operativo). Microsoft incluso exigió a los proveedores de aplicaciones que usaran un instalador estándar y certificaran que su programa de instalación funcionaba correctamente, antes de que se les concediera el uso del logotipo de Microsoft. El enfoque del instalador de buen ciudadano no mitigó el problema, ya que el aumento de la popularidad de Internet brindó más oportunidades para obtener aplicaciones no conformes.

Uso por malware

La ambigüedad con la que se pueden cargar archivos DLL que no están completamente calificados en el sistema operativo Windows ha sido aprovechada por malware en los últimos años, abriendo una nueva clase de vulnerabilidad que afecta a las aplicaciones de muchos proveedores de software diferentes, así como al propio Windows..

Soluciones

A lo largo de los años, se han solucionado o mitigado varias formas de problemas de DLL.

Enlace estático

Una solución simple para DLL Hell en una aplicación es vincular estáticamente todas las bibliotecas, es decir, incluir la versión de biblioteca requerida en el programa, en lugar de seleccionar una biblioteca del sistema con un nombre específico. Esto es común en las aplicaciones C/C++, donde, en lugar de tener que preocuparse por qué versión de MFC42.DLL está instalada, la aplicación se compila para vincularse estáticamente con las mismas bibliotecas. Esto elimina las DLL por completo y es posible en aplicaciones independientes que usan solo bibliotecas que ofrecen una opción estática, como lo hace Microsoft Foundation Class Library. Sin embargo, se sacrifica el objetivo principal de las DLL (compartir bibliotecas en tiempo de ejecución entre programas para reducir la sobrecarga de memoria); duplicar el código de la biblioteca en varios programas crea una sobrecarga de software y complica la implementación de correcciones de seguridad o versiones más nuevas de software dependiente.

Protección de archivos de Windows

El problema de sobrescritura de DLL (denominado DLL Stomping por Microsoft) se redujo un poco con Windows File Protection (WFP), que se introdujo en Windows 2000. Esto evita que las aplicaciones no autorizadas sobrescriban las DLL del sistema. a menos que utilicen las API específicas de Windows que lo permitan. Todavía puede existir el riesgo de que las actualizaciones de Microsoft sean incompatibles con las aplicaciones existentes, pero este riesgo generalmente se reduce en las versiones actuales de Windows mediante el uso de ensamblajes en paralelo.

Las aplicaciones de terceros no pueden pisotear los archivos del sistema operativo a menos que incluyan actualizaciones legítimas de Windows con su instalador, o si deshabilitan el servicio de protección de archivos de Windows durante la instalación, y en Windows Vista o posterior también toman posesión de los archivos del sistema y se otorgan acceso.. La utilidad SFC podría revertir estos cambios en cualquier momento.

Ejecutar archivos DLL en conflicto simultáneamente

Las soluciones aquí consisten en tener diferentes copias de las mismas DLL para cada aplicación, tanto en disco como en memoria.

Una solución manual fácil para los conflictos fue colocar las diferentes versiones de la DLL del problema en las aplicaciones' carpetas, en lugar de una carpeta común para todo el sistema. Esto funciona en general siempre que la aplicación sea de 32 o 64 bits y que la DLL no utilice memoria compartida. En el caso de aplicaciones de 16 bits, las dos aplicaciones no pueden ejecutarse simultáneamente en una plataforma de 16 bits, o en la misma máquina virtual de 16 bits bajo un sistema operativo de 32 bits. OLE evitó esto antes de Windows 98 SE/2000, porque las versiones anteriores de Windows tenían un único registro de objetos COM para todas las aplicaciones.

Windows 98 SE/2000 introdujo una solución llamada ensamblaje en paralelo, que carga copias separadas de DLL para cada aplicación que las requiere (y, por lo tanto, permite que las aplicaciones que requieren DLL en conflicto se ejecuten simultáneamente). Este enfoque elimina los conflictos al permitir que las aplicaciones carguen versiones únicas de un módulo en su espacio de direcciones, al tiempo que conserva el beneficio principal de compartir archivos DLL entre aplicaciones (es decir, reduce el uso de memoria) mediante el uso de técnicas de mapeo de memoria para compartir código común entre diferentes procesos que todavía Usa el mismo módulo. Sin embargo, las DLL que utilizan datos compartidos entre múltiples procesos no pueden adoptar este enfoque. Un efecto secundario negativo es que es posible que las instancias huérfanas de DLL no se actualicen durante los procesos automatizados.

Aplicaciones portátiles

Según la arquitectura de la aplicación y el entorno de tiempo de ejecución, las aplicaciones portátiles pueden ser una forma eficaz de reducir algunos problemas de DLL, ya que cada programa incluye sus propias copias privadas de cualquier DLL que necesite. El mecanismo se basa en que las aplicaciones no califican completamente las rutas a las DLL dependientes al cargarlas, y el sistema operativo busca el directorio ejecutable antes que cualquier ubicación compartida. Sin embargo, esta técnica también puede ser explotada por malware, y la mayor flexibilidad también puede ser a expensas de la seguridad si las DLL privadas no se mantienen actualizadas con parches de seguridad de la misma manera que las compartidas.

La virtualización de aplicaciones también puede permitir que las aplicaciones se ejecuten en una "burbuja", lo que evita instalar archivos DLL directamente en el sistema operativo.

Otras contramedidas

Hay otras contramedidas para evitar DLL Hell, algunas de las cuales pueden tener que usarse simultáneamente; Algunas otras características que ayudan a mitigar el problema son:

• Las herramientas de instalación ahora se agrupan en Microsoft Visual Studio, uno de los principales entornos para el desarrollo de Windows. Estas herramientas realizan la comprobación de la versión antes de la instalación DLL, y pueden incluir paquetes de instalación predefinidos en una instalación. Esto permite a aplicaciones de terceros integrar actualizaciones de componentes OS sin tener que escribir sus propios instaladores para estos componentes.
• System Restore puede recuperar un sistema de una mala instalación, incluyendo el daño del registro. Si bien esto no impide el problema, hace más fácil recuperarse.
• El directorio WinSxS (Windows Side-by-Side), que permite múltiples versiones de las mismas bibliotecas coexistir.
• Ejecute aplicaciones de 16 bits en un espacio de memoria separado bajo una versión de 32 bits de Windows para permitir que dos aplicaciones usen versiones conflictivas del mismo DLL al mismo tiempo.
• Utilice una versión de Windows que incluye Windows File Protection. Windows Yo y Windows 2000, ambos liberados en 2000, soportan esta forma de protección de archivos del sistema, así como Windows XP y Windows Server 2003. Su reemplazo, Windows Resource Protection, fue introducido en Windows Vista y Windows Server 2008, y utiliza un método diferente para proteger los archivos del sistema de ser cambiado.
• COM sin registro: Windows XP introdujo un nuevo modo de registro de objetos COM llamado "Registro libre COM". Esta función permite a las aplicaciones que necesitan instalar objetos COM almacenar toda la información necesaria del registro COM en el propio directorio de la aplicación, en lugar del registro global del sistema. Por lo tanto, proporciona un mecanismo para múltiples versiones del mismo DLL para ser registrado al mismo tiempo por múltiples aplicaciones (Microsoft llama a esta "Asamblea Side-by-Side"). DLL infierno puede ser evitado sustancialmente mediante el registro libre COM, la única limitación es que requiere al menos Windows XP o versiones posteriores de Windows y que no debe ser utilizado para servidores EXE COM o componentes de todo el sistema como MDAC, MSXML, DirectX o Internet Explorer.
• Envío del sistema operativo con un sistema de gestión de paquetes capaz de rastrear las dependencias DLL, alentando el uso del gestor de paquetes y desalentando la instalación manual de DLLs. Installer de Windows, incluido con Windows Me, Windows 2000 y todas las versiones posteriores proporciona esta funcionalidad.
• Tener una base de datos o autoridad central para la resolución de conflictos y la distribución de software DLL. Los cambios a una biblioteca pueden ser sometidos a esta autoridad; por lo tanto, puede asegurarse de que la compatibilidad se conserva en las ramas desarrolladas. Si algún software antiguo es incompatible con la biblioteca actual, la autoridad puede proporcionar una interfaz de compatibilidad para ella, o empaquetar la versión antigua como un paquete distinto.
• Si los desarrolladores de software necesitan personalizar una biblioteca, y si la versión principal de la biblioteca es poco probable que incorpore los cambios que necesitan, pueden enviar el DLL personalizado para el uso privado del programa (comúnmente colocandolo en el directorio privado del programa) o vincular estadísticamente el programa contra la biblioteca personalizada.
• Mientras que los DLLs son los mejores para modular aplicaciones y componentes del sistema y como bibliotecas de terceros, su uso no es imperativo en todos los casos en sistemas modernos donde la memoria ya no es una limitación. Por ejemplo, si una aplicación necesita una biblioteca que no se utilizará en ningún otro lugar, puede estar vinculada estadísticamente, sin penalización espacial y con un aumento de velocidad.
• Windows Vista y luego utilizar un especial TrustedInstaller servicio para instalar archivos del sistema operativo. Otras cuentas de usuario, incluyendo el SYSTEM, no tienen acceso a binarios de sistemas básicos de sobreescritura. Windows 7 amplía esta funcionalidad a algunas partes críticas del Registro.
• Las aplicaciones basadas en la web evitan muchos problemas de lado a lado ejecutando la mayor parte del código en un servidor y utilizando una interfaz de navegador en el cliente.