1 | |
---|
2 | Frequently Asked Questions about ZLIB1.DLL |
---|
3 | |
---|
4 | |
---|
5 | This document describes the design, the rationale, and the usage |
---|
6 | of the official DLL build of zlib, named ZLIB1.DLL. If you have |
---|
7 | general questions about zlib, you should see the file "FAQ" found |
---|
8 | in the zlib distribution, or at the following location: |
---|
9 | http://www.gzip.org/zlib/zlib_faq.html |
---|
10 | |
---|
11 | |
---|
12 | 1. What is ZLIB1.DLL, and how can I get it? |
---|
13 | |
---|
14 | - ZLIB1.DLL is the official build of zlib as a DLL. |
---|
15 | (Please remark the character '1' in the name.) |
---|
16 | |
---|
17 | Pointers to a precompiled ZLIB1.DLL can be found in the zlib |
---|
18 | web site at: |
---|
19 | http://www.zlib.org/ |
---|
20 | |
---|
21 | Applications that link to ZLIB1.DLL can rely on the following |
---|
22 | specification: |
---|
23 | |
---|
24 | * The exported symbols are exclusively defined in the source |
---|
25 | files "zlib.h" and "zlib.def", found in an official zlib |
---|
26 | source distribution. |
---|
27 | * The symbols are exported by name, not by ordinal. |
---|
28 | * The exported names are undecorated. |
---|
29 | * The calling convention of functions is "C" (CDECL). |
---|
30 | * The ZLIB1.DLL binary is linked to MSVCRT.DLL. |
---|
31 | |
---|
32 | The archive in which ZLIB1.DLL is bundled contains compiled |
---|
33 | test programs that must run with a valid build of ZLIB1.DLL. |
---|
34 | It is recommended to download the prebuilt DLL from the zlib |
---|
35 | web site, instead of building it yourself, to avoid potential |
---|
36 | incompatibilities that could be introduced by your compiler |
---|
37 | and build settings. If you do build the DLL yourself, please |
---|
38 | make sure that it complies with all the above requirements, |
---|
39 | and it runs with the precompiled test programs, bundled with |
---|
40 | the original ZLIB1.DLL distribution. |
---|
41 | |
---|
42 | If, for any reason, you need to build an incompatible DLL, |
---|
43 | please use a different file name. |
---|
44 | |
---|
45 | |
---|
46 | 2. Why did you change the name of the DLL to ZLIB1.DLL? |
---|
47 | What happened to the old ZLIB.DLL? |
---|
48 | |
---|
49 | - The old ZLIB.DLL, built from zlib-1.1.4 or earlier, required |
---|
50 | compilation settings that were incompatible to those used by |
---|
51 | a static build. The DLL settings were supposed to be enabled |
---|
52 | by defining the macro ZLIB_DLL, before including "zlib.h". |
---|
53 | Incorrect handling of this macro was silently accepted at |
---|
54 | build time, resulting in two major problems: |
---|
55 | |
---|
56 | * ZLIB_DLL was missing from the old makefile. When building |
---|
57 | the DLL, not all people added it to the build options. In |
---|
58 | consequence, incompatible incarnations of ZLIB.DLL started |
---|
59 | to circulate around the net. |
---|
60 | |
---|
61 | * When switching from using the static library to using the |
---|
62 | DLL, applications had to define the ZLIB_DLL macro and |
---|
63 | to recompile all the sources that contained calls to zlib |
---|
64 | functions. Failure to do so resulted in creating binaries |
---|
65 | that were unable to run with the official ZLIB.DLL build. |
---|
66 | |
---|
67 | The only possible solution that we could foresee was to make |
---|
68 | a binary-incompatible change in the DLL interface, in order to |
---|
69 | remove the dependency on the ZLIB_DLL macro, and to release |
---|
70 | the new DLL under a different name. |
---|
71 | |
---|
72 | We chose the name ZLIB1.DLL, where '1' indicates the major |
---|
73 | zlib version number. We hope that we will not have to break |
---|
74 | the binary compatibility again, at least not as long as the |
---|
75 | zlib-1.x series will last. |
---|
76 | |
---|
77 | There is still a ZLIB_DLL macro, that can trigger a more |
---|
78 | efficient build and use of the DLL, but compatibility no |
---|
79 | longer dependents on it. |
---|
80 | |
---|
81 | |
---|
82 | 3. Can I build ZLIB.DLL from the new zlib sources, and replace |
---|
83 | an old ZLIB.DLL, that was built from zlib-1.1.4 or earlier? |
---|
84 | |
---|
85 | - In principle, you can do it by assigning calling convention |
---|
86 | keywords to the macros ZEXPORT and ZEXPORTVA. In practice, |
---|
87 | it depends on what you mean by "an old ZLIB.DLL", because the |
---|
88 | old DLL exists in several mutually-incompatible versions. |
---|
89 | You have to find out first what kind of calling convention is |
---|
90 | being used in your particular ZLIB.DLL build, and to use the |
---|
91 | same one in the new build. If you don't know what this is all |
---|
92 | about, you might be better off if you would just leave the old |
---|
93 | DLL intact. |
---|
94 | |
---|
95 | |
---|
96 | 4. Can I compile my application using the new zlib interface, and |
---|
97 | link it to an old ZLIB.DLL, that was built from zlib-1.1.4 or |
---|
98 | earlier? |
---|
99 | |
---|
100 | - The official answer is "no"; the real answer depends again on |
---|
101 | what kind of ZLIB.DLL you have. Even if you are lucky, this |
---|
102 | course of action is unreliable. |
---|
103 | |
---|
104 | If you rebuild your application and you intend to use a newer |
---|
105 | version of zlib (post- 1.1.4), it is strongly recommended to |
---|
106 | link it to the new ZLIB1.DLL. |
---|
107 | |
---|
108 | |
---|
109 | 5. Why are the zlib symbols exported by name, and not by ordinal? |
---|
110 | |
---|
111 | - Although exporting symbols by ordinal is a little faster, it |
---|
112 | is risky. Any single glitch in the maintenance or use of the |
---|
113 | DEF file that contains the ordinals can result in incompatible |
---|
114 | builds and frustrating crashes. Simply put, the benefits of |
---|
115 | exporting symbols by ordinal do not justify the risks. |
---|
116 | |
---|
117 | Technically, it should be possible to maintain ordinals in |
---|
118 | the DEF file, and still export the symbols by name. Ordinals |
---|
119 | exist in every DLL, and even if the dynamic linking performed |
---|
120 | at the DLL startup is searching for names, ordinals serve as |
---|
121 | hints, for a faster name lookup. However, if the DEF file |
---|
122 | contains ordinals, the Microsoft linker automatically builds |
---|
123 | an implib that will cause the executables linked to it to use |
---|
124 | those ordinals, and not the names. It is interesting to |
---|
125 | notice that the GNU linker for Win32 does not suffer from this |
---|
126 | problem. |
---|
127 | |
---|
128 | It is possible to avoid the DEF file if the exported symbols |
---|
129 | are accompanied by a "__declspec(dllexport)" attribute in the |
---|
130 | source files. You can do this in zlib by predefining the |
---|
131 | ZLIB_DLL macro. |
---|
132 | |
---|
133 | |
---|
134 | 6. I see that the ZLIB1.DLL functions use the "C" (CDECL) calling |
---|
135 | convention. Why not use the STDCALL convention? |
---|
136 | STDCALL is the standard convention in Win32, and I need it in |
---|
137 | my Visual Basic project! |
---|
138 | |
---|
139 | (For readability, we use CDECL to refer to the convention |
---|
140 | triggered by the "__cdecl" keyword, STDCALL to refer to |
---|
141 | the convention triggered by "__stdcall", and FASTCALL to |
---|
142 | refer to the convention triggered by "__fastcall".) |
---|
143 | |
---|
144 | - Most of the native Windows API functions (without varargs) use |
---|
145 | indeed the WINAPI convention (which translates to STDCALL in |
---|
146 | Win32), but the standard C functions use CDECL. If a user |
---|
147 | application is intrinsically tied to the Windows API (e.g. |
---|
148 | it calls native Windows API functions such as CreateFile()), |
---|
149 | sometimes it makes sense to decorate its own functions with |
---|
150 | WINAPI. But if ANSI C or POSIX portability is a goal (e.g. |
---|
151 | it calls standard C functions such as fopen()), it is not a |
---|
152 | sound decision to request the inclusion of <windows.h>, or to |
---|
153 | use non-ANSI constructs, for the sole purpose to make the user |
---|
154 | functions STDCALL-able. |
---|
155 | |
---|
156 | The functionality offered by zlib is not in the category of |
---|
157 | "Windows functionality", but is more like "C functionality". |
---|
158 | |
---|
159 | Technically, STDCALL is not bad; in fact, it is slightly |
---|
160 | faster than CDECL, and it works with variable-argument |
---|
161 | functions, just like CDECL. It is unfortunate that, in spite |
---|
162 | of using STDCALL in the Windows API, it is not the default |
---|
163 | convention used by the C compilers that run under Windows. |
---|
164 | The roots of the problem reside deep inside the unsafety of |
---|
165 | the K&R-style function prototypes, where the argument types |
---|
166 | are not specified; but that is another story for another day. |
---|
167 | |
---|
168 | The remaining fact is that CDECL is the default convention. |
---|
169 | Even if an explicit convention is hard-coded into the function |
---|
170 | prototypes inside C headers, problems may appear. The |
---|
171 | necessity to expose the convention in users' callbacks is one |
---|
172 | of these problems. |
---|
173 | |
---|
174 | The calling convention issues are also important when using |
---|
175 | zlib in other programming languages. Some of them, like Ada |
---|
176 | (GNAT) and Fortran (GNU G77), have C bindings implemented |
---|
177 | initially on Unix, and relying on the C calling convention. |
---|
178 | On the other hand, the pre- .NET versions of Microsoft Visual |
---|
179 | Basic require STDCALL, while Borland Delphi prefers, although |
---|
180 | it does not require, FASTCALL. |
---|
181 | |
---|
182 | In fairness to all possible uses of zlib outside the C |
---|
183 | programming language, we choose the default "C" convention. |
---|
184 | Anyone interested in different bindings or conventions is |
---|
185 | encouraged to maintain specialized projects. The "contrib/" |
---|
186 | directory from the zlib distribution already holds a couple |
---|
187 | of foreign bindings, such as Ada, C++, and Delphi. |
---|
188 | |
---|
189 | |
---|
190 | 7. I need a DLL for my Visual Basic project. What can I do? |
---|
191 | |
---|
192 | - Define the ZLIB_WINAPI macro before including "zlib.h", when |
---|
193 | building both the DLL and the user application (except that |
---|
194 | you don't need to define anything when using the DLL in Visual |
---|
195 | Basic). The ZLIB_WINAPI macro will switch on the WINAPI |
---|
196 | (STDCALL) convention. The name of this DLL must be different |
---|
197 | than the official ZLIB1.DLL. |
---|
198 | |
---|
199 | Gilles Vollant has contributed a build named ZLIBWAPI.DLL, |
---|
200 | with the ZLIB_WINAPI macro turned on, and with the minizip |
---|
201 | functionality built in. For more information, please read |
---|
202 | the notes inside "contrib/vstudio/readme.txt", found in the |
---|
203 | zlib distribution. |
---|
204 | |
---|
205 | |
---|
206 | 8. I need to use zlib in my Microsoft .NET project. What can I |
---|
207 | do? |
---|
208 | |
---|
209 | - Henrik Ravn has contributed a .NET wrapper around zlib. Look |
---|
210 | into contrib/dotzlib/, inside the zlib distribution. |
---|
211 | |
---|
212 | |
---|
213 | 9. If my application uses ZLIB1.DLL, should I link it to |
---|
214 | MSVCRT.DLL? Why? |
---|
215 | |
---|
216 | - It is not required, but it is recommended to link your |
---|
217 | application to MSVCRT.DLL, if it uses ZLIB1.DLL. |
---|
218 | |
---|
219 | The executables (.EXE, .DLL, etc.) that are involved in the |
---|
220 | same process and are using the C run-time library (i.e. they |
---|
221 | are calling standard C functions), must link to the same |
---|
222 | library. There are several libraries in the Win32 system: |
---|
223 | CRTDLL.DLL, MSVCRT.DLL, the static C libraries, etc. |
---|
224 | Since ZLIB1.DLL is linked to MSVCRT.DLL, the executables that |
---|
225 | depend on it should also be linked to MSVCRT.DLL. |
---|
226 | |
---|
227 | |
---|
228 | 10. Why are you saying that ZLIB1.DLL and my application should |
---|
229 | be linked to the same C run-time (CRT) library? I linked my |
---|
230 | application and my DLLs to different C libraries (e.g. my |
---|
231 | application to a static library, and my DLLs to MSVCRT.DLL), |
---|
232 | and everything works fine. |
---|
233 | |
---|
234 | - If a user library invokes only pure Win32 API (accessible via |
---|
235 | <windows.h> and the related headers), its DLL build will work |
---|
236 | in any context. But if this library invokes standard C API, |
---|
237 | things get more complicated. |
---|
238 | |
---|
239 | There is a single Win32 library in a Win32 system. Every |
---|
240 | function in this library resides in a single DLL module, that |
---|
241 | is safe to call from anywhere. On the other hand, there are |
---|
242 | multiple versions of the C library, and each of them has its |
---|
243 | own separate internal state. Standalone executables and user |
---|
244 | DLLs that call standard C functions must link to a C run-time |
---|
245 | (CRT) library, be it static or shared (DLL). Intermixing |
---|
246 | occurs when an executable (not necessarily standalone) and a |
---|
247 | DLL are linked to different CRTs, and both are running in the |
---|
248 | same process. |
---|
249 | |
---|
250 | Intermixing multiple CRTs is possible, as long as their |
---|
251 | internal states are kept intact. The Microsoft Knowledge Base |
---|
252 | articles KB94248 "HOWTO: Use the C Run-Time" and KB140584 |
---|
253 | "HOWTO: Link with the Correct C Run-Time (CRT) Library" |
---|
254 | mention the potential problems raised by intermixing. |
---|
255 | |
---|
256 | If intermixing works for you, it's because your application |
---|
257 | and DLLs are avoiding the corruption of each of the CRTs' |
---|
258 | internal states, maybe by careful design, or maybe by fortune. |
---|
259 | |
---|
260 | Also note that linking ZLIB1.DLL to non-Microsoft CRTs, such |
---|
261 | as those provided by Borland, raises similar problems. |
---|
262 | |
---|
263 | |
---|
264 | 11. Why are you linking ZLIB1.DLL to MSVCRT.DLL? |
---|
265 | |
---|
266 | - MSVCRT.DLL exists on every Windows 95 with a new service pack |
---|
267 | installed, or with Microsoft Internet Explorer 4 or later, and |
---|
268 | on all other Windows 4.x or later (Windows 98, Windows NT 4, |
---|
269 | or later). It is freely distributable; if not present in the |
---|
270 | system, it can be downloaded from Microsoft or from other |
---|
271 | software provider for free. |
---|
272 | |
---|
273 | The fact that MSVCRT.DLL does not exist on a virgin Windows 95 |
---|
274 | is not so problematic. Windows 95 is scarcely found nowadays, |
---|
275 | Microsoft ended its support a long time ago, and many recent |
---|
276 | applications from various vendors, including Microsoft, do not |
---|
277 | even run on it. Furthermore, no serious user should run |
---|
278 | Windows 95 without a proper update installed. |
---|
279 | |
---|
280 | |
---|
281 | 12. Why are you not linking ZLIB1.DLL to |
---|
282 | <<my favorite C run-time library>> ? |
---|
283 | |
---|
284 | - We considered and abandoned the following alternatives: |
---|
285 | |
---|
286 | * Linking ZLIB1.DLL to a static C library (LIBC.LIB, or |
---|
287 | LIBCMT.LIB) is not a good option. People are using the DLL |
---|
288 | mainly to save disk space. If you are linking your program |
---|
289 | to a static C library, you may as well consider linking zlib |
---|
290 | in statically, too. |
---|
291 | |
---|
292 | * Linking ZLIB1.DLL to CRTDLL.DLL looks appealing, because |
---|
293 | CRTDLL.DLL is present on every Win32 installation. |
---|
294 | Unfortunately, it has a series of problems: it does not |
---|
295 | work properly with Microsoft's C++ libraries, it does not |
---|
296 | provide support for 64-bit file offsets, (and so on...), |
---|
297 | and Microsoft discontinued its support a long time ago. |
---|
298 | |
---|
299 | * Linking ZLIB1.DLL to MSVCR70.DLL or MSVCR71.DLL, supplied |
---|
300 | with the Microsoft .NET platform, and Visual C++ 7.0/7.1, |
---|
301 | raises problems related to the status of ZLIB1.DLL as a |
---|
302 | system component. According to the Microsoft Knowledge Base |
---|
303 | article KB326922 "INFO: Redistribution of the Shared C |
---|
304 | Runtime Component in Visual C++ .NET", MSVCR70.DLL and |
---|
305 | MSVCR71.DLL are not supposed to function as system DLLs, |
---|
306 | because they may clash with MSVCRT.DLL. Instead, the |
---|
307 | application's installer is supposed to put these DLLs |
---|
308 | (if needed) in the application's private directory. |
---|
309 | If ZLIB1.DLL depends on a non-system runtime, it cannot |
---|
310 | function as a redistributable system component. |
---|
311 | |
---|
312 | * Linking ZLIB1.DLL to non-Microsoft runtimes, such as |
---|
313 | Borland's, or Cygwin's, raises problems related to the |
---|
314 | reliable presence of these runtimes on Win32 systems. |
---|
315 | It's easier to let the DLL build of zlib up to the people |
---|
316 | who distribute these runtimes, and who may proceed as |
---|
317 | explained in the answer to Question 14. |
---|
318 | |
---|
319 | |
---|
320 | 13. If ZLIB1.DLL cannot be linked to MSVCR70.DLL or MSVCR71.DLL, |
---|
321 | how can I build/use ZLIB1.DLL in Microsoft Visual C++ 7.0 |
---|
322 | (Visual Studio .NET) or newer? |
---|
323 | |
---|
324 | - Due to the problems explained in the Microsoft Knowledge Base |
---|
325 | article KB326922 (see the previous answer), the C runtime that |
---|
326 | comes with the VC7 environment is no longer considered a |
---|
327 | system component. That is, it should not be assumed that this |
---|
328 | runtime exists, or may be installed in a system directory. |
---|
329 | Since ZLIB1.DLL is supposed to be a system component, it may |
---|
330 | not depend on a non-system component. |
---|
331 | |
---|
332 | In order to link ZLIB1.DLL and your application to MSVCRT.DLL |
---|
333 | in VC7, you need the library of Visual C++ 6.0 or older. If |
---|
334 | you don't have this library at hand, it's probably best not to |
---|
335 | use ZLIB1.DLL. |
---|
336 | |
---|
337 | We are hoping that, in the future, Microsoft will provide a |
---|
338 | way to build applications linked to a proper system runtime, |
---|
339 | from the Visual C++ environment. Until then, you have a |
---|
340 | couple of alternatives, such as linking zlib in statically. |
---|
341 | If your application requires dynamic linking, you may proceed |
---|
342 | as explained in the answer to Question 14. |
---|
343 | |
---|
344 | |
---|
345 | 14. I need to link my own DLL build to a CRT different than |
---|
346 | MSVCRT.DLL. What can I do? |
---|
347 | |
---|
348 | - Feel free to rebuild the DLL from the zlib sources, and link |
---|
349 | it the way you want. You should, however, clearly state that |
---|
350 | your build is unofficial. You should give it a different file |
---|
351 | name, and/or install it in a private directory that can be |
---|
352 | accessed by your application only, and is not visible to the |
---|
353 | others (e.g. it's not in the SYSTEM or the SYSTEM32 directory, |
---|
354 | and it's not in the PATH). Otherwise, your build may clash |
---|
355 | with applications that link to the official build. |
---|
356 | |
---|
357 | For example, in Cygwin, zlib is linked to the Cygwin runtime |
---|
358 | CYGWIN1.DLL, and it is distributed under the name CYGZ.DLL. |
---|
359 | |
---|
360 | |
---|
361 | 15. May I include additional pieces of code that I find useful, |
---|
362 | link them in ZLIB1.DLL, and export them? |
---|
363 | |
---|
364 | - No. A legitimate build of ZLIB1.DLL must not include code |
---|
365 | that does not originate from the official zlib source code. |
---|
366 | But you can make your own private DLL build, under a different |
---|
367 | file name, as suggested in the previous answer. |
---|
368 | |
---|
369 | For example, zlib is a part of the VCL library, distributed |
---|
370 | with Borland Delphi and C++ Builder. The DLL build of VCL |
---|
371 | is a redistributable file, named VCLxx.DLL. |
---|
372 | |
---|
373 | |
---|
374 | 16. May I remove some functionality out of ZLIB1.DLL, by enabling |
---|
375 | macros like NO_GZCOMPRESS or NO_GZIP at compile time? |
---|
376 | |
---|
377 | - No. A legitimate build of ZLIB1.DLL must provide the complete |
---|
378 | zlib functionality, as implemented in the official zlib source |
---|
379 | code. But you can make your own private DLL build, under a |
---|
380 | different file name, as suggested in the previous answer. |
---|
381 | |
---|
382 | |
---|
383 | 17. I made my own ZLIB1.DLL build. Can I test it for compliance? |
---|
384 | |
---|
385 | - We prefer that you download the official DLL from the zlib |
---|
386 | web site. If you need something peculiar from this DLL, you |
---|
387 | can send your suggestion to the zlib mailing list. |
---|
388 | |
---|
389 | However, in case you do rebuild the DLL yourself, you can run |
---|
390 | it with the test programs found in the DLL distribution. |
---|
391 | Running these test programs is not a guarantee of compliance, |
---|
392 | but a failure can imply a detected problem. |
---|
393 | |
---|
394 | ** |
---|
395 | |
---|
396 | This document is written and maintained by |
---|
397 | Cosmin Truta <cosmint@cs.ubbcluj.ro> |
---|