по результатам последнего FB installer survey решил устыдиться и искать клиенткую либу в реестре

win7 x64 / fb 2.1 x86 / fb 2.5.5 x64 / fb 3rc x64 (установленны стандартными GUI-установщиками)

HKCU\Software - следов firebird'a не вижу

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Firebird Project - пустая папка

HKEY_LOCAL_MACHINE\SOFTWARE\Firebird Project\Firebird Server\Instances

один единственный ключ DefaultInstance=C:\Program Files\Firebird\Firebird_2_5\


Итого - для моей 32-битной программы в реестре вообще ничего полезного нет, для 64-битных же программ есть только намёк, где можно пoискать одну из клиентских библиотек (если точно знаешь название), не самую последнюю к тому же (но возможно пока для 3rc отдельные правила, чтобы не прописывался *пока* в реестр). Названия же библиотеки, тем паче списка версий и названий - нет.

Ищем "fbclient.dll" в стандартных местах Windows

HKCR, HKCU - пусто

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\SharedDLLs
C:\Program Files\Firebird\Firebird_2_5\bin\fbclient.dll=4
C:\Program Files\Firebird\Firebird_2_5\WOW64\fbclient.dll=4
C:\Program Files\Firebird\Firebird_3_0\fbclient.dll=1
C:\Program Files\Firebird\Firebird_3_0\WOW64\fbclient.dll=1
C:\Windows\system32\FBCLIENT.DLL=1
C:\Windows\system32\GDS32.DLL=1

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\SharedDLLs
C:\Program Files (x86)\Firebird\Firebird_2_1\bin\fbclient.dll=5
C:\Windows\system32\FBCLIENT.DLL=3
C:\Windows\system32\GDS32.DLL=4

То есть возможно имеет место быть "курица и яйцо", но я пока не вижу как бы я мог использовать это в простой аппликухе лучше, чем простое LoadLibrary и пусть ищет в %Path%

Видно, что даже в Shared Libraries прописываются только библиотеки от fb 2.1, библиотеки же от 2.5/3.0 попали - в том числе 32-битные! - в 64-битный куст реестра, в который 32-битным аппликухам глядеть не резон.
И даже в этих местах искать можно только полным перебором по заранее известным именам DLL, после чего из самого файла читать его версию после пробной загрузки/выгрузки. IMHO хотя и гипотетически возможно, но практического смысла не имеет.

То есть остаются старые добрые "кладите весе в system32" и "правьте %PATH% чтобы показывал в firebird\WOW64 или firebird\bin".
Решения "проверенные временем" но чреватые DLL Hell, от которого - судя по наличию этого пункта отдельно в опроснике - создатели инсталлятора надеялись уйти. No way.

----

Для сравнения, записи в реестре сделанные другими программами, со сходной задачей - позволить наперёд неизвестным пользователям найти и загрузить нужную DLL

HKEY_CURRENT_USER\Software\MozillaPlugins\@mozilla.zeniko.ch/SumatraPDF_Browser_Plugin
Path=C:\Program Files (x86)\SumatraPDF\npPdfViewer.dll

HKEY_LOCAL_MACHINE\SOFTWARE\MozillaPlugins\@videolan.org/vlc,version=2.1.3
Path=C:\Program Files\VideoLAN\VLC\npvlc.dll

HKEY_LOCAL_MACHINE\SOFTWARE\MozillaPlugins\@Microsoft.com/NpCtrl,version=1.0
C:\Program Files\Microsoft Silverlight\5.1.41105.0\npctrl.dll

kdvв реестре про fbclient никогда не было,

тогда этот вопрос в опроснике не имел практического смысла.

И отсюда уже вопрос - хотят ли в принципе разработчики FB делать поиск клиентской библиотеке в реестре вместо DLL Hell

Если да - то это надо делать немного по другому.
Если нет - то такой вопрос в опроснике был чистой провокацией

Dimitry SibiryakovТы не поверишь, но может быть и наоборот

не может

32-битная программа без спец-ключа видит system32 как полную копию SysWOW64, а 64-битные библиоткеи не видит в принципе

64-битная программа или 32-битная со спец-ключом видят 32-битные в SysWOW64, а 64-битные в system32

но режима "наоборот" - то есть видеть 64-битные билиотеки в SysWOW64 - такого режима нет в принципе

Только, мышки мои, это частности, я же как мудрый филин вопрос "по стратегии" ставил

Можно/нужно ли уйти от DLL Hell через прописывание разных клиентских библиотек в реестре.
Чтобы изготовители инсталляторов не обижались на тупых прикладников и наоборот, что вполне возможно в случае разных неозвученных взаимных ожиданий.

DBConstructorArioch, а нафига?

Поскольку такой пункт был в опроснике про инсталлятор, я сделал предположение, что FB Team ожидает от прикладников именно этого как правильного поведения, а копирование gds32/fbclient/fbembed в system32 считает грязным legacy, который зажимая нос приходится тащить в новый чудесный мир из-за косности прикладников. Что-то типа fbguardian

DBConstructor,

так ведь нужно ещё определиться, что писать

то есть аппликуха должна, желательно, видеть ещё до попытки ткнуться в файл, про каждую DLL

1) версию частичную x.y
2) версию частичную x.y.z или даже x.y.z.bbbbb
3) разрядность
4) наличие embed-движка внутри DLL

Вообще мне в этом плане импонирует симлинковая система хранения dll'ек разных версий в Линуксе, но в реестре симлинки делаются только на папки, не на значения

Arioch3) разрядность

а точнее даже архитектуру - x86, AMD64, WinRT/ARM, WinCE/ARM, etc

kdvAriochМожно/нужно ли уйти от DLL Hell через прописывание разных клиентских библиотек в реестре.
ни fbclient.dll ни gds32.dll в реестре не прописываются . А "уйти от dll hell" можно только одним способом - размещая библиотеку рядом с exe.

тогда на хрена этот пункт вообще был в опроснике инсталлятора, если его реализация в принципе невозможна ?

kdv ни fbclient.dll ни gds32.dll

ну и до кучи, ты уже второй раз забываешь про третье имя - fbEmbed

kdvразмещая библиотеку рядом с exe.
...а заодно ICU, MSG и все что ещё может понадобиться

DBConstructor



в плане готовых бинарников - там и сейчас так.

но вот информации о клиенте для аппликух не публикуется

и по умолчанию установка клиента в system32 тоже не делается