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

[Gerard Juyn]

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

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. It seems to have worked, but I can't boast the popularity 
of zlib or libpng of course.
 
> > 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.

I'd wait for libpng-2 or later where that problem was removed. Of course it 
might be a lot easier to add libpng-like functions to the libmng code.

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 diagnosis tool, that 
checks installed DLLs it recognizes. It scans the system-libraries and library-
path. It can even do a complete scan of all drives (including network drives). 
This is how I found my share of various zlib.dll's:

http://libmng.sf.net/windows32.html

Currently it scans for libmng*.dll, libpng*.dll, lcms.dll and zlib.dll files. It tests 
only the libmng.dll in the system searchpath.

Gerard