> An easy way to figure out where the dependencies lie are to compare the > data structure > definitions in the CRT headers.
As was pointed out earlier, data structure definitions are apparently not the only concern:-( > If there are #ifdef's in the data > structure definition > then you know there is a guarranteed compatibility issue. In MSVCRT case structures are all the same in all combinations of MT and debug and it's multiple copies of global structures (in stdio case it's most notably __iob and __pioinfo arrays) which cause the trouble. For the reference, source code for MSVCRT is available in Microsoft Platform SDK under src/crt. As for "with the BIO code I am not sure this is a possibility." Note that once compiled and linked with MSVCRT, BIO would actually work fine with any run-time environment, because it never exposes FILE * to the application and sticks to private __iob, private to OpenSLL .DLL, in cases when application uses incompatible stdio. The real problem is "grep 'FILE \*' include/openssl/*". Bottom line. In order to make OpenSSL independent from Windows compiler run-time, it's appears to be necessary to [at least!] eliminate FILE * references from exposed API. > We have the following variables which we want to express in the name of > the dll: > > 1. run-time library [compiler x threading x debugging] > > Compilers: > msvc 6.0 > msvs .net > msvs .net 2003 > others? Given the variety of run-times getting rid of FILE * in API might appear as viable alternative, huh? Unless of course Microsoft and few others (e.g. Borland?) can *guarantee* internal consistency over different releases. > Threading; > linked to threaded run-time > linked to non-threaded run-time I see no need for having non-threaded version (as there is no MT MSVCRT). MT build should siffice for all purposes. > Debugging: > linked to debugging run-time > linked to non-threaded run-time For the sole reason to provide for common copy of global run-time variables (as mentioned above). This is *very* unfortunate sutiation in my personal opinion. > 2. 32-bit vs 64-bit Is normally solved through search pathes. At least when it comes to installing a .DLL next to other system DLLs, you *have to* put 32- and 64-bit ones to *different* catalogs. A. ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
