Re: Problem with image libraries on Windows (reprise)

[Juanma Barranquero <lekktu@gmail.com>]

On 6/16/05, David Hunter <hunterd42@comcast.net> wrote:

> 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.

Very, very interesting:

  1) MinGW-built Emacs: depends on MSVCRT.DLL
  2) MSVC-built Emacs: doesn't depend on MSVCR*.DLL (it's linked with LIBC.LIB)
  3) Binary tarballs of GnuWin32 image libraries (MinGW): depend on MSVCRT.DLL
  4) My MSVC-built image libraries (.NET 2003): depend on MSVCR71.DLL

So 1) is compatible with 3) and would break with 4). OTOH, 2) should
break with 3) and 4). And that's *exactly* what I'm seeing. Thanks!

> 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.

Fortunately this is not happening. The image libraries do their own
memory handling.

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

Yeah.

In this case, the moral is: on Windows builds, we *cannot* rely on
passing FILE * to any image library (or any other library whatsoever)
because we cannot guarantee the libraries will use the same CRT. So we
have to go the alternate datasource route (that's what my patches
implement).

Thanks for a illuminating and very informative posting.

-- 
                    /L/e/k/t/u