У меня есть процесс, который загружает DLL из места, не указанного в задокументированном порядке поиска (документы, ссылки на которые приведены ниже). Я хочу знать, почему.
Вот описание моей установки:
- У меня есть папка 'c: \ foo', содержащая a.dll и b.dll.
- У меня есть скрипт на python, который также хранится в c: \ foo.
- Скрипт Python выполняет LoadLibrary ('c: /foo/a.dll') (через ctypes)
- a.dll связан с библиотекой импорта для b.dll (т. Е. Используется неявное связывание).
- Я запускаю скрипт python с текущим каталогом, скажем, c :. Это может быть что угодно.
- b.dll загружается из c: \ foo, хотя его нет в пути поиска.
- Глядя на трассировку монитора процессов, я вижу, что сначала были опробованы все документированные пути поиска, и все они оказались неудачными. Затем процесс python попытался и не смог открыть «C: \ WINDOWS \ assembly \ GAC \ Microsoft.VC80.CRT.mui \ 8.0.50727.4053_en-US_1fc8b3b9a1e18e3b \ Microsoft.VC80.CRT.mui.DLL», , затем он открыл c: \ foo \ b.dll.
Итак, похоже, что в каталоге a.dll ищется b.dll, хотя в документах об этом не говорится. Кроме того, это происходит после просмотра системного пути, который является безумным. Кто-нибудь может пролить свет на это?
То же самое происходит со скриптом MatLab, который также использует ..dll.
Я использую Windows XP SP 3.
В этой статье MSDN объясняется порядок поиска по умолчанию. Я цитирую:
- Каталог, указанный в lpFileName.
- Системный каталог. Используйте функцию GetSystemDirectory, чтобы получить путь к этому каталогу.
- 16-битный системный каталог. Нет функции, которая получает путь к этому каталогу, но она ищется.
- Каталог Windows. Используйте функцию GetWindowsDirectory, чтобы получить путь к этому каталогу.
- Текущий каталог.
- Каталоги, перечисленные в переменной среды PATH. Обратите внимание, что сюда не входит путь для каждого приложения, указанный в разделе реестра «Пути к приложениям». Ключ App Paths не используется при вычислении пути поиска DLL.