0,0 → 1,861 |
__________________________________________________________________________ |
|
This is the Info-ZIP file INSTALL (for UnZip), last updated 16 Apr 2009. |
__________________________________________________________________________ |
|
Yes, this is a rather long file, but don't be intimidated: much of its |
length is due to coverage of multiple operating systems and of optional |
customization features, large portions of which may be skipped. |
__________________________________________________________________________ |
|
|
|
To compile UnZip, UnZipSFX and/or fUnZip (quick-start instructions): |
======================================== |
|
(1) Unpack everything into a work directory somewhere, and make sure you're |
in the main UnZip directory (the one with this file in it). |
* (See note below concerning line termination format used in the source |
distribution) |
|
(2) Copy the appropriate makefile into the current directory, except under |
OS/2. |
|
(3) Run your "make" utility on the makefile (e.g., "nmake -f makefile.msc"). |
|
(4) Try out your new UnZip the way you would any new utility: read the |
docs first. |
|
Ah ha ha ha!! Oh, that kills me. But seriously... For VMS, see the |
Install section below or [.vms]README. for details. |
|
For DOS and other OSes without explicit timezone support (i.e., everybody |
but Unix, Windows 95 and NT), make sure the "TZ" environment variable is |
set to a valid and reasonable value; see your compiler docs for details. |
|
(*) The unzip sources as well as other Info-ZIP source archives are packaged |
in Unix format. All text files use single LF (Ascii 0x0a) characters as |
line terminators. On systems that use different conventions for plain text |
files (e.g.:DOS,Win9x,WinNT,OS/2 -> combined CR+LF; MacOS -> single CR), |
some utilities (editors, compilers, etc.) may not accept source files |
with LF line terminators. |
For these systems, we recommend to use Info-ZIP's UnZip utility for |
extraction of our distribution archives, applying the command option |
"-a" (= translate text files to native format) in the extraction command. |
In case this procedure is not applicable, an appropiate third-party |
conversion utility may be used to achieve the desired line termination |
style (examples: "flip", available for Unix, DOS, OS/2; or "tr" on Unix). |
|
|
To compile UnZip, UnZipSFX and/or fUnZip (detailed instructions): |
======================================== |
|
(1) Unpack *.c and *.h (the actual source files), preserving the directory |
structure (e.g., ./unix/unix.c). The sole exception is TOPS-20, where |
tops20/* should be unpacked into the current directory, but TOPS-20 |
is no longer fully supported anyway. |
|
As of UnZip 5.41, full decryption support has been integrated in the |
UnZip source distribution. If you wish to compile binaries without |
decryption support, you must define the preprocessor flag NO_CRYPT. |
For many environments, you may add this flag to the custom compilation |
flags supplied by the environment variable LOCAL_UNZIP. For more |
details, see the make procedures and accompanied documentation for your |
particular target OS. |
|
As of UnZip 5.53, support for the bzip2 compression algorithm has been |
added to UnZip. However, this support requires the original sources of |
the bzip2 compression library which have to be aquired separately; |
see "http://www.bzip.org/" for further reference. |
|
|
(2) Choose the appropriate makefile based on the description in the Con- |
tents file for your OS (that is, there's only one for Unix or OS/2, but |
MS-DOS and several other OSes have several, depending on the compiler). |
Copy it into the current directory and rename if necessary or desired. |
(Some makefiles can be invoked in place; see (5) below.) |
|
Don't be afraid to read the makefile! Many options will be explained only |
in the comments contained therein. The defaults may not quite suit your |
system. When making changes, remember that some "make" utilities expect |
tabs as part of the makefile syntax. Failure with cryptic error messages |
will result if your editor quietly replaces those tabs with spaces. |
|
Special point of confusion: some non-MSDOS makefiles contain MS-DOS |
targets (useful for cross-compilations). An example is the OS/2 makefile |
os2/makefile.os2 that contains the gccdos target for DOS emx+gcc and |
some more DOS related targets for Watcom C and MSC. But since version 5.3, |
the msdos subdirectory contains makefiles for all supported DOS compilers. |
[The old djgpp, djgpp1 and gcc_dos targets in unix/Makefile have been |
removed in 5.3; use msdos/makefile.dj* instead.] |
|
Extra-special point of confusion: makefile.os2 expects to remain in |
the os2 subdirectory. Invoke it via "nmake -f os2/makefile.os2 gcc", |
for example. |
|
|
(3) If you want a non-standard version of UnZip, define one or more of the |
following optional macros, either by adding them to the LOCAL_UNZIP |
environment variable or by editing your makefile as appropriate. The |
syntax differs from compiler to compiler, but macros are often defined |
via "-DMACRO_NAME" or similar (for one called MACRO_NAME). Note that |
some of these may not be fully supported in future releases (or even |
in the current release). Note also that very short command lines in |
MS-DOS (128 characters) may place severe limits on how many of these |
can be used; if need be, the definitions can be placed at the top of |
unzip.h instead (it is included in all source files)--for example, |
"#define MACRO_NAME", one macro per line. |
|
DOSWILD (MS-DOS only) |
Treat trailing "*.*" like Unix "*" (i.e., matches anything); treat |
trailing "*." as match for files without a dot (i.e., matches any- |
thing, as long as no dots in name). Special treatment only occurs |
if patterns are at end of arguments; i.e., "a*.*" matches all files |
starting with "a", but "*.*c" matches all files ending in "c" *only* |
if they have a dot somewhere before the "c". [The default method of |
specifying files without a dot would be "* -x *.*", making use of |
UnZip's exclude-files option.] The matching is actually the same as |
Unix, if you assume that undotted filenames really have an invisible |
dot at the end, which is how DOS and related systems treat filenames |
in general. All other regular expressions (including "?" and |
"[range_of_chars]") retain their Unix-like behavior. |
|
WILD_STOP_AT_DIR (incompatible with WINDLL!) |
Enables an additional option "-W". When this qualifier is specified, |
the pattern matching routine is modified so that both '?' (single-char |
wildcard) and '*' (multi-char wildcard) do not match the directory |
separator character '/'. Examples: |
"*.c" matches "foo.c" but not "mydir/foo.c" |
"*/*.c" matches "bar/foo.c" but not "baz/bar/foo.c" |
"??*/*" matches "ab/foo" and "abc/foo" but not "a/foo" or "a/b/foo" |
To enable matching across directory separator chars, two consecutive |
multi-char wildcards "**" should be specified. |
This modified behaviour is equivalent to the pattern matching style |
used by the shells of some of UnZip's supported target OSs (one |
example is Acorn RISC OS). |
|
VMSWILD (VMS only) |
Use parentheses rather than brackets to delimit sets (ranges), and |
use '%' instead of '?' as the single-character wildcard for internal |
filename matching. (External matching of zipfile names always uses |
the standard VMS wildcard facilities; character sets are disallowed.) |
|
VMSCLI (VMS only) |
Use VMS-style "slash options" (/FOOBAR) instead of the default Unix- |
style hyphenated options (-f). This capability does not affect options |
stored in environment variables (UNZIP_OPTS or ZIPINFO_OPTS); those use |
the Unix style regardless. Beginning with UnZip 5.32, the supplied |
VMS build methods generate both VMS-style and default "UNIX-style" |
executables; you should NOT add VMSCLI to the custom options. |
|
CHECK_VERSIONS (VMS only) |
UnZip "extra fields" are used to store VMS (RMS) filesystem info, |
and the format of this information may differ in various versions |
of VMS. Defining this option will enable UnZip warnings when the |
stored extra-field VMS version(s) do(es) not match the version of |
VMS currently being used. This is a common occurrence in zipfiles |
received from other sites, but since the format of the filesystem |
does not seem to have changed in years (including on Alpha and |
IA64 systems), the warnings are not enabled by default. |
|
RETURN_CODES (VMS only) |
VMS interprets return codes according to a rigid set of guidelines, |
which means it misinterprets normal UnZip return codes as all sorts |
of really nasty errors. Therefore VMS UnZip returns an alternate set |
of return codes; since these may be difficult to interpret, define |
RETURN_CODES for human-readable explanations. |
|
VMS_TEXT_CONV (everybody except VMS) |
VMS Stream_LF-format text files archived with the "-V" option |
(/VMS), but NOT with -VV (/VMS=ALL), should be fine when extracted |
on other systems. Stream_LF-files archived with -VV should be |
readable as well, but they may get some junk appended. |
Text files with other formats (like the default VFC, with its |
embedded byte counts) may be only semi-readable at best when |
extracted on other systems. Defining this option enables UnZip's |
-aa option to detect and convert VMS VFC-record text files into |
native text format. Non-VMS UnZips now use a rudimentary VMS extra |
field analyser to relyably determine such text files. (Earlier |
versions of UnZip applied some heuristics instead.) |
Therefore this option is now enabled by default for the main program |
(but not the SFX stub), because it can be extremely useful on those |
rare occasions when a VMS text file must be extracted as normal text. |
|
USE_DJGPP_ENV (MS-DOS DJGPP 2.0x only) |
Regular DJGPP v2.0x compiled programs which use ENVIRONMENT are |
able to read from the file "djgpp.env" as well as those set in the |
environment. This adds about 1KB to the size of the executable. |
This option is disabled by default in Info-ZIP source. If you are |
able to use "djgpp.env" and don't like to clutter the environment |
with many special purpose variables, you may want to compile with |
this option set. |
|
USE_DJGPP_GLOB (MS-DOS DJGPP 2.0x only) |
If you like to get UnZip binaries that handle command line arguments |
similar to Unix tools which are run in an Unix shell, you might want |
to set this compilation option. This option enables the support for |
globbing command line arguments containing wildcards that is built |
into the DJGPP startup code. When using a binary compiled with this |
option, you may have to enclose wildcard arguments in double quotes |
to get them passed to the program unmodified. Enabling this option |
is not recommended, because it results in Info-Zip binaries that do |
not behave as expected for MS-DOS programs. |
|
USE_VFAT (MS-DOS only, for using same executable under DOS and Win95/NT) |
djgpp 2.x and emx/gcc+RSX 5.1 can detect when they are running under a |
Win32 DOS box and will accordingly enable long-filename support. For |
now only djgpp 2.x and emx/gcc with RSX 5.1 or later have this feature |
(and it is defined by default in msdos/makefile.dj2 and makefile.emx), |
but if/when other compilers build in similar support, define this |
macro to enable its use. See also msdos/doscfg.h. [Note that djgpp |
2.0's LFN support is flaky; users should upgrade to 2.01 or later.] |
|
NO_W32TIMES_IZFIX (Win32 including WinDLL, and WinCE) |
By specifying this option, you can disable Info-ZIP's special timestamp |
adjustment to get stable time stamps on NTFS disks that do not change |
depending on the current time being normal vs. daylight saving time. |
When this option is set, UnZip behaves exactly like other programs; |
file timestamps on NTFS partitions are created so that their >current< |
local time representation displayed by directory listings (cmd.exe |
"dir" command or Windows Explorer listings) is the same as shown by |
UnZip's listing. But the actual UTC timestamp values stored in the |
NTFS file attributes vary depending on whether extraction is done |
at summer or winter time. |
This option is not recommended because it sacrifies the timestamp |
comparison checks when extracting or modifying archives in "update |
only newer" mode. |
However, for environments where consistency of >displayed< dates |
of files extracted to NTFS vs. FAT disks is considered more important |
than correctly working update/freshen tasks of Zip&UnZip, this |
option may be used. |
>> DO NOT DISTRIBUTE OR PUBLISH executables that were compiled with |
this option! << |
|
NOTIMESTAMP |
This option disables the -T option, which basically does exactly what |
Zip's -go options do (i.e., set the timestamp of the zipfile to that of |
the newest file in the archive without rewriting the archive). Unlike |
Zip, however, UnZip supports wildcard specifications for the archive |
name; for example, "unzip -T *.zip" will set the dates of all zipfiles |
in the current directory. (UnZip's option is also much faster.) |
|
DATE_FORMAT=DF_DMY or DF_MDY or DF_YMD |
This option controls the order in which date components are printed |
in non-ZipInfo-mode listings: day-month-year or month-day-year or |
year-month-day. |
For DOS, FlexOS, OS2, Theos and Win32, the format is automatically |
obtained from the operating system; most others default to DF_MDY. |
|
DATE_SEPCHAR='-' or '.' or '/' etc. |
This option controls the character that separates the date components |
shown in (non-ZipInfo-mode) listings. The Win32 port obtains the |
separator automatically from the operating system's locale settings; |
all others default to '-'. |
|
ACORN_FTYPE_NFS (needs support for long filenames with embedded commas) |
This option enables a -F option that instructs UnZip to interpret the |
filetype information extracted from Acorn RiscOS extra field blocks. |
The filetype IDs are translated into "NFS filetype extensions" and |
appended to the names of the extracted files. This feature facilitates |
maintenance of Unix-based NFS volumes that are exported to Acorn RiscOS |
systems. |
|
QLZIP (Unix only) |
Add some support for QDOS extra fields. This option enables Unix |
UnZip to append "datalen info" to QDOS exec type files in the same |
format as used by QDOS cross-compilers on Unix or the qltools v2.2(+). |
|
UNIXBACKUP (default on OS/2, Unix, Win32) |
This option enables a -B option that instructs UnZip to rename files |
that would normally be overwritten. The renamed files are given a |
tilde suffix and a unique sequence number (`~#####'). Note that |
previously renamed files may be overwritten without notice, even |
if the -n option is given. |
On target ports where UNIXBACKUP is enabled by default, the negated |
option NO_UNIXBACKUP may be used to disable this feature. |
|
OS2_EAS |
List the sizes of OS/2 EAs and ACLs for each file as two extra columns |
in "unzip -l" output. This is primarily useful for OS/2 systems, but |
because zipfiles are portable, OS2_EAS can be defined for any system. |
(May be extended someday to show sizes of Mac resource forks, RISCOS |
and VMS file info, etc.) |
|
DELETE_IF_FULL (anybody with unlink() function) |
If a write error is encountered (most likely due to a full disk), |
enabling this option will cause the incomplete file to be deleted |
instead of closed normally. This is particularly useful for the |
Windows CE port, which must generally contend with extremely limited |
resources. |
|
ASM_CRC (Amiga/Aztec C; many x86 systems: DOS, OS/2, Win32, Unix) |
Use an assembler routine to calculate the CRC for each file (speed). |
|
ASM_INFLATECODES (Amiga/Aztec C only, for now) |
Use an assembler version of inflate_codes() for speed. |
|
OLD_EXDIR |
No longer supported. |
|
SFX_EXDIR |
Enable the "-d <extract_dir>" option for UnZipSFX. This is now |
enabled by default (since UnZip 5.5) to facilitate use with |
automated installation scripts and the like. For disabling |
this feature, see the NO_SFX_EXDIR option. |
|
NO_SFX_EXDIR |
Disables the "-d <extract_dir>" option for UnZipSFX to generate the |
smallest possible executable stub. (Prior to the UnZip 5.5 release, |
this was the default.) |
|
CHEAP_SFX_AUTORUN |
Enable a simple "run command after extraction" feature for |
the (command line) UnZipSFX stub. This feature is currently |
incompatible with the "-d <extract_dir>" command line option, |
therefore CHEAP_SFX_AUTORUN implicitely sets the NO_SFX_EXDIR |
option. |
|
NO_ZIPINFO |
Compile without ZipInfo mode (-Z) enabled; makes a smaller executable |
because many text strings are left out. Automatically enabled for |
some small-model compiles under MS-DOS and OS/2, so ordinarily there |
is no need to specify this explicitly. (Note that even with this |
defined, the resulting executable may still be too big to extract |
some zipfiles correctly, if compiled with the small memory model.) |
|
USE_DEFLATE64 (default for UnZip and fUnZip) |
NO_DEFLATE64 (default for UnZipSFX stub) |
The "deflate64" algorithm from PKZIP 4.0 (or newer) is an enhanced |
variant of the deflate algorithm that achieves slightly better |
compression ratios on highly redundant data. Normally, UnZip should |
be compiled with support for this compression algorithm enabled. |
However, this results in significantly larger memory requirements |
to run the program. For 16-bit executables (DOS and OS/2), the |
special memory management to support the 64k history buffer results |
in a slight performance (= speed) penalty. And for the SFX stub, |
"deflate64" support might be unnessessary as long as the Info-ZIP |
Zip utility does not support it (quite likely, this will never |
get implemented). So, the NO_DEFLATE64 option is provided to allow |
exclusion of the deflate64 support. |
|
USE_BZIP2 (requires additional external code distribution) |
UnZip can optionally support the "bzip2" compression algorithm for |
most ports on 32-bit (or higher) platforms. Currently, this support |
is integrated in the Make procedures of MSDOS 32-bit (DJGPP), VMS, |
Win32, and many Unix systems. |
Prerequisites: |
You have to obtain the bzip2 source distribution (version 1.03 or |
higher) and extract it into the "bzip2" subdirectory. |
Compilation: |
- MSDOS, Win32: You have to supply the symbol definition |
"USEBZ2=1" on the command line when you invoke the make program. |
- Unix: The target "generic" automatically activates bzip2 support |
when its configure script detects the presence of the bzip2 sources. |
For other targets, there are two options: |
a) Use the command |
"make -f unix/Makefile D_USE_BZ2=-DUSE_BZIP2 L_BZ2=-lbz2 \ |
LIBBZ2=bzip2/libbz2.a YourTarget" |
(Do not use the continuation line and replace YourTarget with |
the appropiate target name.) |
b) Edit the Makefile and remove the comment signs from the lines |
that define the macros D_USE_BZ2, L_BZ2, and LIBBZ2 (at about |
line 84 ff.). |
- VMS: The MMS/MMK build program should automatically activate the |
bzip2 support when it detects the presence of the bzip2 sources. |
|
MULT_VOLUME (experimental for 5.5x, do NOT use in production versions!) |
NO_MULT_VOLUME (default) |
The symbol MULT_VOLUME is used to flag code portions needed for |
support of multi-volume archives. For now, this flag MUST NOT be |
used to compile a production versions of UnZip. This flag has been |
introduced to allow integration of experimental code for multi-volume |
support in the master source tree. This feature will become a default |
option in the future 6.1 release of UnZip. |
|
LZW_CLEAN |
USE_UNSHRINK (now default, as of January 2005) |
The "shrinking" algorithm from PKZIP 1.0 is an LZW variant. Unisys |
patented the Lempel-Ziv-Welch algorithm in 1985 and has publicly |
claimed that decompression is covered by it. (IBM also patented the |
same thing in a filing 3 weeks prior to Unisys's.) In 2004, the |
Unisys and IBM patents expired worldwide, so unshrinking is now |
enabled again by default. If you do not wish to include the LZW |
method, you may still disable it by defining LZW_CLEAN. |
(Unshrinking was used by PKZIP 1.0 and 1.1, and Zip 1.0 and 1.1. |
All newer archives use only the deflation method.) |
|
COPYRIGHT_CLEAN (now default) |
USE_SMITH_CODE |
The last chunk of code in UnZip that was blatantly derived from Sam |
Smith's unzip 2.0 (as in, "substantially similar") is in unreduce.c. |
Since reducing was only used by very early PKZIP beta versions (0.9x), |
support for it is now omitted by default (COPYRIGHT_CLEAN). To in- |
clude unreducing capability, define USE_SMITH_CODE and replace the |
stub unreduce.c source file by the separatly distributed full source |
code module. Note that this subjects UnZip to any and all restrictions |
in Smith's copyright; see the UnZip COPYING.OLD file for details. |
|
USE_CRYPT |
Enable decryption support for all binaries. The default setting |
is to disable decryption support for the SFX stub to keep its size |
as small as possible. For other binaries of the UnZip distribution, |
decryption support is enabled by default. |
|
NO_CRYPT |
Disable decryption support for all binaries. |
|
PASSWD_FROM_STDIN (with full crypt sources only; Unix, VMS only) |
Used to allow the password on encrypted files to be read from stdin |
rather than the default stderr. This was useful for those who wished |
to automate the testing or decoding of encrypted archives (say, in a |
shell script via ``echo "password" | unzip -tq archive''), but as of |
version 5.3, UnZip has a -P option for passing a password directly to |
the program. PASSWD_FROM_STDIN will therefore probably be phased out |
in future versions. Note that the same security warnings given in the |
description of the -P option apply here as well. |
|
UNICODE_SUPPORT |
Enable restoring from UTF-8 encoded paths. These paths are stored |
in extra fields in a backward-compatible way so that archives with |
UTF-8 paths still work on zips and unzips that don't support Unicode. |
This support follows the recent additions to the PKWare AppNote for |
Unicode support, except that Unicode comments on systems where UTF-8 |
is not the current character set is not implemented in this release. |
|
Internally, Unicode support can be achieved by three methods: |
a) The charset encoding used by the system is already UTF-8, so |
the program just has to select the UTF-8 versions of the stored |
filenames for file name handling. |
This method is enabled by setting the symbol UTF8_MAYBE_NATIVE; |
this activates code to check for native UTF-8 encoding in the |
locale settings. |
b) The operating system and the compilation environment support |
"wide character" data in Unicode encoding (UCS-2/UTF-16 or UCS-4), |
which are used to translate between UTF-8 and the native |
extended-ASCII character encoding. |
The code for this method is activated by setting the preprocessor |
symbol UNICODE_WCHAR. |
It may be activated together with UTF8_MAYBE_NATIVE to provide |
more versatile Unicode support and additional "debugging" options |
for checking the correct recognition of non-ASCII Unicode |
characters. |
c) The operating system and the compilation environment allow to use |
unicode-encoded "wide character" data for native text strings |
support. |
Complete support for this method requires a throughout revision |
of the UnZip code. All internal string handling and text output |
needs to be ported to use wchar_t character storage. |
This porting is still in an experimental stage and not ready |
for general distribution. |
|
On some ports UNICODE_SUPPORT is set automatically: |
- WIN32 (and WinCE) use method b) by defining UNICODE_SUPPORT and |
UNICODE_WCHAR. |
- On Unix, the automatic configuration script enables UNICODE_WCHAR |
if ISO-10646 compatible wide characters are supported and |
UTF8_MAYBE_NATIVE if the locale detection call is available. |
For these ports, setting NO_UNICODE_SUPPORT forces deactivation of |
the Unicode support. |
|
NO_SETLOCALE (for Unix) |
On Unix, it is now assumed that <locale.h> and the setlocale function |
are available, to setup locale-aware filtering of displayed filenames. |
The option NO_SETLOCALE allows to disable the dependency on <locale.h> |
and setlocale() on systems where this assumption is invalid (and the |
auto-configuring make target "generic" cannot be used for capabilities |
detection). |
|
_MBCS |
NO_MBCS |
Enable multi-byte character set support. This is the default for the |
Human68k system (originated from Japan) and for Win32 (here only DBCS |
"double-byte character set" support). The MBCS support should also be |
enabled on systems which are capable of using UTF-8 as native charset. |
For MBCS support, the C runtime library must supply implementations |
for the mblen() function and the MB_CUR_MAX runtime macro/function. |
The NO_MBCS symbol allows to explicitely disable MBCS support for |
testing purpose, or when MBCS support does not work as expected. |
|
HAVE_WORKING_ISPRINT |
NO_WORKING_ISPRINT |
The symbol HAVE_WORKING_ISPRINT enables enhanced non-printable chars |
filtering for filenames in the fnfilter() function. On some systems |
(Unix, VMS, some Win32 compilers), this setting is enabled by default. |
In cases where isprint() flags printable extended characters as |
unprintable, defining NO_WORKING_ISPRINT allows to disable the enhanced |
filtering capability in fnfilter(). (The ASCII control codes 0x01 to |
0x1f are always escaped on ASCII systems.) |
|
DEBUG |
Used for debugging purposes; enables Trace() statements. Generally |
it's best to compile only one or two modules this way. |
|
DEBUG_TIME |
Used for debugging the timezone code in fileio.c; enables TTrace() |
statements. This code is only used for the freshen/update options |
(-f and -u), and non-Unix compilers often get it wrong. |
|
|
(4) If you regularly compile new versions of UnZip and always want the same |
non-standard option(s), you may wish to add it (them) to the LOCAL_UNZIP |
environment variable (assuming it's supported in your makefile). Under |
MS-DOS, for example, add this to AUTOEXEC.BAT: |
|
set LOCAL_UNZIP=-DDOSWILD -DDATE_FORMAT=DF_DMY |
|
You can also use the variable to hold special compiler options (e.g., |
-FPi87 for Microsoft C, if the x87 libraries are the only ones on your |
disk and they follow Microsoft's default naming conventions; MSC also |
supports the CL environment variable, however). |
|
|
(5) Run the make utility on your chosen makefile: |
|
Unix |
For most systems it's possible to invoke the makefile in place, at |
the possible cost of an ignorable warning; do "make -f unix/Makefile |
list" to get a list of possible system targets, and then "make -f |
unix/Makefile target" for your chosen target. The "generic" target |
works for most systems, but if it fails with a message about ftime() |
unresolved or timezone redefined, do "make clean", "make help", and |
then either "make generic2" or "make generic3" as instructed. If all |
else fails, read the makefile itself; it contains numerous comments. |
(One of these days we'll make a configure script that automates this |
procedure better.) |
|
VMS (OpenVMS): |
On VMS, two build methods are provided: a command procedure, and |
description files for MMS or MMK. Both methods must be run from |
the main directory, not the [.VMS] subdirectory. |
|
A simple build using the command procedure looks like this: |
@ [.VMS]BUILD_UNZIP.COM |
|
A simple build using MMS or MMK looks like this: |
MMS /DESCRIP = [.VMS]DESCRIP.MMS ! Or, with MMK, ... |
MMK /DESCRIP = [.VMS]DESCRIP.MMS |
|
Various options for each build method are explained in comments in |
the main builder file, either BUILD_UNZIP.COM or DESCRIP.MMS. |
|
Here are some more complex build examples: |
|
o Build with the large-file option enabled (non-VAX only): |
|
@ [.VMS]BUILD_UNZIP LARGE |
or: |
MMS /DESC = [.VMS] /MACRO = LARGE=1 |
|
o Re-link the executables (small-file and large-file): |
|
@ [.VMS]BUILD_UNZIP LINK |
@ [.VMS]BUILD_UNZIP LARGE LINK |
or |
MMK /DESC = [.VMS] CLEAN_EXE ! Deletes existing executables. |
MMK /DESC = [.VMS] ! Builds new executables. |
MMK /DESC = [.VMS] /MACRO = LARGE=1 CLEAN_EXE |
MMK /DESC = [.VMS] /MACRO = LARGE=1 |
|
o Build a large-file product from scratch, for debug, getting |
compiler listings and link maps: |
|
mms /desc = [.vms] clean |
mms /desc = [.vms] /macro = (DBG=1, LARGE=1. LIST=1) |
|
On VAX, the builders attempt to cope with the various available C |
compilers: DEC/Compaq/HP C, VAX C, or GNU C. If DEC/Compaq/HP C is |
not available or not desired, comments in the relevant builder file |
explain the command-line options used to select a different |
compiler. |
|
System-architecture-specific files (like objects and executables) |
are placed in separate directories, such as [.ALPHA], [.IA64], or |
[.VAX]. Large-file products get their own directories, [.ALPHAL] |
or [.IA64L]. On VAX, VAX C products are placed in [.VAXV], GNU C |
products in [.VAXG]. Each product builder announces what the |
destination directory will be when it is run. |
|
Common files, such as the help libraries (UNZIP.HLP for the |
default UNIX-like command-line interface, UNZIP_CLI.HLP for the |
VMS-like command-line interface), are placed in the main |
directory. With a mixed-architecture VMS cluster, the same main |
directory on a shared disk may may be used by all system types. |
(Using the NOHELP option with BUILD_UNZIP.COM can keep it from |
making the same help files repeatedly.) |
|
Some further information may be found in the files |
[.VMS]README. and [.VMS]00BINARY.VMS, though much of what's |
there is now obsolete. |
|
MS-DOS |
See the msdos\Contents file for notes regarding which makefile(s) to |
use with which compiler. In summary: pick one of msdos\makefile.* |
as appropriate, or (as noted above) use the OS/2 gccdos target for |
emx+gcc. There is also an mscdos cross-compilation target in |
os2\makefile.os2 and a sco_dos cross-compilation target in the Unix |
makefile. For Watcom 16-bit or 32-bit versions, see the comments in |
the OS/2 section below. |
|
After choosing the appropriate makefile and editing as necessary or |
desired, invoke the corresponding make utility. Microsoft's NMAKE |
and the free dmake and GNU make utilities are generally the most |
versatile. The makefiles in the msdos directory can be invoked in |
place ("nmake -f msdos\makefile.msc", for example). |
|
OS/2 |
Either GNU make, nmake or dmake may be used with the OS/2 makefile; |
all are freely available on the net. Do "nmake -f os2\makefile.os2", |
for example, to get a list of supported targets. More generally, |
read the comments at the top of the makefile for an explanation of |
the differences between some of the same-compiler targets. |
|
Win32 (WinNT or Win9x) |
For creating Win32 executables, the Microsoft Visual C++ compiler |
platforms from version 2.x up to 8.0 (Visual Studio .Net C++ 2005) |
are supported. Recent build test have been run on VC++ 6.0, 7.1 |
and 8.0. The linker of newer Microsoft Visual C++ versions (beginning |
with Visual C++ 2008 - [VC++ 9.0]) create executables that are marked |
to run on Windows 2000 and newer, only. Although these Visual C++ |
environments may succeed in building Win32 Info-ZIP executables, |
they cannot (and must not) be used to create binaries for public |
distribution. |
Alternative compilers for the Intel platforms are OpenWatcom C++, |
GNU C (preferably the mingw32 port, CygWin and emx/rsxnt may also |
work), Borland C++, or lcc-win32. |
DEC C/C++ for NT/Alpha may or may not still work. |
For the Watcom compiler, use WMAKE and win32\makefile.wat; for the |
Microsoft compilers, use NMAKE and win32\Makefile; for mingw32 and |
CygWin, GNU Make and win32\Makefile.gcc should do the job. |
With emx+gcc, a good choice is GNUMake 3.75 (or higher) from the |
djgpp V2 distribution used on win32\Makefile.emx. |
|
The unzip32.dll WinDLL executables can be built using the appropiate |
Makefile in the win32\ subdirectory, or by using the Microsoft Visual |
C++ project files supplied below the windll subdirectory. Besides the |
MSC compilers, gcc-mingw32, Watcom C and Borland C allow to build the |
Windows UnZip DLL. By default, the Makefiles for compilers that use |
the Microsoft C runtime are configured to link against the shared |
multithreading C runtime DLL. Depending on the intended usage for |
unzip32.dll, a statically linked dll might be more suitable. The |
make scripts for MSC support build variants with static linking; you |
should look up the configuration switch DLLSTANDALONE in the MSC |
Makefile or the "Static..." build configurations in the Visual Studio |
project files. |
|
WinCE (WinCE or WinNT) |
Only Microsoft Visual C++ 5.0, 6.0 or Visual C++ embedded 3.0 or later |
are supported. Use the appropiate version of the included project |
files and check wince\README for details. |
|
AmigaDOS |
SAS/Lattice C and Manx Aztec C are supported. For SAS C 6.x do "smake |
-f amiga/smakefile all"; for Aztec C do "make -f amiga/makefile.azt |
all". The Aztec C version supports assembly-language versions of two |
routines; these are enabled by default. |
|
Atari TOS |
Turbo C is no longer supported; use gcc and the MiNT libraries, and |
do "make". Note that all versions of gcc prior to 2.5.8 have a bug |
affecting 68000-based machines (optimizer adds 68020 instructions). |
See atari\README for comments on using other compilers. |
|
Macintosh |
Metrowerks CodeWarrior Pro 4 with Universal Interfaces 3.1 is the only |
currently supported compiler, although the Mac Programmer's Workbench |
(MPW) and Think C were supported at one time and still have some hooks. |
Other Compilers may work too, no compiler specific instructions |
(pragma, header, macros, ...) were used in the code. |
For CodeWarrior Pro 4, un-BinHex the CodeWarrior project file and |
UnZip resource file (using Stuffit Expander or BinHex 4.0 or later), |
then open the project and click on the compile button. |
See ":macos:Contents" for the possible project targets. |
Link order of the standard libraries is very important: Link all |
sources first and all standard libraries last. |
|
Acorn (RISC OS) |
Extract the files from the archive and place in standard 'Acorn' C |
form (i.e., *.c, *.h and *.s become c.*, h.* and s.*, respectively), |
either using the UNZIP$EXTS environment variable and a pre-built UnZip |
binary, or using Spark[FS] and doing it manually. Then copy the |
Acorn.Makefile to the main UnZip directory and either type 'amu' or |
use the desktop make utility. |
|
VM/CMS |
Unpack all the files and transfer them with ASCII -> EBCDIC conver- |
sion to an appropriate directory/minidisk/whatever, then execute |
UNZVMC to compile and link all the sources. This may require C/370 |
version 2.1 or later and certain `nucleus extensions,' although |
UnZip 5.3 has been reported to compile fine with the `ADCYCLE C/370 |
v1.2 compiler.' Note that it will abend without access to the C/370 |
runtime library. See the README.CMS file for more details. |
|
MVS |
Unpack all the files and transfer them to an appropriate PDS with |
ASCII -> EBCDIC conversion enabled, then edit UNZMVSC.JOB as required, |
and execute it to compile and link all the sources. C/370 2.1 or |
later is required. See README.MVS for further details. [This is a |
new port and may need a little more work even to compile.] |
|
Human68K |
[This is a Japanese machine and OS.] It appears that GNU make and |
gcc are required; presumably just do "gmake -f human68k/Makefile.gcc" |
to build everything. This port has not been tested since the 5.12 |
release. |
|
TOPS-20 |
[No longer fully supported due to new, unported features, although |
patches are always accepted.] Unpack all files into the current |
directory only (including those in the zipfile's tops20 directory), |
then use make.mic and "do make". |
|
BeOS |
You can run the BeOS makefile in place by typing "make -f |
beos/Makefile". In fact, this is how the author tests it. |
|
Running the appropriate make utility should produce three executables on |
most systems, one for UnZip/ZipInfo, one for UnZipSFX, and one for fUnZip. |
(VMS is one prominent exception: fUnZip makes no sense on it. The Amiga |
produces a fourth executable called MakeSFX, which is necessary because |
Amiga self-extracting archives cannot be created by simple concatenation. |
If necessary the source amiga/makesfx.c can be compiled on other systems.) |
Read any OS-specific README files for notes on setting things up for |
normal use (especially for VMS) and for warnings about known quirks and |
bugs in various compilers (especially for MS-DOS). |
|
Also note that many OSes require a timezone variable to be set correctly |
(often "TZ"); Unix and VMS generally do so by default, Win95/NT do if set |
up properly, but other OSes generally do not. See the discussion of the |
-f and -u options in the UnZip man page (or unzip.txt). BeOS doesn't |
currently support timezone information at all, but this will probably be |
added soon. |
|
Then test your new UnZip on a few archives and let us know if there are |
problems (but *please* first make certain that the archives aren't actu- |
ally corrupted and that you didn't make one of the silly mistakes dis- |
cussed in the documentation). If possible, double-check any problems |
with PKUNZIP or with a previous version of UnZip prior to reporting a |
"bug." The zipfile itself may be damaged. |
|
|
|
To install: |
=========== |
|
Unix |
The default prefix for the installation location is /usr/local (things |
go into the bin and man/man1 subdirectories beneath the prefix), and |
the default man-page extension is "1" (corresponding to man/man1, above). |
To install as per the defaults, do "make install"; otherwise do "make |
prefix=/your/path manext=your_extension install". (For Intel Unix flavors |
where the assembler CRC routines were used [ASM_CRC], use the install_asm |
target instead of the regular install target.) For example, to install |
in your home directory with "l" as the man-page extension (for "local"), |
do "make prefix=$HOME manext=l install". Permissions will be 755 for the |
executables and 644 for the man pages. In general root must perform in- |
stallation into a public directory. Do "rehash" if your shell requires |
it in order to find the new executables. |
|
VMS |
To complete the installation, the executables may be left in place, |
or moved (or copied) to a convenient place. While other methods |
(like DCL$PATH) exist, most users define symbols to make the UnZip |
executables available as foreign commands. These symbol definitions |
may be placed in a user's SYS$LOGIN:LOGIN.COM, or in a more central |
location, like SYS$MANAGER:SYLOGIN.COM. Typical symbol definitions |
might look like these: |
|
UNZIP :== $ dev:[dir]UNZIP.EXE ! UNIX-like command line. |
or: |
UNZIP :== $ dev:[dir]UNZIP_CLI.EXE ! VMS-like command line. |
|
For convenience, a ZIPINFO symbol could also be defined, so: |
|
ZIPINFO :== $ dev:[dir]UNZIP.EXE """-Z""" |
|
On a non-VAX system, different symbols could be defined for the |
small-file and large-file programs. For example: |
|
UNZIPS :== $ dev:[dir.ALPHA]UNZIP.EXE ! UNZIPS = small-file UnZip. |
UNZIP*L :== $ dev:[dir.ALPHAL]UNZIP.EXE ! UNZIP[L] = large-file UnZip. |
|
The builders create help text files, UNZIP.HLP and UNZIP_CLI.HLP. |
These may be incorporated into an existing help library, or a separate |
UnZip help library may be created using commands like these, using |
either UNZIP.HLP (as shown) or UNZIP_CLI.HLP: |
|
$ LIBRARY /HELP dev:[dir]existing_library.HLB UNZIP.HLP |
|
$ LIBRARY /CREATE /HELP UNZIP.HLB UNZIP.HLP |
|
UnZip help may then be accessed from a separate UnZip help library |
using a command like: |
|
$ HELP /LIBRARY = device:[directory]UNZIP.HLB |
|
For greater ease, the user (or system manager) may define a |
HLP$LIBRARY logical name to allow the HELP utility to find the UnZip |
help library automatically. See HELP HELP /USERLIBRARY for more |
details. The command procedure HLP_LIB_NEXT.COM may be used to |
determine the next available HLP$LIBRARY logical name, and could be |
adapted to define a HLP$LIBRARY logical name for an UnZip help library. |
|
The kit includes MAKESFX.COM, a command procedure intended to simplify |
creating a self-extracting archive. It may be helpful to install this |
procedure near the UnZip executables. MAKESFX.COM expects another |
symbol definition, like one of these: |
|
UNZIPSFX :== $ dev:[dir]UNZIPSFX.EXE ! UNIX-like command line. |
or: |
UNZIPSFX :== $ dev:[dir]UNZIPSFX_CLI.EXE ! VMS-like command line. |
|
Again here, on a non-VAX system, either a small-file or a large-file |
UNZIPSFX program may be used. (MAKESFX.COM could be modified to allow |
a run-time choice to be made.) |
|
OS/2, MS-DOS, NT, Atari, Amiga |
Move or copy unzip.exe (or unzip.ttp, or UnZip, or whatever) to a direc- |
tory in your path; also possibly copy the UnZip executable to zipinfo.exe |
(or ii.exe), or else create an alias or a batch/command file for ZipInfo |
("@unzip -Z %1 %2 %3 %4 %5 %6 %7 %8 %9" under MS-DOS). The latter is only |
relevant if NO_ZIPINFO was *not* defined, obviously... Under djgpp 2.x, |
zipinfo.exe is a 2K stub symbolically linked to unzip.exe. |
|
Acorn RISC OS |
Copy the executables unzip, funzip and zipinfo to somewhere in your |
Run$Path. See your Welcome manual if you don't know about Run$Path. |
|
BeOS |
The default prefix for the installation location is /boot/usr/local |
(things go into the bin and man/man1 subdirectories beneath the prefix), |
and the default man-page extension is "1" (corresponding to the man/man1, |
above). Of course, these Unix man-pages aren't useful until someone ports |
something that can format them... plain text versions are also installed |
with an extension of ".txt". To install, do a "make install", or to |
change the prefix, do "make prefix=/your/path install". For example, to |
install in /boot/bin, do "make prefix=/boot/bin install". |
|
Macintosh |
(This port is for Macintosh OS before Mac OS X. See Unix Apple below for |
Mac OS X and later.) |
MacZip requires at least System 7 and a Macintosh with a minimum of a |
Motorola 68020 or PowerPC 601 processor. Other configurations may work |
but it is not tested at all. |
The application (MacZip) is distributed as a combination of zip and unzip |
in one program. The offical release is a fat binary with both regular 68K |
and native PowerPC versions included. |
Move the executable(s) somewhere--for example, drag it (or them) to your |
Applications folder. For easy access, make an alias in the Launcher Control |
Panel or directly on your desktop. |
This port supports also Apple-event.So you can install it in your |
WWW-Browser as a helper-app. |
Look into "macos/README.TXT" (or ":macos:README.TXT" on Mac) for further |
info. |
|
Macintosh OS X (Unix Apple) |
Mac OS X and later are based on BSD Unix and are supported by the Unix |
port. See the Unix port for details. Though support is currently |
minimal, we plan to support additional Mac OS X features, such as resource |
forks, in future releases. |
|
Human68K, TOPS-20, AOS/VS, MVS, VM/CMS, etc. |
Dunno, sorry... |