Порядок поиска dll ок

← →
Borealis (2003-08-13 14:33) [0]

В каком порядке производится поиск нужной приложению dll?
Сначала в каталоге с exe, потом в системных виндовса, а потом в переменных path. Вроде я сам ответил на свой вопрос, но на самом деле это не полный ответ. Из этого ответа не понятно как получить путь к dll которая реально будет загружена.
Или может есть какая функция для этого? (но я её не нашёл)

ps. Вопрос получился немного сумбурным, но я честное слово переписывал его несколько раз - это лучший вариант :)

← →
Skier (2003-08-13 14:41) [1]

Цель-то конечная какая ?

← →
Dimka Maslov (2003-08-13 14:47) [2]

Используй функции LoadLibrary и GetProcAddress, а не статическую компоновку.

← →
Reindeer Moss Eater (2003-08-13 14:55) [3]

LoadLibrary тоже может не дать прямого ответа на вопрос какая библиотека загрузилась.

← →
clickmaker (2003-08-13 15:07) [4]

А GetModuleFileName на что?

← →
AlexKniga (2003-08-13 15:11) [5]

Где ищутся DLL?
Ответ для 9х:
1) Каталог откуда запустился exe"шник
2) Текущий каталог
3) System32
4) System
5) Windows
6) %PATH%

Если в реестре для данной библиотеке прописан специальный путь поиска, то используется он.

Если в памяти уже есть библиотека с таким же именем, то используется она.

← →
Reindeer Moss Eater (2003-08-13 15:12) [6]

Если в реестре для данной библиотеке прописан специальный путь поиска, то используется он.

Поправка:
Если в реестре для данного приложения прописан специальный путь поиска, то используется он.

← →
Dimka Maslov (2003-08-13 15:16) [7]

>Reindeer Moss Eater © (13.08.03 14:55) [3]
LoadLibrary позволяет явным образом указать путь к загруженной библиотеке.

Второй путь - сделать из библиотеки COM-сервер c пропиской в реестре, тогда можно быть уверенным, что загрузится нужная библиотека

← →
Reindeer Moss Eater (2003-08-13 15:20) [8]

Dimka Maslov
LoadLibrary тоже может не дать прямого ответа на вопрос какая библиотека загрузилась.

← →
AlexKniga (2003-08-13 15:31) [9]

Reindeer Moss Eater © (13.08.03 15:12) [6]
Да.

← →
Borealis (2003-08-13 15:36) [10]

> Dimka Maslov © (13.08.03 14:47) [2]
> Используй функции LoadLibrary и GetProcAddress, а не статическую компоновку.
Забыл сказать, что это два разных приложения: одно которое собственно загружает (требует) dll, а второе которое должно "угадать" какую из dll загрузит первое приложение. И находятся эти два приложения в совершенно разных каталогах и друг с другом никак не связаны.

Я провёл маленький эксперимент - написал приложение которое требует dll которого не существует, и изменил переменные окружения "path" следующим образом: пользовательский "path": "c:\apath", а системный "path": "d:\apath". После запуска этого приложения естественно появляется сообщение об ощибке такого содержания:

TestPath.exe - Unable To Locate DLL
The dynamic link library kernel34.dll could not be found in the specified path E:\Programs\Delphi6\Projects\Test\path;.;E:\WINNT\System32;E:\WINNT\sy stem;E:\WINNT;E:\Programs\Far1705;d:\apath;c:\apath.

Т.е. сначала ищет в текущем каталоге (потом в какойто точке[?] какая разница между текущим каталогом и точкой я не понял), потом в системных папках, потом в системной "path" и наконец в пользовательском "path".
И тут возникает сразу два вопроса:
1. Откуда берётся информация о расположении системных каталогов (ведь под другой версией винды они могут быть и другими).
2. Что это за странную информацию мне возвращает функция GetEnvironmentVariable: E:\Programs\Delphi5\Bin;d:\apath;c:\apath?

Но это всё относится к "ручному" способу, а вот может есть какая стандартная функция?

← →
AlexKniga (2003-08-13 15:45) [11]

Borealis (13.08.03 15:36) [10]> пользовательский "path": "c:\apath", а системный "path": "d:\apath"
???

← →
Reindeer Moss Eater (2003-08-13 15:51) [12]

1. Откуда берётся информация о расположении системных каталогов (ведь под другой версией винды они могут быть и другими).

Хочешь сказать что странно, когда Windows знает где у нее её системные каталоги и странно когда Windows знает кто она - Nt или 9x?

← →
Borealis (2003-08-13 16:02) [13]

> AlexKniga © (13.08.03 15:45) [11]
> Borealis (13.08.03 15:36) [10]>пользовательский "path":
> "c:\apath", а системный "path": "d:\apath"
> ???
:)
Ну если нажать правой кнопкой на иконке "My Computer", щёлкнуть по "Properties", выбрать закладку "Advanced" и нажать кнопку "Environment variables..." появится окно с двумя ListView"ами, верхнее озаглавлено как "User variables for Borealis", нижнее как "System variables" и там и там можно добавлять/изменять переменные окружения, в том числе и "Path". Но это собственно не важно - функция GetEnvironmentVariable возвращает эти переменные слитно, хотя и с каким то мусором :(
Да и ещё в сообщении о ненайденой dll присутствует какая то непонятная строка: "E:\Programs\Far1705" откуда она взялась?

ps. Вышеприведённая последовательность действий относится только к англоязычной Win2k

← →
Borealis (2003-08-13 16:23) [14]

> Reindeer Moss Eater © (13.08.03 15:51) [12]
Хочешь сказать что странно, когда Windows знает где у нее её системные каталоги и странно когда Windows знает кто она - Nt или 9x?
Было бы странно есди бы я сказал что это странно :) Я спрашивал откуда взять эту информацию (порядок тоже имеет значение!)

Но это уже сильное отклонение от моего первоначального вопроса, наверно мой вопрос неправильно поняли поэтому я его немного перефразирую:
Если удалить нужные приложению dll"ки, то при его запуске появится сообщение которое я приводил выше, т.е. что я dll искал-искал по таким путям: "E:\Programs\Delphi6\Projects\Test\path;.;E:\WINNT\System32;E:\WINNT\s ystem;E:\WINNT;E:\Programs\Far1705;d:\apath;c:\apath" но не нашёл.
Вопрос: как узнать вышеприведённую строку "поиска" (т.е. по каким путям приложение искало - точнее по каким искало бы). Фух. Ну проще я уже наверно не смогу объяснить свою проблему :(

← →
Reindeer Moss Eater (2003-08-13 16:27) [15]

т.е. по каким путям приложение искало - точнее по каким искало бы.

Ищет не приложение. Ищет Windows.

← →
AlexKniga (2003-08-13 16:29) [16]

Borealis
В коммандной строке запусти команду Path

← →
Borealis (2003-08-13 16:43) [17]

> Reindeer Moss Eater © (13.08.03 16:27) [15]
> т.е. по каким путям приложение искало - точнее по каким
> искало бы.
> Ищет не приложение. Ищет Windows.
Согласен. Но знание этого, меня не пододвинуло к решению проблемы ни на шаг :(

> AlexKniga © (13.08.03 16:29) [16]
> Borealis
> В коммандной строке запусти команду Path
Запустил. Получил тоже, что и функцией GetEnvironmentVariable: "E:\Programs\Far1705;d:\apath;c:\apath"

← →
Reindeer Moss Eater (2003-08-13 16:50) [18]

Согласен. Но знание этого, меня не пододвинуло к решению проблемы ни на шаг :(

Тут никто в суть твоей проблемы не может въехать.

← →
Borealis (2003-08-13 17:27) [19]

> Reindeer Moss Eater © (13.08.03 16:50) [18]
> Согласен. Но знание этого, меня не пододвинуло к решению
> проблемы ни на шаг :(
> Тут никто в суть твоей проблемы не может въехать.

Ок. Объясню во всех подробностях.
Есть некое (рабочее) приложение и находится в некотором каталоге. (Кто написал это приложение и в каком каталоге находится не имеет значения). Это приложение для своей работы требует кучу dll. Стоп! На самом деле кучу bpl. Теперь уже моё приложение из PE заголовка того приложения получает спиок требуемых библиотек, отсеивает от *.dll - остаются только *.bpl. Теперь моё приложение должно найти все эти *.bpl и собрать в один каталог. Можно конечно втупую просканировать весь винчестер(!). Но во-первых хочется както более рационально, а во-вторых на винте могут быть устаревшие *.bpl с которыми то приложение работать не будет(!). Устаревшие *.bpl могут быть как и в "непрописанных" каталогах, но приложение тем не менее работает, так как устаревшие *.bpl находятся в более "поздних" каталогах и до них очередь не доходит. Это наверно стОит объяснить подробнее: например устаревшая(нерабочая) *.bpl находится в каталоге "E:\WINNT", а более новая(рабочая) в каталоге "E:\WINNT\System32", тем не менее приложение работает нормально так как путь "E:\WINNT\System32" стоит в очереди просмотра раньше чем путь "E:\WINNT" и соответственно загружается новая(рабочая) *.bpl из каталога "E:\WINNT\System32".

ps. Вы извините если я немного резко отвечаю, просто я немного нервничаю (скоро уже нужно показывать результат) и разговаривать на отвлечённые темы меня не тянет. :(

← →
Borealis (2003-08-13 17:28) [20]

← →
Reindeer Moss Eater (2003-08-13 17:31) [21]

Теперь моё приложение должно найти все эти *.bpl и собрать в один каталог.

1. Определи ОС
2. Воспользуйся перечнем каталогов для поиска конкретной ОС
3. Посмотри в реестр на предмет каталогов поиска, зарегистрированных для того приложения.
4. Ищи в том же порядке, что и Windows

← →
Borealis (2003-08-13 17:45) [22]

> Reindeer Moss Eater © (13.08.03 17:31) [21]
> 1. Определи ОС
> 2. Воспользуйся перечнем каталогов для поиска конкретной ОС
Т.е. однозначного ответа не существует?

> 3. Посмотри в реестр на предмет каталогов поиска, зарегистрированных
> для того приложения.
?

> 4. Ищи в том же порядке, что и Windows
" том же порядке, что и Windows" Вот именно этого я и пытаюсь добиться... :(

← →
Reindeer Moss Eater (2003-08-13 17:48) [23]

Т.е. однозначного ответа не существует?
Существует

"том же порядке, что и Windows" Вот именно этого я и пытаюсь добиться... :(

То, чего ты добиваешься, находится в ЛЮБОЙ книжке по Delphi, в которой есть описание работы с DLL.
Там описана последовательность перебора системой каталогов прии загрузке бибиотек.

Впрочем, уверен, что и во встроенной документации это описано.

← →
Reindeer Moss Eater (2003-08-13 17:49) [24]

В посте №5 тебе уже показали этот порядок поиска для Win9x.

← →
Borealis (2003-08-13 18:19) [25]

> Reindeer Moss Eater © (13.08.03 17:48) [23]
> То, чего ты добиваешься, находится в ЛЮБОЙ книжке по Delphi,
> в которой есть описание работы с DLL.
> Там описана последовательность перебора системой каталогов
> прии загрузке бибиотек.
И я их читал. Т.е. описанная последовательность является жёсткой и её ничем нельзя нарушить?

> Reindeer Moss Eater © (13.08.03 17:49) [24]
> В посте №5 тебе уже показали этот порядок поиска для Win9x.
Я только что заметил что функция GetEnvironmentVariable возвращает "E:\Programs\Delphi5\Bin;d:\apath;c:\apath", а path в командной строке: "E:\Programs\Far1705;d:\apath;c:\apath". Почему они так отличаются?

← →
Reindeer Moss Eater (2003-08-13 18:22) [26]

Т.е. описанная последовательность является жёсткой и её ничем нельзя нарушить?
Ну почему же ничем. Вот издаст B.Gates распоряжение по конторе переписать код загрузки DLL и все изменится в один час.

Я только что заметил что функция GetEnvironmentVariable возвращает "E:\Programs\Delphi5\Bin;d:\apath;c:\apath", а path в командной строке: "E:\Programs\Far1705;d:\apath;c:\apath". Почему они так отличаются?

в командной строке FAR"A?

← →
Borealis (2003-08-13 20:04) [27]

> Reindeer Moss Eater © (13.08.03 18:22) [26]
> Т.е. описанная последовательность является жёсткой и её
> ничем нельзя нарушить?
> Ну почему же ничем. Вот издаст B.Gates распоряжение по конторе
> переписать код загрузки DLL и все изменится в один час.
Т.е. совет по поводу " ЛЮБОЙ книжке по Delphi, в которой есть описание работы с DLL" считается недействительным?

Вот буквально только что нашёл в инете такую ссылку: http://www.listsoft.ru/tips/456/

-=begin=-
Эта настройка может пригодиться, чтобы заставить программу, запускаемую по сети использовать локальные dll-ки, а также в тех случаях, когда первой загружается неправильная версия dll. Запустите regedit и найдите ветвь HKLM\SYSTEM\CurrentControlSet\Control\Session Manager Создайте новый DWORD ключ с именем "SafeDllSearchMode" (или измените существующий) и установите его значение в 1, если вы хотите заставить Windows сначала искать библиотеки в System и Windows папках, или в 0, если вы хотите, чтобы сначала проверялась текущая директория. Для того, чтобы настройка заработала понадобится перезагрузить компьютер.
-=end=-

Т.е. ответ, что однозначный ответ сеществует тоже считается недействительным?

> Я только что заметил что функция GetEnvironmentVariable
> возвращает "E:\Programs\Delphi5\Bin;d:\apath;c:\apath",
> а path в командной строке: "E:\Programs\Far1705;d:\apath;c:\apath".
> Почему они так отличаются?
>
> в командной строке FAR"A?
Понятно, этот вопрос снимается.

← →
Reindeer Moss Eater (2003-08-14 09:03) [28]

Т.е. ответ, что однозначный ответ сеществует тоже считается недействительным?

Ответ считается действительным. И ответ этот однозначный.

Приведенный выше пример ничего не меняет. Он лишь говорит, что существует еще одно правило поиска DLL. И правило это выполняется при вполне определенных условиях.

← →
AlexKniga (2003-08-14 10:00) [29]

Borealis
Твоя задача (Borealis (13.08.03 17:28) [20]) решается совсем другим путем.
Внедряешься в АП целевого приложения и GetModuleFileName.
Можно сделать это и чисто пользовательским путем, не кодируя не одной строки.
Юзай ProcExp от www.sysinternals.com

← →
Игорь Шевченко (2003-08-14 11:59) [30]

О порядке поиска DLL подробно написано в win32.hlp в справке по LoadLibrary.
В http://msdn.microsoft.com написано еще подробнее :)

Порядок поиска dll ок Найти похожие ветки