Lines Matching +full:readme +full:. +full:installer
2 Frequently Asked Questions about ZLIB1.DLL
6 of the official DLL build of zlib, named ZLIB1.DLL. If you have
9 http://www.gzip.org/zlib/zlib_faq.html
12 1. What is ZLIB1.DLL, and how can I get it?
14 - ZLIB1.DLL is the official build of zlib as a DLL.
15 (Please remark the character '1' in the name.)
17 Pointers to a precompiled ZLIB1.DLL can be found in the zlib
19 http://www.zlib.net/
21 Applications that link to ZLIB1.DLL can rely on the following
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.
32 The archive in which ZLIB1.DLL is bundled contains compiled
33 test programs that must run with a valid build of ZLIB1.DLL.
37 and build settings. If you do build the DLL yourself, please
40 the original ZLIB1.DLL distribution.
43 please use a different file name.
46 2. Why did you change the name of the DLL to ZLIB1.DLL?
47 What happened to the old ZLIB.DLL?
49 - The old ZLIB.DLL, built from zlib-1.1.4 or earlier, required
51 a static build. The DLL settings were supposed to be enabled
52 by defining the macro ZLIB_DLL, before including "zlib.h".
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.
64 functions. Failure to do so resulted in creating binaries
65 that were unable to run with the official ZLIB.DLL build.
70 the new DLL under a different name.
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
75 zlib-1.x series will last.
79 longer dependents on it.
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?
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.
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
93 DLL intact.
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
101 what kind of ZLIB.DLL you have. Even if you are lucky, this
102 course of action is unreliable.
105 version of zlib (post- 1.1.4), it is strongly recommended to
106 link it to the new ZLIB1.DLL.
109 5. Why are the zlib symbols exported by name, and not by ordinal?
112 is risky. Any single glitch in the maintenance or use of the
114 builds and frustrating crashes. Simply put, the benefits of
115 exporting symbols by ordinal do not justify the risks.
118 the DEF file, and still export the symbols by name. Ordinals
121 hints, for a faster name lookup. However, if the DEF file
124 those ordinals, and not the names. It is interesting to
126 problem.
130 source files. You can do this in zlib by predefining the
131 ZLIB_DLL macro.
134 6. I see that the ZLIB1.DLL functions use the "C" (CDECL) calling
135 convention. Why not use the STDCALL convention?
142 refer to the convention triggered by "__fastcall".)
146 Win32), but the standard C functions use CDECL. If a user
147 application is intrinsically tied to the Windows API (e.g.
150 WINAPI. But if ANSI C or POSIX portability is a goal (e.g.
152 sound decision to request the inclusion of <windows.h>, or to
154 functions STDCALL-able.
157 "Windows functionality", but is more like "C functionality".
161 functions, just like CDECL. It is unfortunate that, in spite
163 convention used by the C compilers that run under Windows.
166 are not specified; but that is another story for another day.
168 The remaining fact is that CDECL is the default convention.
170 prototypes inside C headers, problems may appear. The
172 of these problems.
175 zlib in other programming languages. Some of them, like Ada
177 initially on Unix, and relying on the C calling convention.
178 On the other hand, the pre- .NET versions of Microsoft Visual
180 it does not require, FASTCALL.
183 programming language, we choose the default "C" convention.
185 encouraged to maintain specialized projects. The "contrib/"
187 of foreign bindings, such as Ada, C++, and Delphi.
190 7. I need a DLL for my Visual Basic project. What can I do?
192 - Define the ZLIB_WINAPI macro before including "zlib.h", when
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.
199 Gilles Vollant has contributed a build named ZLIBWAPI.DLL,
201 functionality built in. For more information, please read
202 the notes inside "contrib/vstudio/readme.txt", found in the
203 zlib distribution.
206 8. I need to use zlib in my Microsoft .NET project. What can I
209 - Henrik Ravn has contributed a .NET wrapper around zlib. Look
210 into contrib/dotzlib/, inside the zlib distribution.
213 9. If my application uses ZLIB1.DLL, should I link it to
214 MSVCRT.DLL? Why?
217 application to MSVCRT.DLL, if it uses ZLIB1.DLL.
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
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.
228 10. Why are you saying that ZLIB1.DLL and my application should
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.
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.
239 There is a single Win32 library in a Win32 system. Every
241 is safe to call from anywhere. On the other hand, there are
243 own separate internal state. Standalone executables and user
245 (CRT) library, be it static or shared (DLL). Intermixing
248 same process.
251 internal states are kept intact. The Microsoft Knowledge Base
254 mention the potential problems raised by intermixing.
258 internal states, maybe by careful design, or maybe by fortune.
260 Also note that linking ZLIB1.DLL to non-Microsoft CRTs, such
261 as those provided by Borland, raises similar problems.
264 11. Why are you linking ZLIB1.DLL to MSVCRT.DLL?
266 - MSVCRT.DLL exists on every Windows 95 with a new service pack
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
271 software provider for free.
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,
277 even run on it. Furthermore, no serious user should run
278 Windows 95 without a proper update installed.
281 12. Why are you not linking ZLIB1.DLL to
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
290 in statically, too.
292 * Linking ZLIB1.DLL to CRTDLL.DLL looks appealing, because
293 CRTDLL.DLL is present on every Win32 installation.
296 provide support for 64-bit file offsets, (and so on...),
297 and Microsoft discontinued its support a long time ago.
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
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.
312 * Linking ZLIB1.DLL to non-Microsoft runtimes, such as
314 reliable presence of these runtimes on Win32 systems.
317 explained in the answer to Question 14.
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?
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.
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
335 use ZLIB1.DLL.
339 from the Visual C++ environment. Until then, you have a
340 couple of alternatives, such as linking zlib in statically.
342 as explained in the answer to Question 14.
345 14. I need to link my own DLL build to a CRT different than
346 MSVCRT.DLL. What can I do?
349 it the way you want. You should, however, clearly state that
350 your build is unofficial. You should give it a different file
353 others (i.e. it's neither in the PATH, nor in the SYSTEM or
354 SYSTEM32 directories). Otherwise, your build may clash with
355 applications that link to the official build.
358 CYGWIN1.DLL, and it is distributed under the name CYGZ.DLL.
361 15. May I include additional pieces of code that I find useful,
362 link them in ZLIB1.DLL, and export them?
364 - No. A legitimate build of ZLIB1.DLL must not include code
365 that does not originate from the official zlib source code.
367 file name, as suggested in the previous answer.
370 with Borland Delphi and C++ Builder. The DLL build of VCL
371 is a redistributable file, named VCLxx.DLL.
374 16. May I remove some functionality out of ZLIB1.DLL, by enabling
377 - No. A legitimate build of ZLIB1.DLL must provide the complete
379 code. But you can make your own private DLL build, under a
380 different file name, as suggested in the previous answer.
383 17. I made my own ZLIB1.DLL build. Can I test it for compliance?
386 web site. If you need something peculiar from this DLL, you
387 can send your suggestion to the zlib mailing list.
390 it with the test programs found in the DLL distribution.
392 but a failure can imply a detected problem.
397 Cosmin Truta <cosmint@cs.ubbcluj.ro>