home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
BURKS 2
/
BURKS_AUG97.ISO
/
BURKS
/
SOFTWARE
/
SOURCES
/
UNZIP52.ZIP
/
README
(
.txt
)
< prev
next >
Wrap
Text File
|
1996-04-29
|
12KB
|
215 lines
This is the README file for the 30 April 1996 public release of the
Info-ZIP group's portable UnZip zipfile-extraction program (and related
utilities).
unzip52.zip portable UnZip, version 5.2, source code distribution
unzip52.tar.Z same as above, but compress'd tar format
__________________________________________________________________________
BEFORE YOU ASK: UnZip, its companion utility Zip, and related utilities
and support files can be found in many places; read the file "Where" for
further details. To contact the authors with suggestions, bug reports,
or fixes, continue reading this file (README) and, if this is part of a
source distribution, the file "ZipPorts". Also in source distributions:
read "BUGS" for a list of known bugs, non-bugs and possible future bugs;
INSTALL for instructions on how to build UnZip; and "Contents" for a com-
mented listing of all the distributed files.
__________________________________________________________________________
GENERAL INFO
------------
UnZip is an extraction utility for archives compressed in .zip format (also
called "zipfiles"). Although highly compatible both with PKWARE's PKZIP
and PKUNZIP utilities for MS-DOS and with Info-ZIP's own Zip program, our
primary objectives have been portability and non-MSDOS functionality.
This version of UnZip has been ported to a stupendous array of hardware--
from micros to supercomputers--and operating systems: Unix (many flavors),
VMS, OS/2 (including DLL version), Windows NT and Windows 95 (including DLL
version), Windows 3.x (including DLL versions), MS-DOS, AmigaDOS, Atari TOS,
Acorn RISC OS, Macintosh, VM/CMS, MVS (mostly), Human68k (mostly), AOS/VS
(partly) and TOPS-20 (partly). UnZip features not found in PKUNZIP include
source code; default extraction of directory trees (with a switch to defeat
this, rather than the reverse); OS/2, VMS, Unix, RISC OS and Macintosh ex-
tended file attributes; and, of course, the ability to run under most of
your favorite operating systems. Plus, it's free. :-)
For source distributions, see the main Contents file for a list of what's
included, and read INSTALL for instructions on compiling (including OS-
specific comments). The individual operating systems' Contents files (for
example, vms/Contents) may list important compilation info in addition to
explaining what files are what, so be sure to read them. Some of the ports
have their own, special README files, so be sure to look for those, too.
See unzip.1 or unzip.doc for usage (or the corresponding UnZipSFX, ZipInfo
and fUnZip docs). For VMS, unzip_def.rnh or unzip_cli.help may be compiled
into unzip.hlp and installed as a normal VMS help entry; see vms/descrip.mms.
CHANGES AND NEW FEATURES
------------------------
The 5.2 release adds many way-cool features:
- new "Unix" extra field to preserve file times across timezones and
operating systems (and, optionally within Unix, UID/GID info)
- new OS/2 access-control-list support (LAN Server/Requester, Warp Peer)
- new OS/2 -l listing of sizes of stored EAs and ACLs
- new Amiga self-extracting-zipfile support
- new assembly-language CRC routines for Intel and Motorola processors
- new -M "more" option
- extended VMS -b support to allow fixed-length 512-byte file format
- greatly updated Windows GUI interface (WizUnZip)
- new DLL ports: OS/2 (both C and REXX interfaces!), 16- and 32-bit Windows,
and some Unixen (see below for caveats)
- new Acorn RISC OS port
- new VM/CMS port
- new MVS port (mostly done)
- new AOS/VS port (partly done)
- unshrink() rewritten again for lower memory usage; now COPYRIGHT_CLEAN
is default for all systems (unreducing supported via compilation option)
- ability to pause zipfile comments with embedded ^S (useful for self-
extracting archives)
- many new work-arounds for broken zipfiles, compilers and/or OSes
- various performance enhancements
- lots of little fixes and improvements
The DLL ports need a little explaining. Basically, it's like this: as of
version 5.12, there were no DLL ports. During the 5.2 beta process, no less
than three completely independent DLL ports showed up. The first was Scott
Maxwell's OS/2 C and REXX DLL, which involved humongous changes to the code
to support reentrancy; it uses a simple and somewhat awkward strings-based
interface (that is, you basically create an UnZip command line and feed it
to the API functions). The second port was Stew Loving-Gibbard's 16-bit
Windows DLL. It too is strings-based and was created as part of another,
divergent project; it is no longer actively maintained and is therefore not
included with the main sources archive. The third DLL port was Mike White's
16- and 32-bit Windows DLLs, created as part of the latest WizUnZip (Windows
graphical interface) update. It uses a "binary" interface wherein UnZip's
internal variables can be set directly by API calls, without the need for
any awkward and artificial pseudo-command-line strings. This interface will
almost certainly become the "standard" UnZip DLL interface, but it still
needs to be merged with the unique features of the other ports (particularly
the OS/2 REXX code, which is naturally strings-based). And, of course, none
of this is documented particularly well, other than in the source code.
We'll get to it eventually. :-)
EXCUSES
-------
The more astute humanoids amongst you will notice that the promised multi-
part archive support did NOT make it into this release. The maintainer is
most apologetic; 1995 turned out to be a busy year, with a dissertation, a
new job and a new baby all colliding to make life extra-specially busy. The
massive code changes to support the various DLL ports didn't help any, either.
Multi-part archive support will be the very FIRST item on the list for ver-
sion 6.0, and with luck it will be released within six months or so of this
release, maybe even by summer. (No promises, but we'll try hard.)
On the plus side, special thanks go to Christian Spieler, who did a spectac-
ular job of integrating patches, fixing bugs, working with a remote VM/CMS
user to make that port fully functional, and just generally picking up a lot
of the slack. This release owes a lot to Christian's dedication.
"IMPOSTERS"
-----------
Info-ZIP is aware of four "imposter" zip programs, one of which creates .zip
files. The Andrew Toolkit (ATK) comes with a (now-obsolete) drawing editor
called "zip" that creates these files (incompatible with .zip archives, of
course); there is an interpreter for Infocom games called ZIP ("Z-code Inter-
preter Program); Chris Barker has developed a pseudo-random number generator
called "ZIP" for crypto purposes; and SGI may bundle an editor called "zip"
with some versions of their operating system (it has apparently been renamed
to "jot" in newer releases). The Andrew version actually predates not only
Info-ZIP but also PKWARE (1984), but fortunately it has been replaced by a
program called "figure" that uses the extension ".fi". The Infocom inter-
preter appears to postdate Info-ZIP's version by a couple of years, although
the documentation is too sparse to be certain. Barker's and SGI's versions
were certainly publicly released long after Info-ZIP's and may have been
created after ours, as well (almost certainly in the case of Barker's PRNG).
In any case, there's nothing to be done about it now; just be aware of the
potential name collisions and file incompatibilities (and upgrade to "figure"
if you still have Andrew Zip installed).
DISTRIBUTION
------------
If you have a question regarding redistribution of Info-ZIP software,
either as-is, as packaging for a commercial product, or as an integral
part of a commercial product, read the Frequently Asked Questions (FAQ)
section of the included COPYING file.
Insofar as C compilers are rare on some platforms and the authors only have
direct access to Unix, VMS, OS/2, MS-DOS, NT/Intel, Win95, Mac, Amiga and
Atari systems, others may wish to provide ready-to-run executables for new
systems. In general there is no problem with this; we require only that