Академический Документы
Профессиональный Документы
Культура Документы
Welcome Guest |
Log In |
Register |
Benefits
Subscribe
Newsletters
Search: Site
Source Code
Digital Library
RSS
Home Articles News Blogs Source Code Dobb's TV Webinars & Events
Cloud Mobile Parallel .NET JVM Languages C/C++ Tools Design Testing Web Dev Jolt Awards
C/C++
Permalink
Tweet Like 0 Share Red
Mark examines zlib, a library of C routines that can be used to compress or expand files using
the same deflate algorithm popularized by PKZIP 2.0.
Afew months back, Scott Steketee, a developer of the educational/visualization tool The
Geometer's Sketchpad, asked via e-mail if I knew of a software package that could be used in
place of the compress.exe and expand.exe Windows files for installation. Scott commented that
the compression achieved by the standard Windows programs didn't seem to be very good.
I frequently see messages like this in Internet newsgroups such as comp.compression and
comp.lang.c, or on various CompuServe forums. Often, programmers find their needs aren't
being fulfilled by the Windows API functions in LZEXPAND.DLL (no compression functions) and
they don't want to spend money on third-party solutions, such as Greenleaf's ArchiveLib (which
I wrote).
Fortunately, I was able to point Scott to zlib, an efficient, portable, and free solution to his
problem. zlib is a library of C routines that can be used to compress or expand files using the
same deflate algorithm popularized by PKZIP 2.0.
zlib's roots are in Info-ZIP, a loosely organized group of programs that exists, according to its
authors, for the following reason:
...to provide free, portable, high-quality versions of the Zip and UnZip compressor-archiver
utilities that are compatible with the DOS-based PKZIP, by PKWARE, Inc.
The free versions of Zip and UnZip are world-class programs and are in wide use on many
platforms, including the Amiga through DOS PCs, and high-powered RISC workstations. But
these programs are designed to be used as command-line utilities, not as library routines.
People have found that porting the Info-ZIP source into an application can be a grueling
exercise.
Fortunately, two Info-ZIP gurus decided to solve this problem. Mark Adler and Jean-loup Gailly
single handedly created zlib, a set of library routines that provide a safe, free, and unpatented
zlib was created in part for use as the compressor for PNG-format graphics (see "PNG: The
Portable Network Graphic Format," by Lee Daniel Crocker, DDJ, July 1995). After Unisys
belatedly began asserting its patent rights to LZW compression, programmers were thrown into
a panic over the prospect of paying royalties on their GIF decoding programs. The PNG standard
was created to provide an unencumbered format for graphics interchange. The zlib version of
the deflate algorithm was embraced by PNG developers, not only because it was free, but
because it also compressed better than the original LZW compressor used in GIF files.
zlib turns out to be good for more than graphics development, however. The deflate algorithm
makes an excellent general-purpose compressor and can be incorporated into all sorts of
software. For example, I used zlib as the compression engine in Greenleaf's ArchiveLib, a data-
compression library that works with ZIP archives. Its performance and compatibility meant I
didn't have to reinvent the wheel, and I saved precious months of development time.
zlib's Interface
As a library developer, I know that interfaces make or break a library. Performance issues are
important, but if an awkward API makes it impossible to integrate a library into your program,
you've got a problem.
zlib's interface is confined to just a few simple function calls. The entire state of a given
compression/decompression session is encapsulated in a C structure of type z_stream; see
Figure 1.
There are three steps (see Figure 2) to using the library to compress or decompress a file or
other data object:
2.Process input and output, using the z_stream object to communicate with zlib.
Steps 1 and 3 of the compression process are done using conventional function calls. The zlib
API, documented in header file zlib.h, prototypes the following functions for initialization and
termination of the compression or decompression process:
deflateInit()
inflateInit()
deflateEnd()
inflateEnd()
Step 2 is done via repeated calls to either inflate() or deflate(), passing the z_stream object as
a parameter. The entire state of the process is contained in that object, so there are no global
flags or variables, which allows the library to be completely reentrant. Storing the state of the
process in a single object also cuts down on the number of parameters that must be passed to
the API functions.
When performing compression or decompression, zlib doesn't perform any I/O on its own.
Instead, it reads data from an input-buffer pointer that you supply in the z_stream object.
Simply set up a pointer to the next block of input data in member next_in, and place the
number of available bytes in the avail_in member. Likewise, zlib writes its output data to a
memory buffer set up in the next_out member. As it writes output bytes, zlib decrements the
avail_out member until it drops to 0.
Given this interface, step 2 of the compression process for an input file and an output file might
look something like Figure 3. This method of handling I/O frees zlib from having to implement
system-dependent read and write code, and it ensures that you can use the library to compress
any sort of input stream, not just files. It's simply a matter of replacing the wrapper code in
Figure 3 with a version customized for your data stream.
Wrapping it Up
While zlib's versatility is one of its strengths, I don't always need all that flexibility. For example,
to perform the simple file-compression task Scott asked about, it would be nice to just call a
single function to compress a file and another function to decompress. To make this possible, I
created a wrapper class called zlibEngine that provides a simple API that automates the
compression and decompression of files and uses virtual functions to let you customize your
user interface to zlib. Figure 4 is the entire class definition. There are two different groups of
members that are important in zlibEngine. The first is the set of functions providing the calling
interface to the engine. The second is the set of functions and data members used to create a
UI that is active during the compression process.
There are three C++ functions that implement the API for simple compression and
decompression. Before using the engine, you must call the constructor, the first function. Since
zlibEngine is derived from the z_stream object used as the interface to zlib, the constructor is,
in effect, also creating a z_stream object that will be used to communicate with zlib. In addition,
the constructor initializes some of the z_stream member variables that will be used in either
compression or decompression.
The two remaining functions are straightforward: compress() compresses a file using the deflate
algorithm. An optional level parameter sets a compression factor between 9 (maximum
compression) and 0 (no compression). decompress() decompresses a file, as you would expect.
The compression-level parameter isn't necessary when decompressing, due to the nature of the
deflate algorithm. Both of these functions return an integer-status code, defined in the zlib
header file zlib.h. Z_OK is returned when everything works as expected. I added an additional
code, Z_USER_ABORT, for an end-user abort of the compression or decompression process.
The wrapper class makes it much easier to compress or decompress files using zlib. You only
need to remember to
This means you can now perform compression with code as simple as that in Example 1.
The calling API doesn't really make much of a case for creating the zlibEngine class, nor do the
compress() and decompress() functions really need to be members of a class. In theory, a
global compress() function could just instantiate a z_stream object when called, without the
caller even being aware of it.
The reason for creating this engine class involves the user interface. It's nice to be able to track
the progress of your compression job while it's running. Conventional C libraries have to make
do with callback functions or inflexible standardized routines in order to provide feedback, but
C++ offers a better alternative through the use of virtual functions.
The zlibEngine class has two virtual functions that are used to create a useful UI: progress() is
called periodically during the compression or decompression process, with a single integer
argument that tells what percentage of the input file has been processed. status() is called with
status messages during processing.
Both of these virtual functions have access to the zlibEngine protected data element,
m_AbortFlag. Setting this flag to a nonzero value will cause the compression or decompression
routine to abort immediately. This takes care of another sticky UI problem you encounter when
using library code.
Writing your own UI then becomes a simple exercise. You derive a new class from zlibEngine
and define your own versions of one or both of these virtual functions. Once you instantiate an
object of your class instead of zlibEngine, your UI can be as spiffy and responsive as you like.
Command-Line Compression
I also wrote a command-line test program to demonstrate the use of class zlibEngine.
zlibtest.cpp does a simple compress/decompress cycle of the input file specified on the
command line. I implement a progress function that prints out the current percent toward
completion as the file is processed; see Example 2.
Since class zlibEngine is so simple, the derived class doesn't even have to implement a
constructor or destructor. The derived version of progress() is able to provide user feedback as
well as an abort function with just a few lines of code. zlibtest.cpp, zlibengn.h, and zlibengn.cpp
are available electronically (see "Availability," page 3).
The OCX
To provide a more complicated test of class zlibEngine, I created a 32-bit OCX using Visual C++
4.1. The interface to an OCX is defined in terms of methods, events, and properties. zlibTool.ocx
has the following interface:
Note that I chose to pass status information from the OCX using a property, not an event.
zlibTool.ocx is a control derived from a standard Win32 progress bar. The progress bar gets
updated automatically while compressing or decompressing, so you get some UI functionality
for free. Using it with Visual Basic 4.0 or Delphi 2.0 is a breeze. After registering the OCX, you
can drop a copy of it onto your form and use it with a minimal amount of coding.
Both the source code for the OCX and a sample Delphi 2.0 program are available electronically;
see "Availability," page 3. Figure 5 shows the Delphi program in action.
DDJ
The best place to find information on zlib and Info-ZIP software can be found online:
http://quest.jpl.nasa.gov/Info=ZIP/
http://quest.jpl.nasa.gov/zlib/
1 2 3 4 5 6 7 8 Next
Related Reading
Parallels Supports Docker Apps 2014 Developer Salary Survey An Algorithm for Compressing
Space and Time
20x Faster Test Scripting, 2013 Developer Salary Survey
Seriously A Simple and Efficient FFT
Developer Reading List Implementation in C++:
Devart dbForge Studio For Part I
MySQL With Phrase Completion NoSQL Options Compared
MongoDB with C#: Deep Dive
Restlet Completes "Complete" More Slideshows»
API Platform A Gentle Introduction to OpenCL
More Insights
White Papers Reports Webcasts
Case Study: Gilt Cloud Collaboration Tools: Big Advanced Threat Protection For
Hopes, Big Needs Dummies ebook and Using Big
Red Hat cloud a road map to Data Security Analytics to Identify
government cloud computing SaaS 2011: Adoption Soars, Yet Advanced Threats Webcast
based on openness, portability, Deployment Concerns Linger
and choice Accelerate Cloud Computing
More >> Success with Open Standards
More >>
More >>
Most Popular
Stories Blogs
Upcoming Events
Live Events WebCasts
No records found
Featured Reports
What's this?
More >>
Featured Whitepapers
What's this?
More >>
2014
Dr. Dobb's Journal
November - Mobile Development
August - Web Development
May - Testing
February - Languages
2013
January - Mobile Development
February - Parallel Programming
March - Windows Programming
April - Programming Languages
May - Web Development
June - Database Development
July - Testing
August - Debugging and Defect Management
September - Version Control
October - DevOps
November- Really Big Data
December - Design
2012
January - C & C++
February - Parallel Programming
March - Microsoft Technologies
April - Mobile Development
May - Database Programming
June - Web Development
July - Security
August - ALM & Development Tools
September - Cloud & Web Development
October - JVM Languages
November - Testing
December - DevOps
2011
TECHNOLOGY GROUP
Black Hat Enterprise Connect
Content Marketing Institute GDC
Content Marketing World Gamasutra
Dark Reading HDI
COMMUNITIES SERVED
Content Marketing
Enterprise IT
Enterprise Communications
Game Developers
Information Security
IT Services & Support
WORKING WITH US
Advertising Contacts
Event Calendar
Tech Marketing
Solutions
Contact Us
Licensing
Terms of Service | Privacy Statement | Legal Entities | Copyright © 2018 UBM, All rights reserved
Dr. Dobb's Home Articles News Blogs Source Code Dobb's TV Webinars & Events
About Us
Contact Us
Site Map
Editorial Calendar