Frequently Asked Questions about ZLIB1.DLL
This document describes the design, the rationale, and the usage
of the official DLL build of zlib, named ZLIB1.DLL. If you have
general questions about zlib, you should see the file "FAQ" found
in the zlib distribution, or at the following location:
http://www.gzip.org/zlib/zlib_faq.html
1. What is ZLIB1.DLL, and how can I get it?
- ZLIB1.DLL is the official build of zlib as a DLL.
(Please remark the character '1' in the name.)
Pointers to a precompiled ZLIB1.DLL can be found in the zlib
web site at:
http://www.zlib.net/
Applications that link to ZLIB1.DLL can rely on the following
specification:
* The exported symbols are exclusively defined in the source
files "zlib.h" and "zlib.def", found in an official zlib
source distribution.
* The symbols are exported by name, not by ordinal.
* The exported names are undecorated.
* The calling convention of functions is "C" (CDECL).
* The ZLIB1.DLL binary is linked to MSVCRT.DLL.
The archive in which ZLIB1.DLL is bundled contains compiled
test programs that must run with a valid build of ZLIB1.DLL.
It is recommended to download the prebuilt DLL from the zlib
web site, instead of building it yourself, to avoid potential
incompatibilities that could be introduced by your compiler
and build settings. If you do build the DLL yourself, please
make sure that it complies with all the above requirements,
and it runs with the precompiled test programs, bundled with
the original ZLIB1.DLL distribution.
If, for any reason, you need to build an incompatible DLL,
please use a different file name.
2. Why did you change the name of the DLL to ZLIB1.DLL?
What happened to the old ZLIB.DLL?
- The old ZLIB.DLL, built from zlib-1.1.4 or earlier, required
compilation settings that were incompatible to those used by
a static build. The DLL settings were supposed to be enabled
by defining the macro ZLIB_DLL, before including "zlib.h".
Incorrect handling of this macro was silently accepted at
build time, resulting in two major problems:
* ZLIB_DLL was missing from the old makefile. When building
the DLL, not all people added it to the build options. In
consequence, incompatible incarnations of ZLIB.DLL started
to circulate around the net.
* When switching from using the static library to using the
DLL, applications had to define the ZLIB_DLL macro and
to recompile all the sources that contained calls to zlib
functions. Failure to do so resulted in creating binaries
that were unable to run with the official ZLIB.DLL build.
The only possible solution that we could foresee was to make
a binary-incompatible change in the DLL interface, in order to
remove the dependency on the ZLIB_DLL macro, and to release
the new DLL under a different name.
We chose the name ZLIB1.DLL, where '1' indicates the major
zlib version number. We hope that we will not have to break
the binary compatibility again, at least not as long as the
zlib-1.x series will last.
There is still a ZLIB_DLL macro, that can trigger a more
efficient build and use of the DLL, but compatibility no
longer dependents on it.
3. Can I build ZLIB.DLL from the new zlib sources, and replace
an old ZLIB.DLL, that was built from zlib-1.1.4 or earlier?
- In principle, you can do it by assigning calling convention
keywords to the macros ZEXPORT and ZEXPORTVA. In practice,
it depends on what you mean by "an old ZLIB.DLL", because the
old DLL exists in several mutually-incompatible versions.
You have to find out first what kind of calling convention is
being used in your particular ZLIB.DLL build, and to use the
same one in the new build. If you don't know what this is all
about, you might be better off if you would just leave the old
DLL intact.
4. Can I compile my application using the new zlib interface, and
link it to an old ZLIB.DLL, that was built from zlib-1.1.4 or
earlier?
- The official answer is "no"; the real answer depends again on
what kind of ZLIB.DLL you have. Even if you are lucky, this
course of action is unreliable.
If you rebuild your application and you intend to use a newer
version of zlib (post- 1.1.4), it is strongly recommended to
link it to the new ZLIB1.DLL.
5. Why are the zlib symbols exported by name, and not by ordinal?
- Although exporting symbols by ordinal is a little faster, it
is risky. Any single glitch in the maintenance or use of the
DEF file that contains the ordinals can result in incompatible
builds and frustrating crashes. Simply put, the benefits of
exporting symbols by ordinal do not justify the risks.
Technically, it should be possible to maintain ordinals in
the DEF file, and still export the symbols by name. Ordinals
exist in every DLL, and even if the dynamic linking performed
at the DLL startup is searching for names, ordinals serve as
hints, for a faster name lookup. However, if the DEF file
contains ordinals, the Microsoft linker automatically builds
an implib that will cause the executables linked to it to use
those ordinals, and not the names. It is interesting to
notice that the GNU linker for Win32 does not suffer from this
problem.
It is possible to avoid the DEF file if the exported symbols
are accompanied by a "__declspec(dllexport)" attribute in the
source files. You can do this in zlib by predefining the
ZLIB_DLL macro.
6. I see that the ZLIB1.DLL functions use the "C" (CDECL) calling
convention. Why not use the STDCALL convention?
STDCALL is the standard convention in Win32, and I need it in
my Visual Basic project!
(For readability, we use CDECL to refer to the convention
triggered by the "__cdecl" keyword, STDCALL to refer to
the convention triggered by "__stdcall", and FASTCALL to
refer to the convention triggered by "__fastcall".)
- Most of the native Windows API functions (without varargs) use
indeed the WINAPI convention (which translates to STDCALL in
Win32), but the standard C functions use CDECL. If a user
application is intrinsically tied to the Windows API (e.g.
it calls native Windows API functions such as CreateFile()),
sometimes it makes sense to decorate its own functions with
WINAPI. But if ANSI C or POSIX portability is a goal (e.g.
it calls standard C functions such as fopen()), it is not a
sound decision to request the inclusion of <windows.h>, or to
use non-ANSI constructs, for the sole purpose to make the user
functions STDCALL-able.
The functionality offered by zlib is not in the category of
"Windows functionality", but is more like "C functionality".
Technically, STDCALL is not bad; in fact, it is slightly
faster than CDECL, and it works with variable-argument
functions, just like CDECL. It is unfortunate that, in spite
of using STDCALL in the Windows API, it is not the default
convention used by the C compilers that run under Windows.
The roots of the problem reside deep inside the unsafety of
the K&R-style function prototypes, where the argument types
are not specified; but that is another story for another day.
The remaining fact is that CDECL is the default convention.
Even if an explicit convention is hard-coded into the function
prototypes inside C headers, problems may appear. The
necessity to expose the convention in users' callbacks is one
of these problems.
The calling convention issues are also important when using
zlib in other programming languages. Some of them, like Ada
(GNAT) and Fortran (GNU G77), have C bindings implemented
initially on Unix, and relying on the C
没有合适的资源?快使用搜索试试~ 我知道了~
资源推荐
资源详情
资源评论
收起资源包目录
libharu 写PDF 开源 C C++ 库 (644个子文件)
miniunzip.1 2KB
minizip.1 1KB
makefile.32sunu 8KB
makefile.64sunu 8KB
configure.ac 786B
makefile.acorn 2KB
a010013l.afm 43KB
makefile.aix 4KB
Makefile.am 1KB
Makefile.am 818B
Makefile.am 590B
makefile.amiga 2KB
gvmat64.asm 16KB
inffas32.asm 16KB
match686.asm 15KB
inffasx64.asm 10KB
makefile.atari 2KB
options.awk 32KB
checksym.awk 6KB
dfn.awk 6KB
png2pnm.bat 2KB
pnm2png.bat 2KB
bld_ml32.bat 92B
bld_ml64.bat 86B
pngminus.bat 60B
makefile.bc32 4KB
makefile.beos 8KB
makefile.bor 4KB
Makefile.bor 3KB
hpdf_encoder_cns.c 844KB
hpdf_encoder_kr.c 642KB
hpdf_encoder_jp.c 366KB
hpdf_encoder_cnt.c 346KB
pngvalid.c 336KB
pngrtran.c 169KB
png.c 151KB
pngrutil.c 142KB
pngread.c 138KB
pngfix.c 130KB
hpdf_encoder.c 113KB
pngstest.c 109KB
hpdf_fontdef_base14.c 107KB
pngwutil.c 90KB
hpdf_page_operator.c 83KB
rpng2-x.c 81KB
pngwrite.c 78KB
deflate.c 70KB
unzip.c 69KB
hpdf_fontdef_tt.c 68KB
zip.c 64KB
hpdf_pages.c 60KB
pngtest.c 59KB
hpdf_doc.c 58KB
inflate.c 52KB
pngimage.c 50KB
pngset.c 47KB
rpng2-win.c 46KB
trees.c 43KB
makepng.c 41KB
gzlog.c 40KB
hpdf_streams.c 38KB
pngpread.c 37KB
hpdf_annotation.c 36KB
pngunknown.c 35KB
hpdf_fontdef_jp.c 35KB
hpdf_font_cid.c 34KB
pngget.c 34KB
wpng.c 31KB
rpng-x.c 31KB
hpdf_fontdef_kr.c 30KB
pngerror.c 29KB
tarith.c 28KB
VisualPng.c 27KB
hpdf_u3d.c 27KB
pngtrans.c 25KB
gun.c 25KB
infcover.c 24KB
rpng-win.c 24KB
enough.c 24KB
infback.c 22KB
hpdf_image_ccitt.c 22KB
hpdf_encrypt.c 20KB
hpdf_image_png.c 19KB
hpdf_image.c 19KB
gzread.c 18KB
readpng2.c 18KB
miniunz.c 17KB
gzappend.c 17KB
example.c 16KB
pnm2png.c 16KB
gzlib.c 16KB
gzwrite.c 16KB
pngwtran.c 15KB
minigzip.c 15KB
zran.c 15KB
pngpixel.c 15KB
hpdf_fontdef_type1.c 15KB
minizip.c 15KB
hpdf_pdfa.c 14KB
hpdf_dict.c 14KB
共 644 条
- 1
- 2
- 3
- 4
- 5
- 6
- 7
oldmtn
- 粉丝: 415
- 资源: 21
上传资源 快速赚钱
- 我的内容管理 展开
- 我的资源 快来上传第一个资源
- 我的收益 登录查看自己的收益
- 我的积分 登录查看自己的积分
- 我的C币 登录后查看C币余额
- 我的收藏
- 我的下载
- 下载帮助
最新资源
- 王锐的《OpenSceneGraph 3.0 Beginner's Guide》中文翻译版,个人读了翻译的很不错!值得推荐
- scr ubuntu上传
- AI Python编程学习课件-第6章深度学习
- STM32单片机FPGA毕设电路原理论文报告液晶显示模块与8031单片机的接口电路及编程
- STM32单片机FPGA毕设电路原理论文报告液晶航向指示器接口电路设计
- Pytorch深度学习入门与实战2024
- STM32单片机FPGA毕设电路原理论文报告野战救护车手术台稳定液压系统及其自动控制
- STM32单片机FPGA毕设电路原理论文报告压延机卷取调速装置改造
- STM32单片机FPGA毕设电路原理论文报告形状记忆合金驱动的微电脑密码锁的设计
- HTML小游戏27 - Chuck Chicken 魔法蛋网页游戏源码
资源上传下载、课程学习等过程中有任何疑问或建议,欢迎提出宝贵意见哦~我们会及时处理!
点击此处反馈
安全验证
文档复制为VIP权益,开通VIP直接复制
信息提交成功
- 1
- 2
- 3
前往页