Hello Andy,
Thank you very much for answering
Andy Polyakov a écrit :
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.
What is the obscure reason of this access violation ?
The OPENSSL_applink function is searched only in the application module,
Which is why it's called *app*link.
so it's necessary to add or include the snippet with any application
that use OpensSSL.
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.
I find that this API is clean and coherent.
Only Windows sucks. Why BIO should suffer of this ?
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.
In the case of a unique DLL that use OpenSSL, what do think about the
following way to define and use OPENSSL_applink
(I've tried this with success with 0.9.8.n but implement it in a
brute force manner) :
ms/uplink.h
Added the following declaration next to extern void
*OPENSSL_UplinkTable[]; :
extern void OPENSSL_SetApplink( void** (*foo)() );
ms/uplink.c
Added :
static void** (*applink_foo)() = NULL;
void OPENSSL_SetApplink( void** (*foo)() )
{
applink_foo = foo;
}
and modifiy OPENSSL_Uplink(). Priority is given to OPENSSL_Applink if
it's found in the current module. If it's not, if applink_foo is not
set, give the error message else use applink_foo.
applink=(void**(*)())GetProcAddress(h,"OPENSSL_Applink");
if (applink==NULL)
{ if( applink_foo == NULL )
{ apphandle=(HMODULE)-1;
_tcscpy (msg+len,_T("no OPENSSL_Applink"));
break;
}
else applink = applink_foo;
}
In the user DLL that uses OpenSSL, add or include the snippet
applink.c in the DLL project and
Add the following declaration (I don't know where to put it in
OpenSSL include files)
extern "C" {
void **OPENSSL_Applink();
void OPENSSL_SetApplink( void **(*foo)() );
};
and add the following in the initialisation function or dllmain:
CRYPTO_malloc_init();
OPENSSL_SetApplink( OPENSSL_Applink );
SSL_library_init(); /* load encryption & hash algorithms for SSL
*/ SSL_load_error_strings(); /* load the
error strings for good
error reporting */
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. I've
found impratical to add appilink.c in each application that uses the DLL.
I want to point to your attention that the call ERR_print_errors_fp(
stderr ) from the user DLL lead to an Access violation (0xc0000005).
This situation arises in mixing debug and release versions and
is probably due to the fact that ERR_print_errors_fp( stderr ) calls
fwrite directly. UP_fwrite should be used instead.
This is bug. It was fixed in development branch and is not present in
1.0.0. http://cvs.openssl.org/chngview?cn=19607 is committed even to
0.9.8. A.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [email protected]
Automated List Manager [email protected]
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [email protected]
Automated List Manager [email protected]
