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

[John Bowler]

Yes, my solution was more than a little gross.  It doesn't change the Zlib
sources but it requires a massively hacked Windows build with extra wrapper
functions and #defines to change the names of the functions in the main
source.

Cosmin Truta:
>I am still trying to understand: why __stdcall all the way? Is there a
>reason besides VB? (Which, by the way, does not demand it anymore in the
>newer versions?)

This problem comes from the failure of the designers of the processor
(Intel) to define a procedure call standard.  The proliferation of compilers
and operating systems running on the processor produced different
approaches.

__stdcall is, I believe, the Pascal calling convention.  Arguments are
pushed in the order they occur in the source, therefore the last is at the
top of the stack.  It's the natural way to do it but it doesn't work with C.
Why would the author of a Pascal compiler care about this, everyone should
be writing in Pascal...

The primary advantage of using __stdcall now that it is possible with ANSI-C
is that the functions are *natively* callable from other languages.
__stdcall C just looks like a Modula-3, or Pascal, or whatever function.
Otherwise either a specific *non-standard* declaration is required or a
wrapper function (as in the VB case.)

That said, it doesn't matter very much - just so long as the C header file
*always* decorates the function declarations with the procedure call
standard!  Even a mixed __cdecl for static lib and __stdcall for DLL would
work fine - the (C) application writers would just have to remember to
define ZLIB_DLL or not according to what they linked with.  The error
happens at build (link) time and is an obvious set of missing symbols.

John Bowler