1b33c96954667ba382fa595baf7b31290bfdd517vboxsync Frequently Asked Questions about ZLIB1.DLL
1b33c96954667ba382fa595baf7b31290bfdd517vboxsyncThis document describes the design, the rationale, and the usage
1b33c96954667ba382fa595baf7b31290bfdd517vboxsyncof the official DLL build of zlib, named ZLIB1.DLL. If you have
1b33c96954667ba382fa595baf7b31290bfdd517vboxsyncgeneral questions about zlib, you should see the file "FAQ" found
1b33c96954667ba382fa595baf7b31290bfdd517vboxsyncin the zlib distribution, or at the following location:
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync 1. What is ZLIB1.DLL, and how can I get it?
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync - ZLIB1.DLL is the official build of zlib as a DLL.
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync (Please remark the character '1' in the name.)
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync Pointers to a precompiled ZLIB1.DLL can be found in the zlib
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync web site at:
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync Applications that link to ZLIB1.DLL can rely on the following
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync specification:
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync * The exported symbols are exclusively defined in the source
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync files "zlib.h" and "zlib.def", found in an official zlib
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync source distribution.
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync * The symbols are exported by name, not by ordinal.
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync * The exported names are undecorated.
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync * The calling convention of functions is "C" (CDECL).
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync The archive in which ZLIB1.DLL is bundled contains compiled
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync test programs that must run with a valid build of ZLIB1.DLL.
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync It is recommended to download the prebuilt DLL from the zlib
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync web site, instead of building it yourself, to avoid potential
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync incompatibilities that could be introduced by your compiler
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync and build settings. If you do build the DLL yourself, please
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync make sure that it complies with all the above requirements,
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync and it runs with the precompiled test programs, bundled with
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync the original ZLIB1.DLL distribution.
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync If, for any reason, you need to build an incompatible DLL,
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync please use a different file name.
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync 2. Why did you change the name of the DLL to ZLIB1.DLL?
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync What happened to the old ZLIB.DLL?
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync - The old ZLIB.DLL, built from zlib-1.1.4 or earlier, required
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync compilation settings that were incompatible to those used by
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync a static build. The DLL settings were supposed to be enabled
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync by defining the macro ZLIB_DLL, before including "zlib.h".
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync Incorrect handling of this macro was silently accepted at
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync build time, resulting in two major problems:
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync * ZLIB_DLL was missing from the old makefile. When building
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync the DLL, not all people added it to the build options. In
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync consequence, incompatible incarnations of ZLIB.DLL started
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync to circulate around the net.
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync * When switching from using the static library to using the
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync DLL, applications had to define the ZLIB_DLL macro and
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync to recompile all the sources that contained calls to zlib
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync functions. Failure to do so resulted in creating binaries
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync that were unable to run with the official ZLIB.DLL build.
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync The only possible solution that we could foresee was to make
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync a binary-incompatible change in the DLL interface, in order to
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync remove the dependency on the ZLIB_DLL macro, and to release
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync the new DLL under a different name.
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync We chose the name ZLIB1.DLL, where '1' indicates the major
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync zlib version number. We hope that we will not have to break
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync the binary compatibility again, at least not as long as the
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync zlib-1.x series will last.
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync There is still a ZLIB_DLL macro, that can trigger a more
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync efficient build and use of the DLL, but compatibility no
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync longer dependents on it.
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync 3. Can I build ZLIB.DLL from the new zlib sources, and replace
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync an old ZLIB.DLL, that was built from zlib-1.1.4 or earlier?
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync - In principle, you can do it by assigning calling convention
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync keywords to the macros ZEXPORT and ZEXPORTVA. In practice,
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync it depends on what you mean by "an old ZLIB.DLL", because the
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync old DLL exists in several mutually-incompatible versions.
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync You have to find out first what kind of calling convention is
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync being used in your particular ZLIB.DLL build, and to use the
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync same one in the new build. If you don't know what this is all
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync about, you might be better off if you would just leave the old
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync DLL intact.
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync 4. Can I compile my application using the new zlib interface, and
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync link it to an old ZLIB.DLL, that was built from zlib-1.1.4 or
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync - The official answer is "no"; the real answer depends again on
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync what kind of ZLIB.DLL you have. Even if you are lucky, this
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync course of action is unreliable.
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync If you rebuild your application and you intend to use a newer
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync version of zlib (post- 1.1.4), it is strongly recommended to
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync link it to the new ZLIB1.DLL.
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync 5. Why are the zlib symbols exported by name, and not by ordinal?
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync - Although exporting symbols by ordinal is a little faster, it
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync is risky. Any single glitch in the maintenance or use of the
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync DEF file that contains the ordinals can result in incompatible
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync builds and frustrating crashes. Simply put, the benefits of
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync exporting symbols by ordinal do not justify the risks.
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync Technically, it should be possible to maintain ordinals in
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync the DEF file, and still export the symbols by name. Ordinals
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync exist in every DLL, and even if the dynamic linking performed
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync at the DLL startup is searching for names, ordinals serve as
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync hints, for a faster name lookup. However, if the DEF file
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync contains ordinals, the Microsoft linker automatically builds
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync an implib that will cause the executables linked to it to use
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync those ordinals, and not the names. It is interesting to
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync notice that the GNU linker for Win32 does not suffer from this
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync It is possible to avoid the DEF file if the exported symbols
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync are accompanied by a "__declspec(dllexport)" attribute in the
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync source files. You can do this in zlib by predefining the
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync ZLIB_DLL macro.
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync 6. I see that the ZLIB1.DLL functions use the "C" (CDECL) calling
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync convention. Why not use the STDCALL convention?
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync STDCALL is the standard convention in Win32, and I need it in
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync my Visual Basic project!
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync (For readability, we use CDECL to refer to the convention
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync triggered by the "__cdecl" keyword, STDCALL to refer to
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync the convention triggered by "__stdcall", and FASTCALL to
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync refer to the convention triggered by "__fastcall".)
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync - Most of the native Windows API functions (without varargs) use
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync indeed the WINAPI convention (which translates to STDCALL in
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync Win32), but the standard C functions use CDECL. If a user
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync application is intrinsically tied to the Windows API (e.g.
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync it calls native Windows API functions such as CreateFile()),
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync sometimes it makes sense to decorate its own functions with
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync WINAPI. But if ANSI C or POSIX portability is a goal (e.g.
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync it calls standard C functions such as fopen()), it is not a
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync sound decision to request the inclusion of <windows.h>, or to
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync use non-ANSI constructs, for the sole purpose to make the user
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync functions STDCALL-able.
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync The functionality offered by zlib is not in the category of
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync "Windows functionality", but is more like "C functionality".
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync Technically, STDCALL is not bad; in fact, it is slightly
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync faster than CDECL, and it works with variable-argument
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync functions, just like CDECL. It is unfortunate that, in spite
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync of using STDCALL in the Windows API, it is not the default
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync convention used by the C compilers that run under Windows.
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync The roots of the problem reside deep inside the unsafety of
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync the K&R-style function prototypes, where the argument types
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync are not specified; but that is another story for another day.
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync The remaining fact is that CDECL is the default convention.
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync Even if an explicit convention is hard-coded into the function
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync prototypes inside C headers, problems may appear. The
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync necessity to expose the convention in users' callbacks is one
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync of these problems.
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync The calling convention issues are also important when using
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync zlib in other programming languages. Some of them, like Ada
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync (GNAT) and Fortran (GNU G77), have C bindings implemented
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync initially on Unix, and relying on the C calling convention.
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync On the other hand, the pre- .NET versions of Microsoft Visual
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync Basic require STDCALL, while Borland Delphi prefers, although
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync it does not require, FASTCALL.
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync In fairness to all possible uses of zlib outside the C
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync programming language, we choose the default "C" convention.
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync Anyone interested in different bindings or conventions is
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync encouraged to maintain specialized projects. The "contrib/"
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync directory from the zlib distribution already holds a couple
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync of foreign bindings, such as Ada, C++, and Delphi.
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync 7. I need a DLL for my Visual Basic project. What can I do?
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync - Define the ZLIB_WINAPI macro before including "zlib.h", when
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync building both the DLL and the user application (except that
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync you don't need to define anything when using the DLL in Visual
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync Basic). The ZLIB_WINAPI macro will switch on the WINAPI
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync (STDCALL) convention. The name of this DLL must be different
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync than the official ZLIB1.DLL.
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync Gilles Vollant has contributed a build named ZLIBWAPI.DLL,
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync with the ZLIB_WINAPI macro turned on, and with the minizip
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync functionality built in. For more information, please read
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync the notes inside "contrib/vstudio/readme.txt", found in the
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync zlib distribution.
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync 8. I need to use zlib in my Microsoft .NET project. What can I
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync - Henrik Ravn has contributed a .NET wrapper around zlib. Look
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync into contrib/dotzlib/, inside the zlib distribution.
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync 9. If my application uses ZLIB1.DLL, should I link it to
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync - It is not required, but it is recommended to link your
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync The executables (.EXE, .DLL, etc.) that are involved in the
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync same process and are using the C run-time library (i.e. they
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync are calling standard C functions), must link to the same
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync library. There are several libraries in the Win32 system:
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync CRTDLL.DLL, MSVCRT.DLL, the static C libraries, etc.
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync Since ZLIB1.DLL is linked to MSVCRT.DLL, the executables that
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync depend on it should also be linked to MSVCRT.DLL.
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync10. Why are you saying that ZLIB1.DLL and my application should
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync be linked to the same C run-time (CRT) library? I linked my
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync application and my DLLs to different C libraries (e.g. my
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync application to a static library, and my DLLs to MSVCRT.DLL),
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync and everything works fine.
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync - If a user library invokes only pure Win32 API (accessible via
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync <windows.h> and the related headers), its DLL build will work
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync in any context. But if this library invokes standard C API,
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync things get more complicated.
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync There is a single Win32 library in a Win32 system. Every
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync function in this library resides in a single DLL module, that
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync is safe to call from anywhere. On the other hand, there are
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync multiple versions of the C library, and each of them has its
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync own separate internal state. Standalone executables and user
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync DLLs that call standard C functions must link to a C run-time
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync (CRT) library, be it static or shared (DLL). Intermixing
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync occurs when an executable (not necessarily standalone) and a
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync DLL are linked to different CRTs, and both are running in the
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync same process.
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync Intermixing multiple CRTs is possible, as long as their
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync internal states are kept intact. The Microsoft Knowledge Base
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync articles KB94248 "HOWTO: Use the C Run-Time" and KB140584
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync "HOWTO: Link with the Correct C Run-Time (CRT) Library"
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync mention the potential problems raised by intermixing.
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync If intermixing works for you, it's because your application
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync and DLLs are avoiding the corruption of each of the CRTs'
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync internal states, maybe by careful design, or maybe by fortune.
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync Also note that linking ZLIB1.DLL to non-Microsoft CRTs, such
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync as those provided by Borland, raises similar problems.
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync - MSVCRT.DLL exists on every Windows 95 with a new service pack
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync installed, or with Microsoft Internet Explorer 4 or later, and
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync on all other Windows 4.x or later (Windows 98, Windows NT 4,
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync or later). It is freely distributable; if not present in the
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync system, it can be downloaded from Microsoft or from other
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync software provider for free.
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync The fact that MSVCRT.DLL does not exist on a virgin Windows 95
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync is not so problematic. Windows 95 is scarcely found nowadays,
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync Microsoft ended its support a long time ago, and many recent
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync applications from various vendors, including Microsoft, do not
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync even run on it. Furthermore, no serious user should run
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync Windows 95 without a proper update installed.
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync12. Why are you not linking ZLIB1.DLL to
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync <<my favorite C run-time library>> ?
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync - We considered and abandoned the following alternatives:
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync * Linking ZLIB1.DLL to a static C library (LIBC.LIB, or
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync LIBCMT.LIB) is not a good option. People are using the DLL
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync mainly to save disk space. If you are linking your program
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync to a static C library, you may as well consider linking zlib
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync in statically, too.
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync * Linking ZLIB1.DLL to CRTDLL.DLL looks appealing, because
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync CRTDLL.DLL is present on every Win32 installation.
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync Unfortunately, it has a series of problems: it does not
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync work properly with Microsoft's C++ libraries, it does not
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync provide support for 64-bit file offsets, (and so on...),
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync and Microsoft discontinued its support a long time ago.
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync * Linking ZLIB1.DLL to MSVCR70.DLL or MSVCR71.DLL, supplied
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync with the Microsoft .NET platform, and Visual C++ 7.0/7.1,
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync raises problems related to the status of ZLIB1.DLL as a
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync system component. According to the Microsoft Knowledge Base
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync article KB326922 "INFO: Redistribution of the Shared C
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync Runtime Component in Visual C++ .NET", MSVCR70.DLL and
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync MSVCR71.DLL are not supposed to function as system DLLs,
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync because they may clash with MSVCRT.DLL. Instead, the
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync application's installer is supposed to put these DLLs
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync (if needed) in the application's private directory.
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync If ZLIB1.DLL depends on a non-system runtime, it cannot
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync function as a redistributable system component.
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync * Linking ZLIB1.DLL to non-Microsoft runtimes, such as
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync Borland's, or Cygwin's, raises problems related to the
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync reliable presence of these runtimes on Win32 systems.
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync It's easier to let the DLL build of zlib up to the people
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync who distribute these runtimes, and who may proceed as
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync explained in the answer to Question 14.
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync13. If ZLIB1.DLL cannot be linked to MSVCR70.DLL or MSVCR71.DLL,
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync how can I build/use ZLIB1.DLL in Microsoft Visual C++ 7.0
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync (Visual Studio .NET) or newer?
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync - Due to the problems explained in the Microsoft Knowledge Base
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync article KB326922 (see the previous answer), the C runtime that
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync comes with the VC7 environment is no longer considered a
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync system component. That is, it should not be assumed that this
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync runtime exists, or may be installed in a system directory.
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync Since ZLIB1.DLL is supposed to be a system component, it may
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync not depend on a non-system component.
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync In order to link ZLIB1.DLL and your application to MSVCRT.DLL
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync in VC7, you need the library of Visual C++ 6.0 or older. If
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync you don't have this library at hand, it's probably best not to
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync We are hoping that, in the future, Microsoft will provide a
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync way to build applications linked to a proper system runtime,
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync from the Visual C++ environment. Until then, you have a
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync couple of alternatives, such as linking zlib in statically.
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync If your application requires dynamic linking, you may proceed
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync as explained in the answer to Question 14.
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync14. I need to link my own DLL build to a CRT different than
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync MSVCRT.DLL. What can I do?
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync - Feel free to rebuild the DLL from the zlib sources, and link
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync it the way you want. You should, however, clearly state that
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync your build is unofficial. You should give it a different file
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync name, and/or install it in a private directory that can be
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync accessed by your application only, and is not visible to the
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync others (i.e. it's neither in the PATH, nor in the SYSTEM or
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync SYSTEM32 directories). Otherwise, your build may clash with
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync applications that link to the official build.
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync For example, in Cygwin, zlib is linked to the Cygwin runtime
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync CYGWIN1.DLL, and it is distributed under the name CYGZ.DLL.
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync15. May I include additional pieces of code that I find useful,
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync link them in ZLIB1.DLL, and export them?
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync - No. A legitimate build of ZLIB1.DLL must not include code
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync that does not originate from the official zlib source code.
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync But you can make your own private DLL build, under a different
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync file name, as suggested in the previous answer.
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync For example, zlib is a part of the VCL library, distributed
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync with Borland Delphi and C++ Builder. The DLL build of VCL
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync is a redistributable file, named VCLxx.DLL.
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync16. May I remove some functionality out of ZLIB1.DLL, by enabling
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync macros like NO_GZCOMPRESS or NO_GZIP at compile time?
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync - No. A legitimate build of ZLIB1.DLL must provide the complete
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync zlib functionality, as implemented in the official zlib source
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync code. But you can make your own private DLL build, under a
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync different file name, as suggested in the previous answer.
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync17. I made my own ZLIB1.DLL build. Can I test it for compliance?
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync - We prefer that you download the official DLL from the zlib
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync web site. If you need something peculiar from this DLL, you
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync can send your suggestion to the zlib mailing list.
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync However, in case you do rebuild the DLL yourself, you can run
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync it with the test programs found in the DLL distribution.
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync Running these test programs is not a guarantee of compliance,
1b33c96954667ba382fa595baf7b31290bfdd517vboxsync but a failure can imply a detected problem.
1b33c96954667ba382fa595baf7b31290bfdd517vboxsyncThis document is written and maintained by
1b33c96954667ba382fa595baf7b31290bfdd517vboxsyncCosmin Truta <cosmint@cs.ubbcluj.ro>