infozip.smsqdos.readme

infozip2.2源码

     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 thing that

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

would just find the files in the sub directories, 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 zip file 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 "-DQL_ZIP", and get a
standard Linux ZIP 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 ZIP file 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 zip file.

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 zip file 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.

In the case of the 4Mb zip, with the SMS/QDOS 50Kb unzipsfx image
prepended, then the whole 4.05 Mb is loaded (if possible !!) into
memory, then the zip data part is still processed from disk !!

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

1. A program 'makesfx' will combine the unzipsfx image and a ZIP file
   to produce a sfx (self-extracting zip) file.

2. The unzipsfx program supports a SMS/QDOS specific option to tell
   itself where the image file was loaded from.

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 zip file of the required files

    ex zip;'ram1_test_zip *_c'

    # Now create the sfx file (ram2_test_sfx)
    # our unzipsfx images is in 'win1_bin'
    # the '>' is the standard Unix/'C' convention for redirection
    # of standard output.

    ex makesfx;'>ram2_test_sfx win1_bin_unzipsfx ram1_test_zip'

You can now unpack the _sfx file on any SMS/QDOS compatible
system. The files in the archive are unpacked to the current
directory. It is necessary to tell the sfx where it came from (sfx
files are _very_ philosophical); but it knows where it's going to.

      data_use win1_stuff
      ex ram2_test_sfx;'-Xram2_test_sfx'

	 -----> win1_stuff_*_c

If you fail to give the -Xfile_name option (no space after the 'X'),
then you will get the message:

unzipsfx: can't find myself! [unzip]

This is not indicative of failure to compress using the 'shrink'
algorithm !! Enough of the silly comments .....

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
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/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 documents "InfoZIP_SMSQDOS_ReadMe" 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.