> 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.
Here is alternative suggestion I've been pondering over.
What is this thread about? About making it possible to provide binary
toolkit distribution, which preferably can be used with a number of
compiler environments(*): Visual C, .NET, Borland, MinGW(?), Digital
Mars(?). If we manage to achieve the goal of building *unified* binary
distribution with a single compiler, there hardly is a reason for making
it work with every particular compiler.
(*) I leave DJGCC out because it doesn't support dynamic linking, and
Cygwin - because it's rather thick POSIX API emulation layer, thick
enough to deserve separate "namespace."
Now let's imagine we pick Microsoft compiler. I'd suggest to perform an
MT build and link it dynamically with MSVCRT.DLL. Idea is to use MSVCRT
primarily for BIO and other strictly internal purposes (keep in mind
that MSCVRT.DLL can be redistributed). At the same time I'd sanitize
functions appearing in "grep 'FILE \*' include/openssl/*" and replace
calls to stdio with wrappers, which would treat FILE * as opaque
pointer. Idea is to link these wrappers to corresponding stdio functions
provided by compiler environment at run-time. How? We could require user
application to be linked with a module of own design, which exports a
symbol, and then we could refer to this symbol from DllMain in
libeay32.dll for the purposes of linking the wrappers with vendor stdio.
For example. Supplied code to be compiled and linked with user
application could look as following (this is just an example!):
static void *link_table[]={stdin,stout,stderr,fprintf,fread,fclose};
void ** __declspec(dllexport) get_link_table() { return link_table; }
While DllMain in libeay32.dll could:
h=GetModuleHandle(NULL);//.exe image used to create the calling process
proc=GetProcAddress(h,"get_link_table");
if (proc==NULL) report_or_log_error_and_exit();
tbl=(*proc)(); // use tbl to feed the wrappers
It should be enough to simply add the supplied module to the target
project to make magic happen and work with any run-time environment or
flag combination. There is a minor problem with Borland, which insists
on different function name decoration and uses different .LIB format,
but it seems that it can be easily resolved with IMPLIB... Thoughts? A.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
