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

[Gerard Juyn]

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

Yes, but that's still a design-problem IMHO. Not caused by the runtime 
themselves. The caller of alloc() should always be the one to call free(). 
There's no need for deferring ownership under normal circumstances. And 
passing file-handles to a DLL? Honostly, what's that got to do with 
compression / decompression??? I know, zlib was designed that way for 
ease of use, but such things really don't belong in a DLL...
 
> 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.

Which is what causes stack-misalignment and gives the "spectacular" 
crashes.
 
> 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.

The diagnostic tool is not to prevent the problem. The problem will arise from 
people not using the standardly available DLL and building one themselves. 
But the tool can be used to diagnose the problem.
 
> However, it is possible to show the convention in the already-existing
> zlibCompileFlags().

That's useful. And any program that requires a standard zlib1.dll can then 
also use this to test at startup, and possibly give the user an option to fix the 
problem beforehand, instead of crashing somewhere in the midst of an 
important procedure.

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

Are those executables always part of the source download? If not, you get 
the same problem, with someone building everything from altered soruces. 
The examples will work but the DLL has wrong calling-convention.
IMHO stick that DLL with the source download, it's not a extremely big thing 
now is it? And then, who'd need to rebuild it....

Gerard

(ps. off on holidays until 24th)