Hello,
I posted a message in the sunforum.sun.com and I thought that I might
get some reply if I also post it here:
nsldap32v50.dll only works if client process (*.EXE file) statically
links to nslad32v50.lib. If you write your own DLL that statically
links to nslad32v50.lib, this DLL will crash when it calls
ldap_simple_bind_s(), unless the host process also links to the LIB
file. Of course, if you don't own the .EXE file for the host process
(like MS IIS's dllhost.exe or inetinfo.exe), you're out of luck. Is
there a fix to this that I should download? I assume nsldap32v50 is
the latest version (nsldap32v50.dll doesn't have a version resource so
I assume there is only one release for ver 5.0)
Theoretically, this test program should work but it doesn't:
<pre>
// main.cpp, simple test program
#include <windows.h>
int main()
{
typedef int(__stdcall *ldap_init)(char*, int);
typedef int(__stdcall *ldap_bind_s)(int, char*, char*, int);
HMODULE mod1 = LoadLibrary("nsldap32v50.dll");
ldap_init func_ldap_init = (ldap_init)GetProcAddress(mod1,
"ldap_init");
ldap_bind_s func_ldap_bind_s = (ldap_bind_s)GetProcAddress(mod1,
"ldap_bind_s");
int h = func_ldap_init("devsun6", 389);
int ret = func_ldap_bind_s(h, "cn=user,ou=userfil3,o=company", "",
128);
return 0;
}
</pre>
-posted by Marlon Baculio on 1/22/2002
--------------------------------------------------------------------------------
Someone@SunForum on 1/22/2002 answered:
I recently had this come up, and my solution was to put the LDAP-using
code in the EXE, and then export an interface pointer (not a true COM
interface, mind you) to the DLL, which could then call functions on
the interface pointer, using the EXE to do the dirty work of
communicating with the LDAP DLL.
Recently, I found the following in (boo, hiss!) MSDN:
If a DLL declares any nonlocal data or object as __declspec( thread ),
it can cause a protection fault if dynamically loaded. After the DLL
is loaded with LoadLibrary, it causes system failure whenever the code
references the nonlocal __declspec( thread ) data. Because the global
variable space for a thread is allocated at run time, the size of this
space is based on a calculation of the requirements of the application
plus the requirements of all of the DLLs that are statically linked.
When you use LoadLibrary, there is no way to extend this space to
allow for the thread local variables declared with __declspec( thread
). Use the TLS APIs, such as TlsAlloc, in your DLL to allocate TLS if
the DLL might be loaded with LoadLibrary.
While I haven't exhaustively hacked the DLL apart to see if this is in
fact what's occurring, none of the evidence I have so far suggests
some other alternative.
By the way, ldap_set_option() works (for setting the LDAP version to
3, for example), but other functions, such as ldap_search_ext_s(),
also fail, so even skipping ldap_bind_s() does not allow the DLL to be
used."
1 out of 1 users found this answer helpful
Is this a good answer to the original question?
--------------------------------------------------------------------------------
Marlon Baculio on 1/23/2002 commented:
Thanks Someone@SunForum! I appreciate your response and it's very
informative. I hope developers working on nsldap32 could see your
suspicion on __declspec(thread) and try it. As for my case, I don't
have any workaround since I don't have control of the EXE build. We
are running under Microsoft's Internet Information Service which is
either mtx.exe, dllhost.exe or inetinfo.exe."
--------------------------------------------------------------------------------
Marlon Baculio on 1/23/2002 commented:
Someone@SunForum could be right with his static TLS theory. I dump
nsldap32v50.dll header using Dumpbin.exe, and it has a non-zero TLS:
2000 .data
4000 .rdata
1000 .reloc
1B000 .text
1000 .tls
--------------------------------------------------------------------------------
