[Zlib-devel] Avoiding WIN* macros in GNU code

[Cosmin Truta]

On Mon, 16 Jun 2003, Dmitriy Anisimkov wrote:

> <<The name ZLIB1.DLL comes from the "zlib"+"major version" naming
> scheme. I expect there will be big changes in a future zlib-2.0,>>
>
> I propose to do not put major version to the dll name.

This is common practice both in Windows and Unix. There is no risk of
misleading the people. They will know what this means.

> The Zlib API is stable enough.

Which means that zlib-1.x.x will last for a long time, which means that
ZLIB1.DLL will last for a long time. Which is good.
(Look at OLE2.DLL, which is around for more than 10 years.)

> If the new big changes would broke backward compartibility, then we
> have to change name.

Exactly. When the changes will be so big and break backwards
compatibility, there will be a zlib-2.0 and a ZLIB2.DLL.
If people will see ZLIB2.DLL, they will know it is something newer than
ZLIB1.DLL.

It is common to put version names in Windows DLLs; look into your SYSTEM
or SYSTEM32 directory and see what I mean.
It's pretty much the same thing, albeit more sophisticated, that happens
to the Unix shared libraries. These are the equivalents of DLLs in Unix.


> But now we need just separate different calling conventions.

No. We only need a standard ZLIB1.DLL. In the ZLIB DLL FAQ I explained
why the big majority needs this configuration (standard C library,
standard C calling convention, standard dynamic RTL == MSVCRT.DLL).

Everything else is needed only by a small fraction of people who can
rebuild zlib themselves -- provided they change the name of the DLL.
We cannot fulfill a plethora of mutually-incompatible needs:

- __stdcall calling convention (needed by older Visual Basic)
- __fastcall calling convention (needed but not req'd by Delphi)
- zlib linked to the static singlethreaded/multithreaded C library
- zlib linked to CRTDLL.DLL
- zlib linked to MSVCRT70.DLL
- zlib linked to the Borland C lib (again with cdecl/stdcall/fastcall)
- zlib linked to the CygWin lib (CYGWIN.DLL, or CYGWIN1.DLL, etc.)
- etc.

Once that we switch to a different library name, such as ZLIB1.DLL, we
won't need to maintain anymore a binary using __stdcall.


> I think it is better to put just calling convension to the dll name.

It is both technically and style-wise a bad idea to put low-level issues
into high-level names. Simply put, nobody does it.


> For example
>
> zlib-c.dll
> zlib-std.dll

"zlib-std" is misleading: people would think it means "standard zlib",
not "zlib with stdcall-decorated API".

"zlib-c" is again misleading: people would think it means "zlib for C",
or "zlib version C", or anything but "zlib with cdecl-decorated API".

Those examples should be called in fact "zlib-cdecl-msvcrt.dll", etc.
These names look ugly, and I didn't see any serious software provider
(either commercial or free) using this naming convention.

Noone represents low-level issues in library names. The healthy way to
go is to establish which are the actual low-level issues, and stick with
them consistently - rather than forking a build for each configuration
of low-level issues.

There is a notable exception in the use of the "16" and "32" suffixes.
This happened when the same source files were built into 16-bit and
32-bit binaries at the same time, and it was the only good solution.
Even this convention is disappearing, because 16-bit binaries themselves
are disappearing.


Best regards,
Cosmin