Комментарии 11
НЛО прилетело и опубликовало эту надпись здесь
Этот момент я еще уточнил — по задумке зависимости от переменной path вообще не должно было быть (собственно это одна из причин почему мы свои пути туда не прописываем), т.к. делались приседания по загрузке .dll только из путей, которые нам известны в явном виде. Таким образом должна была быть защита как раз от подмены .dll по системным путям, и здесь была проблема в том, что этот механизм не отработал.
Единственное где такой механизм не сработает, это если из одной .dll дергается другая сторонняя библиотека, а из этой 2ой дергается еще одна 3я. Вот как раз на последнюю .dll заложиться нельзя, и она может искаться по системным путям (т.к. эта логика прописана во 2ой .dll, на которую влияния не имеем — не наш код)
Единственное где такой механизм не сработает, это если из одной .dll дергается другая сторонняя библиотека, а из этой 2ой дергается еще одна 3я. Вот как раз на последнюю .dll заложиться нельзя, и она может искаться по системным путям (т.к. эта логика прописана во 2ой .dll, на которую влияния не имеем — не наш код)
А есть ли в винде вообще аналог rpath или только курить бамбук и надеяться, что никто не поломает PATH?
Можно складывать dll-файлы рядом с exe или переименовывать их, добавляя в название библиотек версию самой библиотеки и имя продукта, который их использует, чтобы не было пересечений по общим именам, таким, как libxml2.dll.
Можно использовать для этих целей манифест
Вообще, полный порядок загрузки dll под всеми поддерживаемыми версиями Windows описан здесь. Как было сказано, можно иметь в наличии все версии конкретной dll и при помощи манифестов связаться с конкретной версией, если же подобная гибкость не нужна — то есть SetDllDirectory/AddDllDirectory, которые в комбинации с SetDefaultDllDirectories позволяют полностью контроллировать откуда будут загружаться dll. Единственный нюанс: разрешение зависимостей в IAT происходит до выполнения кода, который может установить пути — в этом случае либо манифест, либо delayload для тех dll-ок, которые могут прийти из разных мест.
Описанный глюк давно известен под названием DLL hell и для борьбы с ним еще в начале 2000-х Microsoft придумала .NET платформу, с манифестами сборок и GAC-ом.
Нет для борьбы с этим Microsoft придумала папку Windows\winsxs
Ну, Windows Side by Side они придумали несколько позже — начиная с Висты, и сама идея реализована по образу и подобию GAC-а
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Грабли при использовании общих .dll