You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.
This is a Windows specific proposal, with three items. The first is
independent, the second depends one the first and the third depends one
the first and the second.
1) If I use an UDF DLL that depends one others DLLs, I current can't put
all DLLs in <root>\udf. I need to put the dependencies in <root>\bin or
in some other place in %PATH%.
I propose we change ModuleLoader to load with LoadLibraryEx(...,
LOAD_WITH_ALTERED_SEARCH_PATH), so the dependencies are searched in the
same directory as the library being loaded.
2) Above change makes it possible to the application developer load
fbembed.dll with altered search path too. But our rules to determine
<root> is based on the application EXE directory.
I propose we change the root determination of the embedded engine to be
path of fbembed.dll. This is a change compatible with the current
documented way to use embedded, where fbembed.dll and the application
EXE should be in the same directory.
Currently fbserver is unable to load own ib_udf.dll as it depends on ib_util.dll which placed in \bin folder while ib_udf.dll is in \udf ;)
I offer or put ib_util.dll in \udf or, better as for me, add \bin folder into altered search paths too.
I've a complains from users that FreeAdhocUDF is not worked when Firebird works as a service.
FreeAdhocUDF is dependent on fbclient.dll and on ib_util.dll. The second one is always loaded by the Firebird itself but fbclient.dll is not loaded.
And usage of LOAD_WITH_ALTERED_SEARCH_PATH prevents Windows from looking into application folder (firebird\bin) when dll (fbclient) is loaded.
Adding SetCurrentDirectory into WinMain fixed the issue.