WikiDer > DLL ад

DLL Hell

В вычисление, DLL ад это термин для обозначения осложнений, возникающих при работе с библиотеки с динамической компоновкой (DLL), используемые с Майкрософт Виндоус операционные системы,[1] особенно наследие 16-битные версии, которые все работают в одном пространстве памяти.

DLL Hell может проявляться по-разному, при этом приложения не запускаются и не работают правильно.

DLL Hell - это специфическая для экосистемы Windows форма общей концепции ад зависимости.

Проблемы

DLL - это реализация Microsoft общие библиотеки. Общие библиотеки позволяют объединить общий код в оболочку, DLL, и использовать его любым прикладным программным обеспечением в системе без загрузки нескольких копий в память. Простым примером может быть GUI текстовый редактор, который широко используется многими программами. Поместив этот код в DLL, все приложения в системе могут использовать его без использования дополнительной памяти. Это контрастирует с статические библиотеки, которые функционально похожи, но копируют код прямо в приложение. В этом случае каждое приложение увеличивается на размер всех используемых им библиотек, а для современных программ он может быть довольно большим.

Проблема возникает, когда версия библиотеки DLL на компьютере отличается от версии, которая использовалась при создании программы. Библиотеки DLL не имеют встроенного механизма обратной совместимости, и даже незначительные изменения в DLL делают ее внутреннюю структуру настолько отличной от предыдущих версий, что попытка их использования обычно вызывает сбой приложения. Статические библиотеки позволяют избежать этой проблемы, поскольку версия, которая использовалась для сборки приложения, включена в нее, поэтому даже если где-то в системе существует более новая версия, это не влияет на приложение.

Основная причина несовместимости версий - структура файла DLL. Файл содержит каталог отдельных методов (процедур, подпрограмм и т. Д.), Содержащихся в DLL, и типов данных, которые они принимают и возвращают. Даже незначительные изменения в коде DLL могут привести к переупорядочению этого каталога, и в этом случае приложение, которое вызывает определенный метод, полагая, что он является четвертым элементом в каталоге, может в конечном итоге вызвать совершенно другую и несовместимую процедуру, которая обычно вызывает сбой приложения.

Существует несколько проблем, с которыми обычно сталкиваются библиотеки DLL, особенно после того, как в системе были установлены и удалены многочисленные приложения. Сложности включают конфликты между версиями DLL, трудности с получением необходимых DLL и наличие множества ненужных копий DLL.

Решения этих проблем были известны еще тогда, когда Microsoft писала систему DLL. Они были включены в .СЕТЬ замена, "Сборки".

Несовместимые версии

Определенная версия библиотеки может быть совместима с некоторыми программами, которые ее используют, и несовместима с другими. Windows была особенно уязвима для этого из-за ее упора на динамическое связывание библиотек C ++ и Связывание и внедрение объектов (OLE) объекты. Классы C ++ экспортируют множество методов, и одно изменение класса, например новый виртуальный метод, может сделать его несовместимым с программами, созданными для более ранней версии. Для предотвращения этого существуют очень строгие правила связывания и внедрения объектов: интерфейсы должны быть стабильными, а диспетчеры памяти не используются совместно. Однако этого недостаточно, поскольку семантика класса может измениться. Исправление ошибки в одном приложении может привести к удалению функции из другого. Перед Windows 2000, Windows была уязвима для этого, потому что COM Таблица классов была совместно использована всеми пользователями и процессами. Только один COM-объект в одной DLL / EXE может быть объявлен как имеющий конкретный глобальный идентификатор COM-класса в системе. Если какой-либо программе требовалось создать экземпляр этого класса, она получала то, что было текущей централизованно зарегистрированной реализацией. В результате установка программы, которая установила новую версию общего объекта, может случайно нарушить работу других программ, которые были установлены ранее.

DLL топает

Распространенная и неприятная проблема возникает, когда недавно установленная программа перезаписывает рабочую системную DLL более ранней несовместимой версией. Ранними примерами этого были ctl3d.dll и ctl3dv2.dll библиотеки для Windows 3.1: Библиотеки, созданные корпорацией Майкрософт, которые сторонние издатели будут распространять вместе со своим программным обеспечением, но каждая распространяет версию, с которой они разработали, а не самую последнюю версию.[2] Вытеснение DLL происходит по следующим причинам:

  • В прошлом Microsoft распределяла библиотеки времени выполнения как общие системные компоненты[3] (первоначально C: WINDOWS и C: WINDOWS SYSTEM), как способ эффективного совместного использования кода в ОС с общей памятью с ограниченным ОЗУ и дисковым пространством. Следовательно, сторонние разработчики также распространяли их таким образом.
  • Установщики приложений обычно выполняются в привилегированном контексте безопасности, который имеет доступ для установки DLL в системные каталоги и для редактирования системного реестра для регистрации новых DLL как COM объекты. Поэтому плохо написанный или неправильно настроенный установщик может понизить версию системной библиотеки в устаревших версиях Windows, в которых Защита файлов Windows или Защита ресурсов Windows не откатывает изменение. В Windows Vista и более поздних версиях только учетная запись «доверенного установщика» может вносить изменения в основные библиотеки операционной системы.
  • Приложениям Windows было разрешено включать обновления ОС в свои собственные программы установки. То есть многие библиотеки DLL Microsoft распространяемый, что означает, что приложения могут включать их, если им нужны службы определенных библиотек.
  • Перед Установщик Windows, Установщики Windows исторически были коммерческими продуктами; многие люди пытались написать свои собственные установщики, не обращая внимания на проблемы с версией или неправильно решая их в процессе.[нужна цитата]
  • Некоторые среды разработки не добавляли автоматически ресурс версии в свои скомпилированные библиотеки, поэтому многие разработчики упустили этот аспект. Проверка дат файлов, перезапись существующих файлов или пропуск операции копирования, если DLL уже была установлена, были единственными доступными вариантами вместо правильного управления версиями.[нужна цитата]
  • Иногда сама ОС удаляла или заменяла библиотеки DLL более старыми или устаревшими версиями. Например, Windows 2000 установит библиотеки DLL черно-белого принтера поверх DLL с поддержкой цвета, если черно-белый принтер был установлен после цветного принтера.[4]

Неправильная регистрация COM

В COM и других частей Windows до появления бок о бок безреестровые сборки,[5] то Реестр использовался для определения того, какую базовую DLL использовать. Если была зарегистрирована другая версия модуля, эта DLL будет загружена вместо ожидаемой. Этот сценарий может быть вызван конфликтующими установками, в которых регистрируются разные версии одних и тех же библиотек, и в этом случае последняя установка будет иметь приоритет.

Общие модули в памяти

16-битные версии Windows (и Windows в Windows) загружать только один экземпляр любой данной DLL; все приложения ссылаются на одну и ту же копию в памяти до тех пор, пока ее не используют никакие приложения, и она не выгружается из памяти. (Для 32-разрядных и 64-разрядных версий Windows совместное использование между процессами происходит только тогда, когда разные исполняемые файлы загружают модуль из одного и того же каталога; код, но не стек распределяется между процессами через процесс, называемый «отображение памяти».) Таким образом, даже если желаемая DLL находится в каталоге, где ее можно ожидать, например, в системном каталоге или каталоге приложения, ни один из этих экземпляров будет использоваться, если другое приложение было запущено с несовместимой версией из третьего каталога. Эта проблема может проявляться как ошибка 16-битного приложения, которая возникает только при запуске приложений в определенном порядке.

Отсутствие исправности

Находится в прямом конфликте с проблемой выталкивания DLL: если обновления библиотеки DLL не влияют на все приложения, которые ее используют, она становится много труднее «обслуживать» DLL, то есть устранять проблемы, существующие в текущих версиях DLL. (Исправления безопасности - особенно убедительный и болезненный случай.) Вместо исправления только последней версии DLL разработчик в идеале должен внести свои исправления и протестировать их на совместимость с каждой выпущенной версией DLL.

Причины

Несовместимость DLL была вызвана:

  • Ограничения памяти в сочетании с отсутствием разделения пространства памяти процесса в 16-битных версиях Windows;
  • Отсутствие принудительного стандартного управления версиями, именами и расположением файловой системы схемы для DLL;
  • Отсутствие принудительного стандартного метода установки и удаления программного обеспечения (управление пакетами);
  • Отсутствие централизованной авторитетной поддержки DLL двоичный интерфейс приложения управление и меры безопасности, позволяющие выпускать несовместимые библиотеки DLL с одинаковыми именами файлов и внутренними номерами версий;
  • Упрощенные инструменты управления, предотвращающие идентификацию измененных или проблемных DLL пользователями и администраторами;
  • Разработчики нарушают обратную совместимость функций в разделяемых модулях;
  • Microsoft выпускает внеполосные обновления для компонентов среды выполнения операционной системы;
  • Неспособность более ранних версий Windows запускать параллельно конфликтующие версии одной и той же библиотеки;
  • Опора на текущий каталог или %ДОРОЖКА% переменная окружения, обе из которых меняются со временем и от системы к системе, для поиска зависимых библиотек DLL (вместо загрузки их из явно настроенного каталога);
  • Разработчики повторно используют ClassID из примеров приложений для COM-интерфейсов своих приложений, а не создают свои собственные новые GUID.

DLL Hell был очень распространенным явлением в версиях операционных систем Microsoft до Windows NT, основная причина заключалась в том, что 16-разрядные операционные системы не ограничивали процессы их собственным пространством памяти, тем самым не позволяя им загружать свою собственную версию общий модуль, с которым они были совместимы. Ожидалось, что установщики приложений будут хорошими гражданами и проверят информацию о версии DLL перед перезаписью существующих системных DLL. Стандартные инструменты для упрощения развертывания приложений (которые всегда включают доставку зависимых библиотек DLL операционной системы) были предоставлены Microsoft и другими сторонними поставщиками инструментов. Microsoft даже потребовала от поставщиков приложений использовать стандартный установщик и сертифицировать свою программу установки для правильной работы, прежде чем им будет разрешено использовать логотип Microsoft. Подход «добросовестного установщика» не смягчил проблему, поскольку рост популярности Интернета предоставил больше возможностей для получения несовместимых приложений.

Использование вредоносным ПО

Неопределенность, с которой библиотеки DLL, которые не полностью квалифицированы, могут быть загружены в операционную систему Windows, была использована вредоносное ПО за последние годы[когда?], открывая новый класс уязвимостей, который затрагивает приложения от многих различных поставщиков программного обеспечения, а также саму Windows.[6]

Решения

Различные формы DLL-ада были решены или смягчены на протяжении многих лет.

Статическая ссылка

Простое решение проблемы DLL Hell в приложении - это статическая ссылка все библиотеки, т.е. включить требуемую версию библиотеки в программу, вместо того, чтобы брать системную библиотеку с указанным именем.[7] Это распространено в приложениях C / C ++, где вместо того, чтобы беспокоиться о том, какая версия MFC42.DLL установлено, приложение компилируется для статической компоновки с теми же библиотеками. Это полностью исключает библиотеки DLL и возможно в автономных приложениях, использующих только библиотеки, которые предлагают статический вариант, как Библиотека Microsoft Foundation Class делает. Однако основная цель DLL - совместное использование библиотек времени выполнения между программами для уменьшения накладных расходов памяти - принесена в жертву; дублирование кода библиотеки в нескольких программах создает раздувание программного обеспечения и усложняет развертывание исправлений безопасности или новых версий зависимого программного обеспечения.

Защита файлов Windows

Проблема перезаписи DLL (называемая DLL топление от Microsoft) был несколько сокращен с Защита файлов Windows (ВПП),[8] который был введен в Windows 2000.[9] Это предотвращает перезапись системных библиотек DLL неавторизованными приложениями, если они не используют специальные Windows API которые позволяют это. По-прежнему может существовать риск того, что обновления от Microsoft несовместимы с существующими приложениями, но этот риск обычно снижается в текущих версиях Windows за счет использования параллельные сборки.

Сторонние приложения не могут обрабатывать файлы ОС, если они не связывают законные обновления Windows со своим установщиком или если они не отключают Защита файлов Windows service во время установки, а в Windows Vista или более поздних версиях также становятся владельцами системных файлов и предоставляют себе доступ. В SFC Утилита может отменить эти изменения в любое время.

Одновременный запуск конфликтующих DLL

Решения здесь заключаются в наличии разных копий одних и тех же DLL для каждого приложения как на диске, так и в памяти.

Простым ручным решением конфликтов было размещение разных версий проблемной DLL в папках приложений, а не в общей общесистемной папке. В целом это работает, если приложение является 32-разрядным или 64-разрядным и DLL не использует разделяемую память. В случае 16-битных приложений два приложения не могут выполняться одновременно на 16-битной платформе или на одной и той же 16-битной виртуальной машине в 32-битной операционной системе. OLE предотвращало это до Windows 98 SE / 2000, потому что более ранние версии Windows имели единый реестр COM-объектов для всех приложений.

Windows 98 SE / 2000 представила решение под названием параллельная сборка,[10] который загружает отдельные копии DLL для каждого приложения, которому они требуются (и, таким образом, позволяет приложениям, которым требуются конфликтующие библиотеки DLL, работать одновременно). Этот подход устраняет конфликты, позволяя приложениям загружать уникальные версии модуля в свое адресное пространство, сохраняя при этом основное преимущество совместного использования библиотек DLL между приложениями (т. Е. Сокращение использования памяти) за счет использования методов сопоставления памяти для совместного использования общего кода между различными процессами, которые все еще работают. используйте тот же модуль. Однако библиотеки DLL, использующие общие данные между несколькими процессами, не могут использовать этот подход.[11] Одним из отрицательных побочных эффектов является то, что потерянные экземпляры DLL могут не обновляться во время автоматизированных процессов.

Портативные приложения

В зависимости от архитектуры приложения и среды выполнения, портативные приложения может быть эффективным способом уменьшить некоторые проблемы с DLL, поскольку каждая программа связывает свои собственные частные копии любых требуемых DLL.[9] Механизм основан на том, что приложения не полностью определяют пути к зависимым библиотекам DLL при их загрузке, а операционная система выполняет поиск в каталоге исполняемых файлов до любого общего расположения.[12] Однако этот метод также может быть использован вредоносными программами,[13] и повышенная гибкость также может происходить за счет безопасности, если частные библиотеки DLL не обновляются с помощью исправлений безопасности так же, как общие.

Виртуализация приложений может также позволить приложениям работать в «пузыре», что позволяет избежать установки файлов DLL непосредственно в операционную систему.

Другие меры противодействия

Есть и другие контрмеры, чтобы избежать DLL Hell, некоторые из которых, возможно, придется использовать одновременно; некоторые другие функции, которые помогают смягчить проблему:

  • Инструменты установки теперь включены в Microsoft Visual Studio, одна из основных сред разработки для Windows. Эти инструменты выполняют проверку версии перед установкой DLL и могут включать предопределенные установочные пакеты в установку .MSI. Это позволяет сторонним приложениям интегрировать обновления компонентов ОС без необходимости писать собственные установщики для этих компонентов.
  • Восстановление системы может восстановить систему после неправильной установки, включая повреждение реестра. Хотя это не предотвращает проблему, но облегчает ее восстановление.
  • WinSxS (Окна бок о бок), что позволяет сосуществовать нескольким версиям одних и тех же библиотек.
  • Запускайте 16-разрядные приложения в отдельном пространстве памяти в 32-разрядной версии Windows, чтобы два приложения могли одновременно использовать конфликтующие версии одной и той же библиотеки DLL.
  • Используйте версию Windows, которая включает Защита файлов Windows. Windows Me и Windows 2000обе версии, выпущенные в 2000 году, поддерживают эту форму защиты системных файлов, как и Windows XP и Windows Server 2003. Его замена, Защита ресурсов Windows, был представлен в Windows Vista и Windows Server 2008 и использует другой метод защиты системных файлов от изменений.
  • COM без регистрации: Windows XP представил новый режим регистрации COM-объекта под названием "COM без регистрации". Эта функция позволяет приложениям, которым необходимо установить объекты COM, сохранять всю необходимую информацию реестра COM в собственном каталоге приложения, а не в глобальном системном реестре. Таким образом, он обеспечивает механизм для нескольких версий одной и той же библиотеки DLL. быть зарегистрированным одновременно несколькими приложениями (Microsoft называет это "Параллельная сборка"[14]). DLL-ада можно в значительной степени избежать, используя COM без регистрации, единственное ограничение - требуется как минимум Windows XP или более поздних версий Windows и что его нельзя использовать для серверов EXE COM или общесистемных компонентов, таких как MDAC, MSXML, DirectX или Internet Explorer.
  • Доставка операционной системы с возможностью система управления пакетами который может отслеживать зависимости DLL, поощряя использование диспетчера пакетов и препятствуя ручной установке DLL. Установщик Windows, в комплекте с Windows Me, Windows 2000 и все более поздние версии предоставляют эту функцию.
  • Наличие центральной базы данных или полномочий для разрешения конфликтов DLL и распространения программного обеспечения. Изменения в библиотеке могут быть переданы в этот орган; таким образом, он может гарантировать сохранение совместимости в разработанных ветвях. Если какое-то более старое программное обеспечение несовместимо с текущей библиотекой, орган может предоставить для него интерфейс совместимости или связать старую версию как отдельный пакет.
  • Если разработчикам программного обеспечения необходимо настроить библиотеку, и если выпуск основной библиотеки вряд ли будет включать необходимые им изменения, они могут отправить настроенную DLL для личного использования программы (обычно путем помещения ее в частный каталог программы) или статически связать программа против настроенной библиотеки.
  • Хотя библиотеки DLL лучше всего подходят для модульного построения приложений и компонентов системы, а также в качестве сторонних библиотек, их использование не обязательно во всех случаях в современных системах, где память больше не является ограничением. Например, если приложению нужна библиотека, которая больше нигде не будет использоваться, ее можно связать статически, без потери места и с увеличением скорости.
  • Windows Vista и более поздние версии используют специальный Доверенный установщик сервис для установки файлов операционной системы. Другие учетные записи пользователей, включая SYSTEM, не имеют доступа к перезаписи основных системных двоичных файлов. Windows 7 расширяет эту функциональность до некоторых критических частей реестра.
  • Веб-приложения избежать множества параллельных проблем, запустив основную часть кода на сервере и используя интерфейс браузера на клиенте.

Смотрите также

использованная литература

  1. ^ «Как избежать ада DLL: введение метаданных приложения в Microsoft .NET Framework». Microsoft. Октябрь 2000 г.
  2. ^ «Сводка статей о CTL3D.DLL в базе знаний службы поддержки Майкрософт». Microsoft.
  3. ^ Распространение общего компонента среды выполнения C в Visual C ++ 2005 и Visual C ++ .NET.
  4. ^ KB 830490: принтер HP Color LaserJet печатает только в оттенках серого или в черно-белом режиме на компьютере под управлением Windows 2000 SP4.
  5. ^ Лесли Мюллер; Стив Уайт (июль 2005 г.). «Активация COM-компонентов без регистрации: пошаговое руководство». Microsoft.
  6. ^ «Безопасная загрузка библиотек для предотвращения атак предварительной загрузки DLL». Microsoft. 2011-06-11. Получено 2011-07-19.
  7. ^ Пфайффер, Тим (1998-06-01). "Windows DLL: угроза или угроза?". Журнал доктора Добба. Архивировано из оригинал на 2010-08-07. Получено 2010-07-07.
  8. ^ Защита файлов Windows и Windows.
  9. ^ а б Андерсон, Рик (2000-01-11). "Конец ада DLL". microsoft.com. Архивировано из оригинал на 2001-06-05. Получено 2010-07-07.
  10. ^ «Внедрение параллельного совместного использования компонентов в приложениях (расширено)». Microsoft. Архивировано из оригинал 10 декабря 2006 г.. Получено 3 января 2013.
  11. ^ «Как мне поделиться данными в моей DLL с приложением или с другими DLL?». Microsoft. Получено 2008-11-11.
  12. ^ Деситтер, Арно (2007-06-15). «Использование статических и общих библиотек на разных платформах; строка 9: путь к библиотеке». Арно Рецепты. Архивировано из оригинал на 2008-06-01. Получено 2010-07-07.
  13. ^ «Безопасная загрузка библиотек для предотвращения атак с предварительной загрузкой DLL». Microsoft. Получено 16 февраля 2013.
  14. ^ Параллельные сборки (Windows)

внешние ссылки