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

[Cosmin Truta]

On Sun, 3 Aug 2003, Gerard Juyn wrote:

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

You are right, it's just we don't have a way to ensure this except by
saying "if you use your own alloc, please use your own free".

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

That could happen if a gzip stream is part of a more complex file
structure.  The gzip stream is processed inside the dll, the rest of the
structure is processed outside. At least we know that won't affect PNG
and MNG.

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

Good point.

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

Also a good point. Hopefully, zlibCompileFlags() will offer this
diagnostic by the time of the zlib release.


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

Yes, even though if the convention is altered, so will be the builds of
EXAMPLE.EXE and MINIGZIP.EXE, and the problem won't be detected. But we
could offer these executables at the same location where ZLIB1.DLL will
be available. We can say "if you really want to build your own DLL, make
sure it will work with *these* executables".

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

Ideally, yes. But we have no way to prevent the people to do it.

> (ps. off on holidays until 24th)

Have a nice vacation!
Cosmin