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

[Cosmin Truta]

On Fri, 1 Aug 2003, Gerard Juyn wrote:

> > It does require and it does use the Borland static C runtime library.
> > It's not a dynamically-linked runtime library, but it is, well, a
> > runtime library. It will cause problems just like the others.
>
> But it shouldn't matter what runtime library is used internally,
> unless... and now I think I begin to understand the big problem... the
> zlib API uses C runtime types as paramaters in the exported functions.
> That's another unfortunate historic design 'feature'.

It's even simpler than that. Having two different C run-time libraries,
either static (LIBC.LIB, LIBCMT.LIB in MSC; CW32.LIB in Borland C) or
dynamic (MSVCRT.DLL, etc.), one in the user's DLL, the other in the
user's EXE, poses problems, period.

  http://support.microsoft.com/?id=94248

It doesn't necessarily have to deal with run-time *types*. It's enough
to trigger incompatibilities by calling malloc() that belongs to one
runtime, and then by calling free() that belongs to the other runtime;
or by passing buffered files along I/O functions in both runtimes.


> Is there a good way to detemine what calling convention a DLL is built
> with?  The problem is stack-corruption when intermixing STDCALL with
> CDECL, but only on the parameters, right?

The order of parameters in STDCALL and CDECL is the same (it's reversed
in PASCAL), but the difference consists in who cleans up the stack.

> So a global function with no paramters that returns a code for the
> used calling convention inside the DLL could be called independantly
> of what calling-conventions are used in the app or DLL.

That is correct, although I would prefer to have the convention properly
established, given in the zlib.h header. Relying on users running a
diagnostic tool, or otherwise calling this function, is no safer than
relying on users tweaking flags in the zlib header.

However, it is possible to show the convention in the already-existing
zlibCompileFlags().

Or better yet, distributing the standard zlib testing programs,
EXAMPLE.EXE and MINIGZIP.EXE, linked to the DLL and seeing them working,
is both simple and reliable. This way, anyone who rebuilds the DLL must
test it with these programs. If any of these programs don't work, it
means the custom-built DLL is incorrect.


Cosmin