DLL hell (DLL-кошмар, буквально: DLL-ад) — тупиковая ситуация, связанная с управлением динамическими библиотеками DLL в операционной системе Microsoft Windows.
Аналогичная проблема в других ОС носит название Dependency hell.
Сущность проблемы заключается в конфликте версий DLL, призванных поддерживать определённые функции. DLL hell — пример плохой концепции программирования, которая, подобно скрытой мине, приводит к резкому возрастанию трудностей при усложнении и совершенствовании системы.
DLL (англ. Dynamic-link library — библиотека динамической компоновки) — понятие операционных систем Microsoft Windows и IBM OS/2; динамическая библиотека, позволяющая многократное применение различными программными приложениями. K DLL относятся также элементы управления ActiveX и драйверы. В мире UNIX аналогичные функции выполняют т. н. shared objects («разделяемые объекты»).
Формат файлов DLL придерживается тех же соглашений, что и формат исполняемых файлов, сочетая код, таблицы и ресурсы.
Цели введения DLL
Первоначально предполагалось, что введение DLL позволит эффективно организовать память и дисковое пространство, используя только один экземпляр библиотечного модуля для различных приложений. Это было особенно важно для ранних версий Microsoft Windows с жёсткими ограничениями по памяти.
Далее, предполагалось улучшить эффективность разработок и использования системных средств за счёт модульности. Замена DLL-программ с одной версии на другую должна была позволить независимо наращивать систему, не затрагивая приложений. Кроме того, библиотеки DLL могли использоваться разнотипными приложениями — например, Microsoft Office, Microsoft Visual Studio и т. п.
В дальнейшем идея модульности выросла в концепцию COM.
Фактически, полных преимуществ от внедрения DLL получить не удалось по причине явления, называемого DLL hell («ад DLL»). DLL Hell возникает, когда несколько приложений требуют одновременно различные, не полностью совместимые, версии DLL-библиотек, что приводит к сбоям в этих приложениях. Когда система выросла до определённых размеров, количество DLL стало превышать многие тысячи, не все из них обладали полной надёжностью и совместимостью, и конфликты типа DLL Hell стали возникать очень часто, резко понижая общую надёжность системы. Поздние версии Microsoft Windows стали разрешать параллельное использование разных версий DLL, что свело на нет преимущества изначального принципа модульности. Использование разных версий Dll стало возможным благодаря файлу манифеста (manifest), который хранится в ресурсах приложения или в виде отдельного файла в одном с приложением каталоге.
Описание проблемы
По исходному замыслу, DLL должны быть совместимыми от версии к версии и взаимозаменяемыми в обе стороны.
Реализация механизма DLL, такова, что несовместимость и невзаимозаменяемость становится скорее правилом, чем исключением, что приводит к большому количеству проблем.
Отсутствие стандартов на имена, версии и положение DLL в файловой структуре приводит к тому, что несовместимые DLL легко замещают друг друга или отключают друг друга
Отсутствие стандарта на процедуру установки приводит к тому, что установка новых программ приводит к замещению работающих DLL на несовместимые версии
Отсутствие поддержки DLL со стороны линкеров и механизмов защиты приводит к тому, что несовместимые DLL могут иметь одно и то же имя и одну и ту же версию
Отсутствуют стандартные инструменты идентификации и управления системой DLL пользователями и администраторами
Использование отдельных DLL для обеспечения связи между задачами приводит к нестабильности сложных приложений
Для избежания конфликтов обычно используют множество избыточных копий DLL для каждого приложения, что сводит на нет исходную идею получения преимущества от DLL как стандартных модулей, хранящихся один раз в памяти и разделяемых многими задачами. Кроме того, при таком опыте после исправления ошибок в DLL или восстановления системы из архива количество различных DLL, носящих одно и то же имя и выполняющих те же функции, возрастает, а автоматическое обновление версии или исправление ошибок становится невозможным.
История проблемы
Эта проблема возникла в ранних версиях Microsoft Windows.
С подобными же проблемами сталкивались ранние версии Mac OS X, но с использованием других технологий. Не избегают подобных проблем дистрибуторы библиотек Open Source.
Поэтому, когда речь идёт о не-майкрософтовской среде, эту ситуацию называют dependency hell (кошмар зависимостей).
Проблема постоянно повторяется, когда программу пытаются запустить не с той DLL, c которой она тестировалась, что показывает изначальную порочность общей концепции, позволяющей произвольную замену версий модулей.
Меры против DLL hell
Данные меры рекомендуют предпринимать одновременно для получения наилучшего результата:
подсчитать контрольную сумму кода функции вызываемой из DLL - сравнить с контрольной суммой функции используемой при написании программы.
Операционная система должна поставляться совместно с менеджером пакетов, чтобы иметь возможность прослеживать все взаимозависимости DLL, при этом использование менеджера пакетов должно поощряться, а индивидуальная инсталляция DLL — по возможности отвергаться.
Централизованное распространение библиотек
Допустить возможность параллельного использования нескольких версий одной и той же DLL [1].
При модификации программного обеспечения для частного использования поставлять также модифицированные версии DLL.
Во время проектирования DLL должна тщательно продумываться концепция функций и версий. DLL не должны использоваться без необходимости, а библиотеки, связанные только с одним приложением, должны подключаться статически (в EXE-файл).