Mercurial > hg > CbC > CbC_gcc
comparison zlib/win32/DLL_FAQ.txt @ 51:ae3a4bfb450b
add some files of version 4.4.3 that have been forgotten.
author | kent <kent@cr.ie.u-ryukyu.ac.jp> |
---|---|
date | Sun, 07 Feb 2010 18:27:48 +0900 |
parents | |
children | 04ced10e8804 |
comparison
equal
deleted
inserted
replaced
47:3bfb6c00c1e0 | 51:ae3a4bfb450b |
---|---|
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> |