[Zlib-devel] RE: [png-implement] Binary-incompatible change in the DLL interface of zlib

[John Bowler]

The calling convention is frozen in when the library itself, or the DLL, is
built.  Therefore the header file distributed with the built library or
built DLL (well, the stub .lib for the DLL) should say exactly what that
calling convention was.

It doesn't make sense for someone building against an *already built* zlib
to be able to change the meaning of the function definitions within the
header file by changing the macros on the compiler command line or in the
*calling* source code.

The actual function definitions within zlib.h should include __stdcall,
__cdecl or __fastcall as appropriate.  Then it doesn't matter what options
are used either in the original zlib build (static library or DLL) or the
calling app/lib build - the public zlib functions will always have the same
calling convention.

The main problem seems to be that ZLIB_DLL causes a big switch to flip
within the zconf.h header file on Windows (only) between WINAPI/WINAPIV
(macros which define, in addition to other things, the calling convention)
and *nothing* (no specification of calling convention.)  But I don't see
that changing the *static* library from implicit __cdecl to explicit
__stdcall would break anything.  The explicit definition will ensure that
calling code is correct when recompiled.

John Bowler