> OPENSSL_Applink can be implemented only in main EXE module. Yes. Keep in mind that purpose of applink is to facilitate port of Unix and elder Win32 applications, when working around the Win32-specific run-time environment problems is like "hell, it was working for *years*." But for new and evolving code [I suppose JNI would be rather new and evolving] applink should not be preferable option, as there is a way around it, namely avoid passing FILE* to BIO, but instead let BIO open files for you, i.e. avoid BIO_new_fp and stick to BIO_new_filename. Note that applink is engaged purely on demand and it doesn't have to be present in application if application doesn't pass FILE* to BIO.
> There is no possibility, to implement it in my DLL, because openssl finds > OPENSSL_Applink only in main module â GetModuleHandle(NULL). No, because formally speaking it's error-prone, as openssl DLL can't be 100% sure that DLL implementing applink method is not unloaded by the time it's actually needed. One can argue that openssl DLL could increase the reference counter of the module in question to prevent unload, but then it might appear as unexpected to the code trying to unload the DLL implementing the applink method. GetModuleHandle(NULL) on the contrary is guaranteed to be around per definition of a process. > When using Java JNI, I am not able to implement OPENSSL_Applink in main > module, because it is java.exe. > > > > One possible solution is to transform OPENSSL_Uplink function in > openssl-0.9.8a\ms\uplink.c to pass also module name parameter. Even though it's even possible to implement general purpose routine, which would *enumerate* currently mapped DLLs and *locate* OPENSSL_Applink method among then, it's really more appropriate to modify JNI code as mentioned above and simply elimintate need for applink. A. ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
