> But note that there *are* system DLL which are linked with
> MSVCRT.DLL. E.g. CRYPT32.DLL imports string functions and malloc/free,
> while WS32_32.DLL imports fopen, fclose, fgets and some string
> functions...
Consider following dll.c snippet:
#include <stdio.h>
#ifdef ME_DLL
__declspec(dllexport)
foo() { printf ("%p\n",stdin); }
#else
main () { foo (); printf ("%p\n",stdin); }
#endif
Compile it as 'cl -DME_DLL dll.c /LD; cl dll.c dll.lib' [or in other
words link statically with LIBC] and run dll.exe... I get "10008038
00407038" meaning that dll.dll and dll.exe get *separate* copies of
__iob table!? Now compile as 'cl -DME_DLL dll.c /LD /MD; cl dll.c
dll.lib' [or in other words dll.dll is linked dynamically with
MSVCRT]... I now get "7803A690 00407038." Compile as 'cl -DME_DLL dll.c
/LD /MD; cl dll.c dll.lib /MD'... Finally(!) I get "7803A690 7803A690."
But compile as 'cl -DME_DLL dll.c /LD /MD; cl dll.c dll.lib /MDd'
[dll.dll is linked dynamically with MSVCRT.DLL and dll.exe - with
MSVCRTd.DLL]... I get "7803A690 10261828." That must be it! The reason
why it's impossible to interchange debug and non-debug versions.
> How does it work there?
I suppose it works as long as no FILE pointer fopened in one module
(e.g. dll.exe in the above example) is passed down to another module
(dll.dll in the above example). Well, most things would probably work
fine (provided that structure layout is the same), but other things,
like fclose, fileno, fdopen might fail just miserably. If malloc/free
relies on some global variable (there is some kind of lock as far as I
can see), then free-ing a chunk allocated in another module can produce
unpredicted result too. 'dumpbin /imports libeay32.dll' also shows that
it imports _write,_read and _close, but not _open. File descriptor in
MSVCRT is an index in __iob table... What a mess... A.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
