[Zlib-devel] zlib 1.2.0.1 available for testing

[Cosmin Truta]

On Sun, 23 Mar 2003, Gilles Vollant wrote:

> << I also prefer to have libz.a static library with C calling
> convension. >>
> I say only one thing : zlib.dll will always have WINAPI calling
> convention, for not break compatibility.

In my previous email I explained why there is no ZLIB.DLL compatibility
to talk about. And in my first email on this issue I explained why there
will _never_ be a _compatible_ ZLIB.DLL: you will have to have one for
static-singlethreaded, one for static-multithreaded, and one to link
with MSVCRT.DLL. All of these are mutually incompatible. And I didn't
mention the non-Microsoft Win32 platforms...

And worse yet, Visual Studio.NET applications are now using a new
MSVCRT70.DLL, and I wouldn't be surprised if it would require yet
another build of ZLIB.DLL, incompatible to the others.


> We can remove the ZLIB_DLL by defaut. Of course, I'll have to had it has
> preprocessor define in Visual C++ zlib.dll project, but this is
> possible.

That's not enough. What Dmitriy wanted to say is that if some sources
files compile and link to the static zlib, you cannot recompile and
relink them to ZLIB.DLL, nor the other way around. You have to add or
remove the WINAPI attribute to the user callbacks in the source files.

Breaking binary compatibility is not an easy thing to do (it is
incommode for users), but breaking source compatibility is even worse
(mandatory source modifications are not only inconvenient, but also
dangerous).


Cosmin