Есть библиотека, которую используют несколько програм.
Постоянно
прописывать путь при открытии - не совсем удобно. Как
зарегистрировать
DLL-ку, чтобы можно было обратиться к ней только по имени?
Уважаемые авторы вопросов! Большая просьба сообщить о результатах решения проблемы на этой странице. Иначе, следящие за обсуждением, возможно имеющие аналогичные проблемы, не получают ясного представления об их решении. А авторы ответов не получают обратной связи. Что можно расценивать, как проявление неуважения к отвечающим от автора вопроса.
11-08-2004 18:27
вообще-то существует
REGSVR32.EXE C:\WINDOWS\system32\mydll.dll
2 Алексей Вуколов
Да, конечно, я имел в виду динамически импортированные библиотеки. Видимо,
я не совсем четко сформулировал ответ, поскольку для своих библиотек
практически всегда пользуюсь динамическим импортом
to MK:
И все-таки это не работает для статически импортированных DLL.
Для динамически импортированных - да.
Вот цитата из MSDN (переводить не буду).
This entry is effective for most general uses of the PATH environment
in an application. However, it will not be effective for any implicitly
linked DLLs that reside in a directory listed in the App Paths registry.
Implicitly linked DLLs are loaded before the task is fully created and
receives the modified PATH environment variable. At that time the system
uses the Kernel's environment. The DLL will not be found by the system
if it does not reside in the usual places where it may find DLLs.
А что касается Delphi, то там большая часть, в основном в каталоге
приложения находится, есть кое-что в system32, но в основном
используется динамический импорт. То же самое с MS Office, но там
еще и COM используется.
2 Алексей Вуколов
Это не может не работать, поскольку в данном случае работа с большими
пакетами приложений, например MS Office, NU, Delphi, котрые разбрасывают
свои библиотеки в разные каталоги (без добавления этих путей в autoexec.bat)
была бы невозможной. Естественно,
это можно было бы обойти и другими способами, но то что способ функционален,
(по крайней мере у меня (Win95 OSR2)) это точно. И используются эти
пути именно для поиска DLL. Я сам использую этот способ в своих приложениях,
которые работают не только в Win95
Данные сведения в более подробном виде содержатся в книге
"Руководство программиста по Microsoft Windows 95", {Microsoft Press)
русское издание с исправлением допущенных в оригинале ошибок.
P.S. Возможно, у Вас опечатка, но ключ называется "App Paths"
К стати, про запись в "App Path". Что-то оно не работает...
Возможно, что к переменной Path в окружении программы эти пути
добавляются, но при поиске DLL, похоже не используются. Либо у
меня что-то с руками. ;o)
А вот самый надежный способ все-таки, видимо, изменение
системной переменной окружения path.
Добавлю, что в случае, когда библиотека лежит в каком-то определенном
каталоге, и ее местоположение никак не прописано в Path, то придется
использовать динамический импорт, что не всегда приемлемо и удобно.
Несколько дополню предыдущие ответы.
Если Вам нужно, чтобы разделяемую DLL "видели" различные программы, то
нужно выполнить следующее:
В раздел HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\SharedDLLs
добавить параметр DWORD с именем Вашей DLL и значением, указывающим
количество программ-пользователей данной DLL. Эти параметры обычно
устанавливаются и обновляются программами-инсталляторами и деинсталляторами;
возможно, Вам встречалась ситуация, когда деинсталлятор спрашивает
разрешения удалить разделяемую DLL - это означает, что уменьшенный
деинсталлятором счетчик пользователей данной DLL дошел до нуля. Кроме
того имя DLL должно указываться с полным путем (посмотрите для примера реестр).
Уточнение: HKEY_LOCAL_MACHINE можно заменить на HKEY_CURRENT_USER, а
параметры также могут быть двоичного и строкового типа, но подобные
вещи считаются некорректными, хотя и допустимы, кроме того в данном
разделе реестра можно писать и имена других файлов, например .exe:
получается своеобразная замена переменной PATH (кстати, ведь можно использовать и ее).
Ну и в дополнение, если исполняемый файл и используемые им библиотеки
находятся в различных каталогах, то в раздел
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\App Paths
нужно добавить ключ, соответствующий имени Вашей программы без пути,
например BUZZER.EXE, и в этот ключ добавить:
1. значение по умолчанию, соответствующее полному имени файла (с путем)
2. строковый параметр Path, определяющий каталоги с файлами в формате
задания переменной Path в autoexec.bat
Теперь при запуске программы значение Path будет добавлено к системной
переменной Path (каламбур получился, но я надеюсь, что все понятно)
Обычно разделяемые файлы хранятся в каталоге, удовлетворяющем таким
условиям:
\Program Files\Common Files\<фирма> Shared\, например
C:\Program Files\Common Files\Borland Shared
P.S. Хотя решением данного вопроса является также ответ Алексея Вуколова,
я присоединяюсь к мнению Юрия Зотова и добавлю лишь, что при помещении
библиотек в каталог Windows\System можно легко забыть, что именно туда
добавлялось из-за исключительно большого количества файлов в этих каталогах.
Не уверен, но, возможно ее надо прописать в реестре под ключом KnownDLLs.
И совершенно точно, что Вы можете положить свою разделяемую DLL куда угодно
(обычно для этого заводят свой подкаталог в Common Files), а в реестре
создать свой ключ Software\MySoft, который может указывать на все, что нужно
любой Вашей программе для работы с разделяемыми DLL и другими файлами.
Это общепринятый подход. Для примера посмотрите, как организован Common Files
и сделайте поиск его названия в реестре.
А кидать все подряд в системные каталоги считаю не лучшим тоном.
Понятия "зарегистрировать DLL-ку" не существует, а для решения Вашей
проблемы достаточно положить библиотеку в каталог Windows\System или
Windows\System32 (зависит от ОС).
Если вы заметили орфографическую ошибку на этой странице, просто выделите ошибку мышью и нажмите Ctrl+Enter. Функция может не работать в некоторых версиях броузеров.
