[Zlib-devel] zlib 1.2.4 released!

[John Bowler]

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.  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.  If it doesn't change it a *user* upgrade of zlib1 doesn't change the libraries in the running app.  If it does change a *user* upgrade won't stop the app working, but it will result in an app with two CRTs where before there was only one.

John Bowler <jbowler at acm.org>