[Zlib-devel] Updates to zlib 1.2.0.3 - pick one

[Cosmin Truta]

On Mon, 28 Jul 2003, Gilles Vollant wrote:

> I tested the Cosmin work.
> For me zlib-1.2.0.f-cos0 is good, zlib-1.2.0.f-cos1 break my project.

Really? It shouldn't, unless you are building the dll using the same old
name ZLIB.DLL. If you are using any new name for the DLL, it means you
are recompiling your old apps - and they should run fine with the new
DLL. Also, the old ones should run unaffected, because the new DLL does
not interfere with the old ZLIB.DLL in any way.

I tested minizip myself, and everything was fine.

> For compatibility, I'll continue build a DLL that use WINAPI/STDCALL
> and zip function. If noone never made a DLL with WINAPI/STDCALL,
> Visual Basic (by example) user will never be able use zlib

Visual Basic is the *only* that is not able to use CDECL.
But it is possible to build a separate Visual Basic project, just
like the "contrib/delphi/" and "contrib/delphi2/" projects.
Or like your project.


> <<
> - The DEF file used to build ZLIB.DLL includes unofficial exports.
>   You can either fix the DEF file, or use a name different than
>   "ZLIB.DLL" or "ZLIB1.DLL" for the compiled DLL.
> >>
> I'll not modify the .def.

That's ok - but then don't release the DLL under an official name.

> If you think this is a big help, I can rename my DLL as zlibwapi.dll (by
> example), to avoid confusion, by modifing contrib\vstudio\vc70_32\*.vcproj
> and contrib\testzlib\*.vcproj

There is always a problem when someone adds private functions to a
binary component that has a public name. Users might write apps that
depend on those functions, and their apps will break as soon as the
installation will use a component with the same name, but without the
private functions.

For example, Microsoft provides the source code for MSVCRT and MFC, and
Borland provides the source code for VCL and CLX. But the end-user
license agreements that come with the source code, demand the user to
use a different name for the compiled DLL, if the user makes any single
modification to the source code.

If that DLL offers minizip functionality, why not define it
"minizip.dll"? :)


> If one of my user want full compatibility, he will renance this dll as
> zlib.dll, but we don't contribute to confusion.

It depends on what you mean by "full compatibility".

"Official compatibility" usually means "compatibility with the build
that comes from the official sources and makefiles". And in the case of
zlib, "official compatibility" is achieved by .... zlib-1.2.0.f-cos1 !!!
That's because, in zlib-1.1.4 and earlier, the makefile (which is
"nt/Makefile.nt" was building the DLL without ZLIB_DLL enabled).

BUT

If the DLL is renamed, there is no binary compatibility to talk about,
since the applications are going to be recompiled.


> <<
> - The project requires a library file "crtdll.lib" that does not exist
>   in that directory, and there is no doc indicating where to get it
>   from.>>
> This file is useful (allow don't include MS Runtime and use a DLL already
> installed on all Win32 platform)
> I suggest adding link to http://www.winimage.com/zLibDll/crtdll.lib in
> contrib/vstudio/readme.txt
> Note that the DLL project contain alredy target "ReleaseWithoutCrtDll"

Ok. Are you going to do it, or do you want me to do it?
I am asking, because I think you could write more documentation,
explaining, for example, that CrtDll is being used, that there are
additional exports, etc. These things are useful to be known.


> About 6) in your FAQ, can I suggest you add link to
> http://support.microsoft.com/?id=94248
> (section 5, Mixing Library Types)

Thanks.

Good idea, although I wonder if I can run into problems later on. MSDN
articles change their location all the time, and I don't want broken
links. But a reference to the Knowledge Base article 94248 is something
that I can add. The articles can always be found by searching in MSDN,
on the www or on the MSDN compact discs.


> <<
> - In zlib-...-cos1, the ASM interface is now unified with the rest of
>   the sources compiled with CDECL. I think it's a good idea to adapt
>   your ASM files and to put them into "contrib/asm686/", so that they
>   can work like the rest, and are available to all the other makefiles.>>
> Can you explain more what I need to modify in my assembly code to adapt.

It means that the "contrib/asm*/" files are now working with the C
sources. They didn't work when STDCALL was used. But if you will
continue with STDCALL, they still won't work, so you should probably
leave them as they are in that case.

Cosmin