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

[Cosmin Truta]

On Mon, 28 Jul 2003, John Bowler wrote:

> >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.

I don't know how numerous they are, but zlib is designed to work on
other languages, too.

> 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.

Hmm... that seems a little gross. How would you do it without making a
mess in the zlib sources? (The solution you're proposing seems a mess to
me.) Imagine how much would the quality of zlib have to suffer
(simplicity, readability, maintainability, you name it), not to mention
bugs introduced by the errors inherent in this process!

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?)

What's wrong with introducing yet another DLL-for-VB into the runtime
bloat required for a minimal VB program? How big can this problem be,
compared to a whopping clutter over the zlib sources?

Why simplify the binary at the big expense of the source, instead of
keeping the binary simple at the small expense of the binary?
(You probably noticed that I consider an extra DLL a small expense ;)


> 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...

The errors that I personally see are the following:

- K&R (the authors) did not believe in type checking, and K&R C (the
  language) suffered from some diseases that are still inherited by
  ANSI C. Originally, you didn't know at compile time how many arguments
  did the calling functions have
  (you probably know about "int foo()" vs. "int foo(void)")
  so (1) you needed lint; (2) you needed the less performant but the
  more flexible CDECL calling convention; (3), (4), (5), ...

- VB programs could not use external, undecorated functions written
  in pure, standard C (this is yet another way to say that VB didn't
  work with CDECL). Or perhaps it was a decision intended to coerce
  people into using the M$ junk...

Just kidding ;)
Cosmin