>>> If I have correctly understood the FAQ about the OPENSSL_applink. It >>> applies only in the Win32 version: >>> >>> * If OPENSSL_USE_APPLINK is not defined at the compilation stage of >>> OpenSSL, the snippet applink.c is not mandatory BUT I have to >>> build a debug and a release version of OpenSSL DLLs. >>> I don't know why but it seems to be related with FILE functions. >>> * If OPENSSL_USE_APPLINK is defined, the snippet applink.c is >>> mandatory in an application and the release version of OpenSSL >>> DLLs can be used in any case. >> >> Well, OPENSSL_USE_APPLINK is always defined in Win32 builds. applink.c >> is required if a) application uses certain subset of OpenSSL API and >> b) application and DLL are compiled with different flags, debug vs. >> non-debug, or different compilers. > I compile OpenSSL with Visual C++ 6, the same with which I build my DLL > and applications. > I've already used debug vs. non-debug, for example zlib.dll, I've never > had problems.
Because zlib.dll does not accept any FILE * arguments. > What is the obscure reason of this access violation ? Every MSVCRT dll has own copy of FILE structures and passing pointers to them between dlls is not safe. Nor is it safe to pass descriptors returned by open between those dlls. Nor is it safe to let one dll to free memory malloc-ed by another dll. "Every MSVCRT dll" refers to different versions, debug vs. non-debug version, etc. >> It should be noted that applink was introduced primarily in order to >> facilitate migration for legacy applications. New code should rather >> abstain from using above mentioned subset of OpenSSL API (whatever >> using FILE *) and simply avoid applink. > Do you mean that BIO API using FILE* is deprecated ? I have not seen > this mention in the documentation. Well, not really. But if you want to ensure least head-ache in cross-platform development you better avoid FILE* API. It's just state of affairs. Basically I mean life is a bitch and it's not going to change:-) > I find that this API is clean and coherent. > Only Windows sucks. There you go. It sucks, but it doesn't mean that you as cross-platform application developer can dismiss it. You have to use it no matter how much does it suck. Same applies other way. It doesn't matter how much you appreciate some API, you might find yourself in situation when you have to not use it. > Why BIO should suffer of this ? Because it just does. > If the only way to have a DLL that uses OpenSSL as a wrapper is to > compile OpenSSL without OPENSSL_USE_APPLINK define and provide a debug > and a release version... no problem... I will do so. If executable modules, be it .exe or .dll, passing FILE* and malloc-ed pointers between them are compiled with same compiler and compiler flags as OpenSSL, applink won't be engaged. It doesn't matter it you compile OpenSSL without OPENSSL_USE_APPLINK defined. I mean if you do, you would absolutely have to compile with same compiler and flags. And when you do that, applink would have kept itself out of your way anyway. >>> This way, OPENSSL_Applink can be used inside DLLs, but I'm not sure >>> of implications so I need your advices. >> >> As there is no way to ensure/know that there is only one DLL using >> OpenSSL, it's not appropriate for main stream. If it helps to develop >> and debug your application, there is nothing that prevents you from >> doing so. >> > Of course ! but I don't especially want to do so ! > This is the only way I' ve found to build a DLL using OpenSSL. Depending on your situation you might find it appropriate to embed OpenSSL into your dll. I.e. as opposite to having "your" dll and "openssl" dll, you can have one dll with openssl in it. And as the other subscriber pointed out, custom BIO would do the trick too. > I've > found impratical to add appilink.c in each application that uses the DLL. Nobody said that you will like the advice:-) Cheers. A. ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
