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

[Cosmin Truta]

On Tue, 29 Jul 2003, Gerard Juyn wrote:

> The only thing I personally find undesirable is having it linked
> against some external runtime library. Again you've got a good case
> there, but I just have a bad feeling about something like that. It's
> not uncommon for MS to modify these in incompatible ways.

So you would like a different answer to the questions 8 and 9. Are you
suggesting the static library? The counter-argument is given at the
beginning of answer 9. That will cause problems to the people who want
to link their apps to MSVCRT.

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?


> *You* (or someone else, but just *1* origin) should be the sole
> distributor of the standard DLL. This is something you should make
> more clear. Really discourage anyone to build their own 'standard'
> version. There should be just *1* source. And then it doesn't matter
> which compiler you use.  That *is* the beaty of DLLs (probably the
> only one :)

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.

"win32/makefile.msc" and "win32/makefile.gcc" are building compatible
DLLs. Both are linking to the same MS runtime, and I tested them working
with each other's apps. So they work, both in theory and in practice.

"win32/makefile.bor" does not build the DLL.


> This way you could also 'expand' the standard DLL with a separate
> STDCALL API specifically for older VB. Eg. add all functions with a
> vb_ prefix or _vb suffix or something and include a VB include file
> that does the magic translation. A single standard DLL with everybody
> happy.... Of course you can also leave that out until someone begs for
> it.

Something similar was proposed by John Bowler, too, but let's think a
little: we have to choose between messing up the binary and messing up
the source. There is no coming back from the binary, while the source is
the real legacy. I'd say let's sacrifice the elegance of the binary for
the benefit of the elegance of the source, and not the other way around.

Gilles Vollant is distributing his minizip DLL, that includes zlib, and
that will continue to be built under the stdcall convention for VB.


> Anyway, the only real advice (that you probably know already) is that
> you do have to work out the best strategy you can think of right now,
> and then stick with it for at least a decade. And make sure there's
> only ONE (1) source of the DLL!!!!

I'll try that by writing motivating arguments. I can never promise I
will be on the zlib-devel and take care of it as much as I should. In
exchange, I wrote and I'll try to maintain the DLL_FAQ. I will gladly
accept suggestions from anyone.

I cannot even promise prompt email replies, as you probably noticed
already.

> I'll follow your progress, and if its satisfactory I may decide to
> link the standard libmng.dll against your standard zlib.dll But again
> unfortunately, anyone using libmng.dll's zlib functions will have
> linked against STDCALL. I'd have to go the same way as you and create
> a libmng2.dll

If your users are not outside C, VB and Delphi, then probably you
shouldn't worry that much about it. On the zlib-devel list, we have an
Ada user, Dmitriy Anisimkov, who insisted that the ability of using zlib
outside of C, without sacrificing portability, is important.

We had the reason to rebuild the dll under a different name ZLIB1.DLL
because of the unreliability of the old ZLIB.DLL, caused by the
possibility of building it in incompatible ways. libmng.dll does not
suffer from this disease, does it?


> We might even consider creating a bundle with zlib, libpng, lcms and
> libmng.  Having a special Windows installer may help to expedite
> acceptance too. Just another idea....

Might be a good idea. There may be still a problem with the stability of
the libpng structure, that may make it difficult to upgrade libpng.dll
and leave everything else in place, but we could try to work it out.


Cosmin