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

[John Bowler]

Cosmin Truta:
>John Bowler:
>>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.
>
>It wouldn't break anything in C or C++, but it will cause problems in
>other programming languages that interface with zlib via C bindings.

Ah, so there are numerous *other* header files, written in other languages,
which describe the Zlib interface on Windows and which define the interface
functions, explicitly or implicitly to be __cdecl.  Changing these header
files/.DEF modules etc is an intractable problem.

One way round this is to produce a static lib (and, if necessary, a DLL
wrapper) which has both the __cdecl and __stdcall APIs exported, make the
__cdecl a dummy call into __stdcall (reversing all the arguments on the way
of course...)  Change the other languages to __stdcall over time.

The simple way to get both APIs in a static library, say for a function foo
is:

cc -Dfoo=real_implementation_of_foo foo.c
cc stdcall_foo.c cdecl_foo.c

stdcall_foo.c:
int __stdcall foo(int arg) { return real_implementation_of_foo(arg); }

cdecl_foo.c:
int __cdecl foo(int arg) { return real_implementation_of_foo(arg); }

Hacking "ZEXPORT deflate" (etc) into "ZEXPORT(deflate)" actually makes this
slightly easier, but it's still fairly gross.  It just seems like a pity to
have a design decision forced by proliferation of an old error...

John Bowler