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

[Cosmin Truta]

On Thu, 31 Jul 2003, Gerard Juyn wrote:

> > I am not very fond of MSVCRT.DLL myself. I don't consider it "the good
> > solution", I only consider it "the least bad solution".
> >
> > > Why not compile without this dependancy? If MSVC or MingW can't do it,
> > > use another tool.
> >
> > I'm not sure what you mean. I have to link the DLL to some C runtime,
> > right? Then, which one should it be? Whatever that is, it will clash
> > with something else.
> >
> > What is, in your opinion, the best answer to question 8?
>
> I build libmng.dll with Borland C++, which does *not* require any runtime
> library. Any C-routines required are simply enclosed in the binary. This may
> make some binaries a bit larger than they could be, but it removes any
> dependancy on a (not so stable) runtime library.

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.

Gilles Vollant gave me an additional tip:
http://support.microsoft.com/?id=94248

The problems listed there should not avoid a DLL built by linking it to
the Borland static library. Until someone finds a more concrete article
about the compatibility between the MS and Borland runtimes, I think we
should take the safe approach and say "it's not 100% compatible".


> > I'm afraid that cannot be done. The zlib license does not forbid anyone
> > to make one's own builds and distribute them. What we can do, (and we
> > are doing it), is to give the sources, the .def file and the makefiles,
> > and to say "if you are altering anything, please say clearly it's
> > altered and unofficial." And we make sure that the makefiles will build
> > whatever they are supposed to.
>
> The source and the DLL are two separate things. If you have a separate
> download of the 'standard zlib1.DLL', you just point from every point
> possible in the sources to this download. If people need a DLL they
> should just download it, not re-build it. You can't tell them not to
> rebuild a DLL, but strongly advising against it by giving them a much
> easier option: download it!

Works in theory; let's see if it works in practice.
(so far it didn't work too well. Gilles used to offer ZLIB.DLL, which
was pointed to from the zlib home page).

> I've made it as clear as possible that I strongly discouraged anyone
> from building a libmng.dll other than the one that gets distributed
> with the sources, right from the start.

Let's see what we can do with the "as clear as possible" thing...


> > Gilles Vollant is distributing his minizip DLL, that includes zlib, and
> > that will continue to be built under the stdcall convention for VB.
>
> <shameless plug> libmng.dll does too :) </shameless plug>

Alright then, that's yet another reason NOT to worry about the VB
interfacing with zlib.


> There's already a tool for libmng, which I could extend with your
> zlib1.dll when it is ready. The installer also has a DirectX-like
> [...]
> http://libmng.sf.net/windows32.html

Interesting. I would be glad to benefit from your knowledge, and from
the tools you wrote. Joining the efforts to maintain zlib1.dll and
libmng.dll is something that I'd like to do.

What I can take care of is the consistency in the zlib configuration
headers, and in the makefiles. Gilles insisted that a macro ZLIB_STDCALL
is necessary, and I think he is right - it's just that the macro is not
enabled for a standard DLL build. I will also add ZLIB_FASTCALL, for
easier integration with Delphi.


Cosmin