f0d81ffd1c
which included commits to RCS files with non-trunk default branches. git-svn-id: svn://10.65.10.50/trunk@5403 c028cbd2-c16b-5b4b-a496-9718f37d4682
600 lines
19 KiB
Plaintext
Executable File
600 lines
19 KiB
Plaintext
Executable File
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 zip file/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/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 'zip-file' (unix) format.
|
|
|
|
c. When files are added, they are defined in native format.
|
|
|
|
d. When files are added, this is shown in 'zip-file' format.
|
|
|
|
e. When files are unpacked, this is done to native format, but
|
|
selection is done in 'zip-file' 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 ZIP file 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 ZIP is created and un-mapped when it is unpacked. There
|
|
is a option to unpack in 'zip-file' 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 'zip-file' 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 God 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 ZIP files. 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 zip file
|
|
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.
|
|
|
|
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 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 (Jonathan.Hudson@jrhudson.demon.co.uk)
|
|
|
|
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 InfoZip 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.
|
|
|