[Zlib-devel] zlib 1.2.4 released!

[Török Edwin]

On 03/17/2010 06:18 PM, John Bowler wrote:
> It's *ok* to mix CRT (C RunTime) implementations within an app.  The quoted MSDN article says as much when it lists the conditions under which it will fail (emphasis added):
> 
> "If you design your DLL so that it ***passes CRT objects across the boundary*** or allocates memory and expects it to be freed outside the DLL, you restrict the DLL users to use the same copy of the CRT library as the DLL. The DLL and its users use the same copy of the CRT library only if both are linked with the same version of the CRT DLL."
> 
> Zlib does *not* do this, so it's ok.


gzdopen() gets a file descriptor that was opened in the app.

>  Libpng (as a counter example) *does* do this (app allocates (FILE), libpng uses it), so it is not ok.  It's an option to a libpng build (PNG_NO_STDIO) to remove the problem API.
> 
> Notice this only applies to Windows, UNIX CRT (libc) implementations have always been such that two different ones can't exist in the same process (because they take ownership of objects/values in the U-area).  Conclusions drawn from Unix style libcs do not apply to Windows.
> 
> What I'm saying, though, is that zlib1 was released with a link to a particular CRT (MSVCRT) and it should not change that link. 

I was suggesting there should be more versions of zlib DLL, just how
there are multiple versions of pthreads DLL (4 I think).

Best regards,
--Edwin