izreadme.sms

zip压缩

Zip supports extensive recursive wild-carding, again the fact that '_'
can be a directory separator as well as part of a file name makes this
a bit tricky, but given the example:

     test1_bas
     test2_bas
     dir1->demo1_bas            where -> indicates a sub dir
     dir2->demo2_bas

     ex zip;'ram2_test *_bas'
     just finds test1_bas, test2_bas

     ex zip;'-r ram2_test *_bas'
     recurses and finds all the files

You might think that

    ex zip;'-r ram2_test *_*_bas'

would just find the files in the subdirectories--well yes, but it will
also find very other sub-dir'ed _bas file on the disk too. This is
a feature.

The pattern matching supports Unix-style 'regex' so you could:

        ex zip;'ram2_test dir?_*_bas'
        or
        ex zip;'ram2_test dir[12]_*_bas


UnZip has now got a fixed -d option. This is used to specify the
directory to unpack the zipfile into, it must follow immediately
after the zip name.

        ex unzip;'ram2_test_zip -d ram3_ *_txt'

would unpack all *_txt files to ram3_ .

It is not necessary to set the default directory to pack files, Zip
will remove any device names (and store any hard directory names,
unless you zip -j).

        ex zip;'ram1_test flp1_*'

                ----->
                        adding: file.dat (deflated 50%)
                        adding: menu.rext # (deflated xx%)
                        adding: zip * (deflated yy%)
                        adding: hard_one (stored 0%)
                        adding: hard_one/stuff.bas (deflated ...)

Due to the way the file-mapping is implemented, it is not supported
over the nX_ type network device.

Config Options
--------------

A limited number of SMS/QDOS specific functions can be set using the
QJump Config program.

      For Zip:

      Timeout for interactive 'Press any key' prompt

       65535                  Wait forever      (aka -1)
       0                      No wait
       n (1-32767)            Wait for 'n' clocks (1/50 sec)

       Other values are unsupported. Note Config works on 'unsigned'
       integer values (at least according to my manual).

       Directory file type key.

       Config will accept any value in the range 3-255, known useful
       values are 3 (Thor), 4 (CST) and 255 (Level 2 devices). A value
       of 65535 (aka -1) means "determine from device info".

       For UnZip:

       Timeout as above

       Unpack mode (SMS/QOS ('_') or Info-ZIP ('.')

       List format (Info-ZIP ('.') or SMS/QDOS ('_')


When the 'Press a key' text is displayed, if you press ESC, then it
waits until you press any other key, infinite timeout. This may be
useful if you want (much) more time to study a listing etc.

Defaults for timeout and directory type are 250 and -1 respectively.

More Goodies
------------

Part of the Zip compression code is now in assembler; it runs
noticably faster than the previous version. Compressing some arbitrary
files with the previous Zip it took 251 seconds, with Zip 2.0.1 it
took (a mere) 170 seconds (68008 QL).

More good news is that SMS/QDOS is just another system option on top
of standard Info-ZIP, unlike the previous ports that were much more
SMS/QDOS specific. For example, compiling the standard source with c68
(i.e. #define QDOS), then you get an SMS/QDOS version.

Compile with Linux/gcc and get the standard Linux version. Now, here's
the cool bit; compile with Linux/gcc and "-DQLZIP", and get a standard
Linux Zip/UnZip with SMS/QDOS (header) extensions.

so, on Linux:

            zip -Q stuff.zip qtpi zip unzip

the -Q tells Zip to look for XTc68/Lux68 cross-compiler data size
blocks and produce a zipfile with SMS/QDOS headers in it (for exec
type programs). This works for exec files produced by the XTc68/Lux68
cross compilers and ANY SMS/QDOS files copied to a Unix or MS-DOS disk
from an SMS/QDOS floppy using 'qltools v2.2' (or later).

Self Extracting Archives
------------------------

Info-ZIP self-extracting archives (_sfx) are created in a rather
'brute-force' way. The UnZipSFX program is prepended to a zipfile.

i.e.          file_sfx = unzipsfx + file_zip
              ex file_sfx

Although the UnZipSFX program is a cut-down UnZip, it is still around
30Kb - 50Kb, depending on platform.

The success of this approach depends on how the operating system
loader loads executable files. On most systems where the loader only
loads the actual program part (Unix, VMS, DOS et al), the this is
quite efficient; if you make, say, a 4Mb zipfile and prepend a 30Kb
UnZipSFX image, then the system only loads the 30Kb program and the
process is efficient as the zipped data part is still unpacked from
disk. These systems also supply the running UnZipSFX program stub with
the path name of the file it was loaded from, so the program knows
what it has to unpack (so on Linux, for example):

     cat /usr/bin/unzipsfx test.zip > test.sfx  # concatenate the files
     chmod 755 test.sfx                         # make executable
     test.sfx                                   # to extract, it
                                                # 'knows' it is "test.sfx"

Unfortunately, the more simplistic nature of SMS/QDOS makes this much
more difficult and rather less efficient as: (see note 1)

     a. The SMS/QDOS 'loader' loads the whole file into memory.

     b. The SMS/DOS 'loader'/c68 run-time system does not return the
        name of the file from which it was loaded.

     c. You cannot so easily create a image file by concatenating two
        files, it is also necessary to ensure the executable file
        header is set correctly.

     d. The show stopper. The data space required for the
        self-extracting archive is required, as not easily maintained
        during electronic transfer.


If anyone is still interested, then the following support for UnZipSFX
is provided.

 o A program 'makesfx' will combine a stub (callstub), UnZipSFX image
   and a zipfile to produce a sfx (self-extracting zip) file.

 o A callable interface is supplied. The user calls the SFX file,
   which creates the files necessary to do the extraction.

The makesfx program concatenates the supplied files to standard
output.

So, to create a sfx of all the _c files in the default directory.

 # 1st create a zipfile of the required files

 ex zip;'ram1_test_zip *_c'

 # Now create the sfx file (ram2_test_sfx)
 # our UnZipSFX image is in 'win1_bin'
 # as is the call stub.

ex makesfx;'-o test_sfx -x win1_bin_unzipsfx -s win1_bin_callstub -z ram1_test_zip'

The arguments to makesfx are:

    -s stubfile
    -x UnZipSFX_program
    -z Zip_file
    -o Output_file

You can now unpack the _sfx file on any SMS/QDOS-compatible
system.

        f$ = "win2_tmp_test_sfx"
        a = alchp(flen(\f$))
        lbytes f$,a
        call a
        rechp(a)

ZipInfo
-------

Given the above note concerning SMS/QDOS programs not knowing the name
by which the program was invoked, then the usual symbolic-link-of-unzip-
to-zipinfo trick is unavailable (presupposing there is some some SMS/QDOS
trick to emulate symbolic links).

ZipInfo functionality is only available via 'unzip -Z'. There is no
separate ZipInfo program.

Caveat ATP Users
----------------

ATP for SMS/QDOS users should pay particular attention to the
Zip/UnZip options in their atprc and compare with Info-ZIP Zip/UnZip
usage. Older versions of Zip/UnZip screwed up -j.


        zip -jk
        unzip -jo

Distribution & Copyright
------------------------

This software is written by and largely copyrighted by the 'Info-ZIP'
group whose members are noted in the accompanying documentation. This
particular SMS/QDOS port plus 'makesfx' was written by, but is not
copyrighted by, Jonathan R Hudson. The SMS/QDOS code in this release
is written from scratch and is not dependent on previous SMS/QDOS
releases, but is (largely) compatible.

As a courtesy to the authors of this package, please ensure that the
documentation is supplied when it is re-distributed.

In particular, if this archive is split into Zip and UnZip components,
ensure that this document ("IZREADME_SMS") is supplied in
each component.

SMS/QDOS version by:
Jonathan R Hudson ([e-mail])

I am grateful to Graham Goodwin for finding some most imaginative
means of breaking the beta code.

I'd also like to thank Thierry Godefroy for providing the 2.1/5.2
source code and making the initial contact with the Info-ZIP group.

And of course, many, many thanks to the Info-ZIP workers for making
this code freely available.

Note 1
------

The 'C' language FAQ ('frequently asked questions' [comp.lang.c])
notes on the matter of obtaining the load file name of a 'C' program:

16.5:   How can my program discover the complete pathname to the
        executable file from which it was invoked?

A:      argv[0] may contain all or part of the pathname, or it may
        contain nothing.  You may be able to duplicate the command
        language interpreter's search path logic to locate the
        executable if the name in argv[0] is present but incomplete.
        However, there is no guaranteed or portable solution.
                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Note 2
------

NUL files for SMS2. There appears to be a conflict between SMS2/LBASIC
compiled programs and c68 programs using nul as stdin.

        EW zip,nul;'ram1_test *_bas'    # will not work

                                        # This does work !
        EW zip,#FOP_IN('nul');'ram2_test *_bas' : CLOSE

Note 3
------

version number incremented to 2.0.1a and 5.12a to accomodate Erling
Jacobsen's exit message requirements

version number incremented to Zip 2.0.1b to fix bug on zipping files
starting with leading underscore.

version number incremented to UnZip 5.12b to fix UnZip problem on
files zipped with leading './', and linked with revised (fixed) c68
'utime' function (could corrupt level 1 files). (source code _only_ as
IZQ004.zip).

Ported Zip 2.1 and UnZip 5.2 (July 1996). Released as INZIP005.zip

All later versions --- see Info-ZIP release notes and documentation.