izreadme.sms

zip压缩

IZREADME_SMS (IZREADME.SMS): Info-ZIP for SMS/QDOS,   last revised: 15-Jun-1998
===============================================================================
[was "InfoZIP_SMSQDOS_ReadMe" in J. Hudson's original ports, ca. 08/1995]

Info-ZIP Programs
=================

Zip
UnZip
UnZipSFX
fUnZip

Introduction
------------

This archive is a result of frustrations with contemporary (August 95)
versions of Zip and UnZip. While they use the same compression
algorithms as the Info-ZIP programs, there the compatibility ends. If
you just use Zip/UnZip only on SMS/QDOS, then perhaps this is not a
problem (but I know for some users it still is); if you use Zip/UnZip
to transport source code and data between diverse systems, then the
disregard for Info-ZIP standards is inconvenient, particularly the
fact that directories are not supported and files are always stored
underscored.

This release of Zip/UnZip offers:

    o   zipfile/directory compatibility with all other supported
        platforms

    o   SMS/QDOS compatibility and back-compatible with earlier
        versions.

    o   Improved performance (Zip is typically 50% faster)

    o   Command-line compatibility with Info-ZIP

    o   Self-extracting archives (but not very elegantly)

    o   Archives are marked as 'created by SMS/QDOS'.

    o   Optional recursion into directories

    o   Directory structure restored on unzip of Info-ZIP/PKZIP-
        compatible archives.

    o   Config'urable for listing and unpack formats (Info-ZIP (.) or
        SMS/QDOS (_) and 'Press any key' timeouts. Override options
        from command line.

Info-ZIP Standards
------------------

This (rather long-winded and waffling) section discusses the
conventions and standards used by Info-ZIP-compatible archivers and how
"Info-ZIP for SMS/QDOS" achieves compatibility.

Info-ZIP Zip/UnZip on all supported platforms (Unix, DOS, OS/2, NT,
VAX/VMS, Amiga etc etc), works in a specific way. (Until now SMS/QDOS
was neither 'supported' nor Info-ZIP-compliant.)

    a. The zipfile directory is in (/.) (Unix) format.

    b. When zips are listed, it is in 'zipfile' (Unix) format.

    c. When files are added, they are defined in native format.

    d. When files are added, this is shown in 'zipfile' format.

    e. When files are unpacked, this is done to native format, but
       selection is done in 'zipfile' format.

Basically, the listing and stored format of a file is that of the
destination.

So, given a file structure at some arbitrary 'root' level.

    Makefile
    src (Dir)
        afile.c
        bfile.c
        docs (Dir)
             prog.txt
    hdr (Dir)
        cfile.h
        dfile.h

Then these would be in Unix (and Amiga) as

     Makefile
     src/afile.c
     src/bfile.c
     src/docs/prog.txt
     hdr/cfile.h
     hdr/dfile.h

This is also how the zipfile directory appears.

And in DOS/OS2/NT

    Makefile
    src\afile.c
    src\docs\prog.txt
    hdr\cfile.h         .. etc

And in VMS      (we SHOUT in VMS and have a silly file system)

    MAKEFILE
    [SRC]AFILE.C
    [SRC.DOC]PROG.TXT
    [HDR]CFILE.H        .. etc
                        (OK VMS purist, [.SRC] etc. Only an example)

And in SMS/QDOS (quiet again, but slightly ludicrous !)

    Makefile
    src_afile_c
    src_doc_prog_txt
    hdr_cfile_h         .. etc

The main problem regarding SMS/QDOS is not that of extensions - (after
all, only VMS and DOS _really_ have extensions; Unix, AmigaDOS, NT and
OS/2 (and Win95) allow multiple '.' in.long.file.names.

The SMS/QDOS problem is that '_' is both a legal file name character
and a directory separator. This creates the difficulties, as
directories and files are somewhat different objects.

It is the intention that these versions of SMS/QDOS Zip/UnZip will
follow the Info-ZIP rules, thus providing compatibility with the other
platforms. It is possible to zip the file structure described above on
SMS/QDOS and unpack it on VMS and get the VMS structure as shown in the
example (and vice-versa). [We only choose the most obtuse file
systems for the examples].

In order to achieve this, SMS/QDOS names are mapped into Unix-style
ones when the zipfile is created and un-mapped when it is unpacked.
There is an option to unpack in 'zipfile' format (i.e. with '.' rather
than '_'), but there will be no option to pack to all '_'. That would
contravene the standard.  However, a file

        src_split_name_c        (which is src->split_name_c !)
                                          src/split_name.c)

where src is a hard directory, would be stored in the zip directory as

      src/split_name.c

It does handle '_' with a little intelligence.

The default UnZip option will be to translate '.' to '_'; this is
because there are still many QDOS/Minerva users that cannot handle '.'
without quotes, which is immensely inconvenient. For many SMS users
'_' is also the most natural and convenient option. It also means that
SMS/QDOS <-> SMS/QDOS Zip - UnZip sequences are transparent.

There will, however, be two ways around this in UnZip.

      1. It is possible to Config the UnZip default to be '.'
         translations (or not).

      2.  The UnZip -Q1 option will toggle the default (Config'ed)
          state.

Examples:

Given that we want/have

     Makefile                   (Makefile)
     src/afile.c                (src_afile_c)
     src/bfile.c                (src_bfile_c)
     src/docs/prog.txt          (src_docs_prog_txt)
     hdr/cfile.h                (hdr_cfile_h)
     hdr/dfile.h                (hdr_dfile_h)

Then on SMS/QDOS we might have added the *.c files as

     ex zip;'-r test *_c'

(or VMS, just to do something different)

    zip -r test [.src]*.c

In both cases the file lists as above (left).

To unpack on SMS/QDOS (just the _c/.c files)

   ex unzip;'test src/*.c'

   (and VMS, unzip test src/*.c)

i.e. in both cases using the 'zipfile' format. As a concession to
SMS/QDOS, you could also have:

   ex unzip;'test src_*_c'

        but not unzip test [.src]*.c on VMS !!!!! Sorry, dinosaurs.

Both SMS/QDOS commands unpack to

     src_afile_c etc, where src_ is a hard sub-directory.

(and the VMS example would unpack to [.src]afile.c, (or to src\afile.c on
DOS/NT/OS2 etc).

Options & SMS/QDOS Features
---------------------------

The options supported by Zip/UnZip are basically those documented in
the Info-ZIP documents and shown in on-line 'usage'. In particular, -r
and -j work as intended.

PLEASE NOTE: Previous SMS/QDOS zip/unzips have NOT followed these
conventions, for example -r was not implemented and -j was reversed.

A number of -Q (SMS/QDOS-specific) options (not yet in the current
documents or usage screens) are implemented.

The Zip 2.0.1 (and later) default is to add SMS/QDOS headers where
file type = 1 (exe) or 2 (rel) or (type > 0 && != 255 and (filesize %
64) != 0). Directories are included anyway, unless you zip -D.

Where a header is added for an 'exe' file a '*' is displayed after the
name in the zip display  (and '#' for 'rel' files).

The -Q options for Zip are:

    -Q1  Don't add headers for ANY files
    -Q2  Add headers for all files
    -Q4  Don't wait for interactive key press

    (additive, so -Q5 => no headers, no wait, -Q6 all headers,
     no wait etc)

    (the default is exec/rel headers, 5 sec wait)

Zip has rationalised the file header storage in zipfiles. The
previous Zip used to store a QDOS header for each file. This was very
wasteful, for example compressing a SMS/QDOS release of PGP in this
way came to 730Kb, too large for a DD disk. Changing the Zip program
just to add a header record for the single PGP exe and the zipfile
size went down to around 690Kb.

And for UnZip

    -Q1 Toggle unpack format status ('.' <-> '_')
    -Q2 Toggle listing format
    -Q4 Don't wait for key press

Files Types
-----------

The history of QDOS suffers from incompatible feature
implementations. For example, Thor directories have file type 3, CST
have type 4 and Level 2 have type 255. Some software writers (both
amateur and otherwise) have used type 3 or 4 for other purposes
(backward compatibility ?? who cares ??).

In order to bypass problems cause by incompatible (inconsiderate ?)
usage of file types, the file type denoting a directory is a
Config'urable item. The default is set to -1 (65535 in Config terms),
which means "determine directory type from the file header of the root
directory". If this is appears unsuccessful on your system, the value
can be Config'ed in the range 3-255.

Zip assumes a file is a directory if:

        ((type == CONFIGed_type) && (file_size % 64) == 0)

If you are unfortunate enough have files of that pass this test but
are not directories, then Zip will loop endless, as SMS/QDOS opens the
root directory again !!! (recursion: see recursion etc).

I suggest you refrain from zipping such files and contact the software
supplier and point out the error of their ways.

File Naming Issues
------------------

Zip will append a '_zip' suffix to the archive filename when the
supplied name (i.e. excluding device/directory parts) does not
contain a '_' or a '.'. This is broadly compatible with Info-ZIP,
taking into account the '_' aberation.

So
        ex zip;'ram2_test ...'          >> ram2_test_zip

        ex zip;'ram2_test.zip ...'      >> ram2_test.zip

        ex zip;'ram2_test_rep ... '     >> ram2_test_rep

        ex zip;'ram2_fdbbs.rep ... '    >> ram2_fdbbs.rep

        ex zip;'ram2_test_rep.zip ...'  >> ram2_test_rep.zip

This implies that if a file ram2_test.zip exists, and you do:

        ex zip;'ram2_test ...'

Then a new file (test_zip) is created, rather than 'test.zip' being
updated.