home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Columbia Kermit
/
kermit.zip
/
old
/
ckermit4e
/
ckdsq.hlp
< prev
next >
Wrap
Text File
|
2020-01-01
|
4KB
|
108 lines
Included in this distribution of 'sq' and 'usq' are:
1) sq.1 - man page
2) sqcom.h - header file for sq and usq compilations
3) sq.h - header file for sq compilations
4) usq.h - header file for usq compilations
5) sq.c, tr1.c, tr2.c,
sqio.c, sqdebug.c - sources for sq
6) usq.c, utr.c - sources for usq
7) makesq, makeusq - 'make' files for sq and usq
8) README - this file
With the exception of providing 'make' files for Unix, Xenix, etc. systems,
I have not included compilation instructions for other compilers. The
only thing you need to know is which modules are linked with which programs.
To link 'sq', compile:
sq.c
tr1.c
tr2.c
sqio.c
and then link the four object files with your standard libraries to produce
the binary for 'sq'. If you need to debug 'sq', compile sqdebug.c, set the
DEBUG #define in tr2.c, recompile tr2.c, and relink the above four files
plus sqdebug.
To create 'usq', compile:
usq.c
utr.c
and then link the two object files with your standard libraries to produce
the binary for 'usq'.
There are two system-dependent #define's in sq.c which may need to be
modified. They are at the beginning of the source (after the large block
of comments), and are FNM_LEN and UNIX.
FNM_LEN should be set to the maximum length of a file name on the target
system.
UNIX should be defined for Unix or a derivative, and undefined (i.e.,
commented out) for CP/M, MP/M, MS-DOS, PC-DOS, or any system that
has separate file "names" and "types" (delimited by a period).
I have compiled and tested the code with the following compilers on
the following systems:
system "C" compiler Xenix (Altos 586)
system "C" compiler Unix BSD 4.2 (Vax 780)
system "C" compiler Zeus (Zilog Z8000)
Computer Innovations C86 PC-DOS (MS-DOS) (IBM PC, etc.)
Computer Innovations C86 CP/M-86 (Altos 586)
DeSmet C88 CP/M-86 (Altos 586)
Aztec C II CP/M-80 (CompuPro)
If some of the code looks funny (read: slow), remember that it has to be
portable accross all the above systems, and I get tired of too many
#define's. If you successfully port it to some system that requires
minor (but backwards compatible) changes, let me know, and I'll update
them into my sources, and make sure they still work on the above systems.
Oh, and also, for those of you who argue that compact and uncompact should
be used under Unix, consider the following:
1) These programs are compatible with the popular 'SQ' and 'USQ' programs
found on many bulletin board systems. Files squeezed by other programs
will always be unsqueezable by any version of 'usq'.
2) You have the sources yourself. PLEASE don't make changes which affect
the internal format of the squeezed file. This causes great portability
and compatibility headaches.
3) 'sq' and 'usq' are faster than compact/uncompact, and since they use
an adaptive Huffman coding, rather than a fixed one, they compress files
as well or better.
Notes for version 3.2:
Several files were modified to make all returns of form return (n), for the
DECUS C compiler on VAX/VMS. Other than adding parens and incrementing
revision number, there were no changes. This has been tested on the system "C"
compiler under Berkeley 4.2BSD [VAX 750].
-William Swan
Notes for version 3.3:
Modifications were made to sq.c and usq.c to allow compilation for DEC ULTRIX
and c/70 systems. Defines for these will be found near the beginning of the
files, as ULTRIX and C70, respectively. sqio.c was also modified for c.70,
but these changes should be universal (one assumption removed).
File names are now limited to 7-bit ASCII, after Ted Medin reported a problem
related to this. If this causes problems with any systems, let me know.
-William Swan {ihnp4,decvax, allegra,...}!uw-beaver!tikal!sigma!bill
This is an upgraded version of the CPM world sq/usq programs, posted to
usenet recently. I have verified that they produce the same squeezed files
as the version originally released on disk number 10, for my test case
anyway...
Compress still seems to be faster and better for general use.
-Fred
10-Jan-87