Re: Problem with image libraries on Windows (reprise)

[David Hunter]

Juanma Barranquero wrote:
> Cause:
>   Documentation for the JPEG library states: " Microsoft C cannot pass
> file pointers between applications and DLLs. (See Microsoft Knowledge
> Base, PSS ID Number Q50336.) " I've been unable to find article
> Q50336, probably because it is very old, but the description of the
> problem seems to fit what I find. Moreover, tracing calls all the way
> through NTDLL shows that the Windows library is receiving an non-valid
> FILE * (but the image DLLs are receiving a valid one, so it is not a
> problem in Emacs).

I don't know about that particular KB article, but the issue still applies to 
recent MS Visual C runtimes (CRT).  In short, FILE pointers are valid only 
within the instance of the CRT library that created them.  As long as your 
application and all dependent libraries dynamically link to the CRT 
(MSVCRT.DLL), then all application and library code can share FILE pointers.  
However, if an application or library (module) statically links to a CRT 
(LIBC[MT].LIB), then that module must keep its FILE pointers to itself, as no 
other CRT library (static or dynamic) will be able to use them.

This issue is not limited to FILE pointers, but also extends to include most 
CRT resources, including memory (malloc/free).  You must not call one CRT's 
malloc and pass the block to another CRT's free; it won't work.

I believe this sharing issue is also encountered if you attempt to share FILE 
pointers between the retail (MSVCRT.DLL) and debug (MSVCRTD.DLL) libraries.

Additionally, due to the release of Visual C++ .NET, there is a whole new set 
of .NET CRT libraries (e.g., MSVCR71.DLL).  The dynamic CRT library used by a 
given module depends on the version of C++ used to build it.  It is possible to 
have linked all modules to a dynamic CRT, and still the process may end up 
loading both old and .NET CRTs to satisfy modules built on different C++ 
versions.  I have no firsthand knowledge with sharing FILE pointers between the 
old CRTs and these new .NET CRTs, but I think Microsoft does say this is bad:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vclib/html/_crt_c_run.2d.time_libraries.asp

The compiler flags that control CRT linking are given in the above article.

The moral of this story:  Encapsulate, obfuscate, and hide CRT resources.

-Dave