.D The PAK-It System (PAKItUp & UnPAKIt) 
File Compression Archive System
Version 1.0
January 6, 1993
Copyright 1992, 1993 The D-Group 

1.  INTRODUCTION	2
2.  LICENSING INFORMATION	3
3.  SOFTWARE INSTALLATION	3
4.  USING THE SYSTEM	4
4.1. PAKItUp4
4.2. UnPAKIt	5
5.  CHANGES IN THIS VERSION (SPRs fixed)	5
6.  PAK FILE SPECIFICATION	6

1.  INTRODUCTION
The PAK-It file compression and archive system is composed of two programs, PAKItUp and UnPAKIt.  PAKItUp provides a method to compress and store multiple files inside a single "PAKed" file.  UnPAKIt removes the files and expands them to their original size.
The system serves two purposes. The first is to allow you to save space on diskettes and hard disks for seldom used files.  The second is that it provides an archiving function by placing all of the compressed files into a single file that you specify.
This version uses Lempel-Ziv 13 bit (LZW13) compression for maximum overall average compression ratios.  The compression routines are written in assembly language for speed, and each file compressed is stored with a Cyclic Redundancy Check.  UnPAKIt checks the stored CRC against the uncompressed CRC to ensure the file was not corrupted in the compression, storage, or decompression processes.
When PAKItUp determines that a file is larger compressed than uncompressed, it will store it in it's uncompressed state in the PAK file.  This will usually only happen with files that are already compressed or if the file is very small.
Each of the compressed files is stored in the PAKed format sequentially in a PAK file. Each PAKed file is stored with a small header to identify it.  If, while reading the PAKed file, UnPAKIt reads what appears to be a bad header or data it will scan until it finds a valid header or reaches the end of file.  This way, even if one of the files gets corrupted, you don't loose all the files after it in the PAKed file.  This kind of thing can happen by some "geek" editing your PAK file, while in transmission over a modem, or through the failure of a sector on a disk.
There are many file compression utilities for MS-DOS and other systems.  The PAK-It system is not compatible with any that we know of, nor was this a consideration in it's design.  The filename lengths, and directory structures on CTOS prevent efficient use of the limited header structures designed for the MS-DOS compression systems.  Compatible versions of the PAK-It system may be available in the future for MS-DOS and OS/2 systems.  If you are running a BBS system, you should use the PAK‑It System for files destined for CTOS systems.  If you have files that are intended to be downloaded and used on non-CTOS systems, you should use an archive program common to the target system.
The last section of this manual documents the current PAK Header Specification.   This is inlcuded to assist you troubleshooting problems you may have with corrupted PAK files.
For information on using The PAK-It System commands and parameters, see USING THE SYSTEM.

2.  LICENSING INFORMATION
This version of the PAK-It System (1.x) is intended to be distributed with the B2X-BBS system, and may be freely used and distributed by owners of the B2X-BBS.  It may be placed on the BBS for downloading.  This is not PUBLIC DOMAIN software, nor has it ever been.  It simply has very comfortable licensing procedures.  This is to encourage file sharing, and make transferring related groups of files easier for the BBS users and system operator.
The D-Group disclaims any and all implied warranties, including warranties of merchantability and fitness for a particular purpose, and any warranty coverage for incidental or consequential damages.  
The PAK-It System (including PAKItUp and UnPAKIt) are Copyright (c) 1992, 1993 by The D-Group,  2834 Henley Road, Green Cove Springs, FL. 32043

3.  SOFTWARE INSTALLATION
How you install the PAK‑It system depends on how you got it.  If it's from The D-Group diskette, then there's a submit file and a standard installation can be performed using the Install command or the Installation Manager.  Or you can Submit to [fx]<sys>Install.sub (where is [fx] is the device name where the floppy disk is mounted).
If you got the system (or parts of it) from a BBS then you have several options depending on what you downloaded.  The two run files (if you want both PAKItUp and UnPAKIt) should be placed in the system directory.  The file PAKCmds.sub (if you downloaded it) will create the two commands on your system.  If you didn't download the submit file, you can very easily create the commands with the Command File Editor using the parameters shown below.  The command case for both is 00 (the default).
The diskette installation places two run files in the system directory and adds two commands.  The commands and their parameters are:
The parameters are described in detail with examples in the section titled USING THE SYSTEM.  The Run file for the command PAKItUp is [sys]<sys>PAKItUp.run.  The Run file for the command UnPAKIt is [sys]<sys>UnPAKIt.run.  
PAKItUp
  File list
	  PAK file
	  [Overwrite OK?]
	  [Confirm each?]
	  [Delete each?]
UnPAKIt
  PAK file
	  [Overwrite OK?]
	  [Confirm each?]
	  [List files only?]
	  [To current DIR only?]

4.  USING THE SYSTEM
The PAK-It System has two commands:  PAKItUp and UnPAKIt.  They are described in the two sections that follow.
4.1. PAKItUp
The PAKItUp command compresses files into a single file called a PAK file. For consistency and ease of identification we recommend you name these files with the .PAK suffix.  For instance, if you are compressing several old Word Processor files, a name like OldWPFiles.PAK would be recommended.  
PAKItUp has five parameters. Two are mandatory (the File list and the PAK file name) and the other three are optional. They're explained below the example of the command form:
PAKItUp
  File list         *.DOC
	  PAK file          BusinessDocs.PAK
	  [Overwrite OK?]
	  [Confirm each?]   Yes
	  [Delete each?]    Yes
File list -- The file list parameter let's you specify which files will be PAK into the PAK file.  Standard filename expansion is provided by the executive.  Full expanded filenames from the parameter line are saved with the PAK file.  This means you can UnPAK the files to the directories they came from (See the UnPAKIt command for other options).
PAK file -- This is the name of the file that all of the files will be PAKed into. If the file exists, you will be prompted to see if you want to overwrite it unless you have specified YES to Overwrite OK (the next parameter).  If no file exists with that name, a new file is created.  We recommend you name the file with the .PAK suffix, but it is not required, nor does the program default to this extension if left off.
[Overwrite OK?] -- This forces the program to overwrite an existing PAK file if one exists with the name you provided.  
[Confirm each?] -- If you have specified a list of files for the File list parameter, this lets you determine one at a time whether or not to include them in the PAK file.
[Delete each?] -- Specifying YES for this parameter will delete each of the files in the "File list" after it is PAKed.
When you specify a file list in CTOS you can use a directory name or even a wildcard for the directory (such as <SYS>*.msg).  In this case, the parameter line will be expanded to include the directory name with each file.  This means the directory name will be included with each archived file in the PAK file.  This can help or hinder you in what you are trying to do.  For instance, if you want to PAK up several files from your system directory and you specify <SYS> in front of the filenames, then when the PAK file is UnPAKed, these files will automatically be placed in the system directory.  The UnPAKIt command has an option to allow the user to strip off the directory name (and node/volume name if they were also included) so the user can UnPAK all the files into the current path.  This version of the UnPAKIt command will NOT create directories. It will simply skip the files that specify a directory that doesn't exist. 

4.2. UnPAKIt
The UnPAKIt command decompresses files found in a PAK file. 
UnPAKIt has five parameters. One is mandatory (the PAK file name) while the other four are optional. They're explained below the example of the command form:
UnPAKIt
  PAK file                OldWPFiles.PAK
	  [Overwrite OK?]
	  [Confirm each?]         Yes
	  [List files only?]
	  [To current DIR only?]
PAK file -- This is the name of a PAK file that was created with PAKItUp.  If the file doesn't exist, or UnPAKIt determines it isn't a PAK file, you will exit with an appropriate error.  Even though we recommend you use the .PAK suffix with files created by PAKItUp, it is not required. UnPAKIt does NOT automatically append the .PAK suffix to the file.  
[Overwrite OK?] -- Specifying Yes (or just Y) forces the program to overwrite files it finds with the same names as those being UnPAKed.  The default is NO (as with all optional CTOS parameters).
[Confirm each?] -- Specifying YES (or just Y) will let you decide which files to UnPAK one at a time.  Each file is listed and you are prompted to press GO to UnPAK it or Cancel to skip it.
[List file only?] -- Specifying YES (or just Y) will list all of the files in the PAK archive file.  The list includes the full filename as it was PAKed, The uncompressed size, the compressed size (as stored in the PAK file) and the compression type.
[To current DIR only?] -- Specifying YES (or just Y) will UnPAK all the files into the current directory no matter what filespec it was PAKed up with.  If you PAKed files from several directories this can lead to some confusion  (but no real problem).  Some of those files may have the same names.  If you haven't also specified YES to Overwrite OK, then you will be prompted before you overwrite anything.

5.  CHANGES IN THIS VERSION (SPRs fixed)
This is the first version of The PAK-It System made available.  There are no known problems with this release.
Problems with the software may be reported in writing to:
The D-Group 
2834 Henley Road
		Green Cove Springs, FL 
		32043
We will respond to the problem report and let you know if there is a fix in a new version, or if there is a work-around.  This can only be done with correspondence (and as time permits).

6.  PAK FILE SPECIFICATION
PAK-It File Archive and Compression System 
Header Format Specification Version 1.0
Copyright 1992, 1993 The D-Group 
INTRODUCTION
This specification describes the PAK-It System basic file format including the header system.  The PAK-It system compresses files to save disk space and collects them into a single file for archive and purposes.  This specification is independent of the compression methods used in the PAK-It system, but allows for their identification.
DESIGN RATIONALE
The newest UnPAKIt utilities should be able to read (and usually unpak) the oldest PAK files in existence.  If they can't unpak them, they will be able to indicate to you exactly what the problem is.  Likewise, old UnPAK utilities will be able to read and determine if they can UnPAK a file or not, and let you know why they can't (e.g., Unknown compression format). To accomplish this, a system to make the header independent of a fixed size or format was necessary.  This was accomplished by using a TAGED header format.  This is similar to the Tagged Image File Format (TIFF) header, except not as complicated.  The TIFF TAGs allowed each tag to specify the size and type of an item.  This was not necessary or desirable for the PAK implementation.  Instead, the range of values for the TAGs indicate the lengths of data that they introduce.  This was done to save as much space in the header as possible. Remember, we ARE trying to compress things.  
FILE STRUCTURE
The PAK file format is very simple, yet allows for future expansion and improvement and complete backwards compatibility.  A PAK Archive file consists of one or more compressed files stored sequentially into a single file.  Each of the files in the compressed file is preceded by a PAK Header.
   Header, Compressed File, 
   Header, Compressed File, 
	   Header, Compressed File, ... End Of File
HEADER LAYOUT and SIGNATURE
The PAK header consists of the 3 byte SIGNATURE "TSG" (54h, 53h, 47h), followed by each of the tagged pieces of information.  The last piece of tagged information is the single byte FFh (255 decimal), which indicates the end of the header.  The file data in it's compressed format immediately follows this byte.  The TSG was chosen because these letters (TSG) do not represent a common sequence of instructions (binary values) on Intel processors, nor do they appear together in text to often.  They MUST be capitalized.

TAG DESCRIPTION
A TAG is a single byte that tells you what piece of information follows it.
TAGs are single bytes from 80h to FFh (high bit is always set) and FFh is reserved for the TAG that signifies the end of the header.  The tagged fields of the header are always stored in numeric order (See NOTE 3).
Tag values:

	   80h to 8Fh are followed by ONE byte   (16 possible tags).

	   90h to AFh are followed by TWO bytes  (32 possible tags).

	   B0h to DFh are followed by FOUR bytes (48 possible tags).

	   E0h to FEh are followed by a single byte that is the size of a string that follows the byte. The string may contain NULL value bytes (31 possible tags).

	   FFh is reserved and must be the last byte of the header.
ASSIGNED TAG VALUES AND RESERVED TAGS
The description of each of the predefined tags is listed below.  Those not defined or listed as RESERVED may be used for private extensions to the specification.  Tags listed as MANDATORY must be present in the header for the decompressor utility to function. Those listed as optional may be present, but it is up to the decompressing utility to use them or ignore them.
80h  --  Version.  MANDATORY.  A single byte will follow this tag indicating the version of the this specification used to write the utility. This is the MAJOR version number. If it were version 2.0. This byte value number would 2. If it were 3.4, then this byte value would be 3.  Minor version numbers will only be issued for changes that do not affect the fields of the specification. This included typographical corrections.
     Example 80h 02h
81h  --  Compression Type. MANDATORY.  This is a single byte indicating the type of compression used on the file. Legal values (known as of this writing) are:
     0 - None (Written as read, uncompressed, byte aligned)
     1 - LZW13 (Most common, used in PakItUp 1.x)
	     2 - LZW12
	     3 - HuffMan as documented in TIFF 5.0 Spec
	     4 - RLE (Simple Run Length Encoding)
	     5 - Packbit as documented in TIFF 5.0 Spec (a la Mac)
	     6 - 20 RESERVED
    Example 81h 01h

82h  --  RESERVED
83h  --  RESERVED
84h  --  RESERVED
85h  --  RESERVED
90h  --  CRC16 Value. MANDATORY. (Mutually exclusive to all other error check tags. See Note 1). This is a two byte value that contains a 16 bit Cyclic Redundancy Check value for the uncompressed file.  If this TAG is included in the header, other error check tags such as should NOT be.  The CRC16 is the most common type found in current PAK files.  This is the error check type used in the PAK-It system version 1.x.
91h  --  RESERVED
92h  --  RESERVED
93h  --  RESERVED
94h  --  RESERVED
B0h  --  Original File Size. MANDATORY.  A 4 byte unsigned number that is the size of the file in bytes before any compression.  The uncompressed file should be exactly this size when UnPAKed to disk.  
    Example: B0 00 02 00 00 (512 bytes uncompressed) 
    (See NOTE 2)
B1h  --  Compressed File Size. MANDATORY.  A 4 byte unsigned number that is the size of the file in bytes as stored in the PAK file.  If the UnPAKing programing were to skip this file, it would read in this number of bytes to reach the next header signature if it existed.  This size will match the Original File Size (TAG 83h) if the compression type is 0 (uncompressed).
    Example: B1 FF 00 00 00  (255 bytes compressed) 
    (See NOTE 2)
B2h  --  RESERVED
B3h  --  RESERVED
B4h  --  RESERVED
B5h  --  RESERVED
B6h  --  RESERVED
B7h  --  RESERVED

B8h  --  RESERVED
B9h  --  RESERVED
C0h  --  CRC32 Value. MANDATORY. (Mutually exclusive to all other error check tags. See Note 1). This is a four byte value that contains a 32 bit Cyclic Redundancy Check value for the uncompressed file.  If this TAG is included in the header, other error check tags should NOT be.
C1h  --  RESERVED
C2h  --  RESERVED
C3h  --  RESERVED
C4h -- File Creation Date in CTOS Format. OPTIONAL. This is a four byte tag that is the time of the files creation as listed in the CTOS fileheader.
C5h -- File Last Mod Date in CTOS Format. OPTIONAL. This is a a four byte tag that is the time of the files creation as listed in the CTOS fileheader.
C6h  --  RESERVED
C7h  --  RESERVED
C8h  --  RESERVED
C9h  --  RESERVED
E0h  --  RESERVED
E1h  --  RESERVED
E2h  --  RESERVED
E3h  --  RESERVED
E4h  --  RESERVED
F0h -- Comment. OPTIONAL. This is a comment field.  It is usually only included with the first compressed file of a PAK file and is intended to describe the PAK files contents (Obviously up to a maximum of 255 bytes).
FEh -- File Name.  MANDATORY.  This is the filename that this header represents.  This is described with a single byte value containing the size of the file name string, followed by exactly as many bytes. This limits filename (with complete file specifications to 255 bytes).
  EXAMPLES: 90h 0Ah 'MyFile.txt' (10 bytes in the name)
            90h 0Fh '<sys>Config.sys' (15 bytes in the name)

FFh --  End of Header. MANDATORY. The exact number of compressed bytes as listed in tag B1h follow this byte.
NOTES:
NOTE 1. The Error Check TAGS are mutually exclusive. ONE of them must be included, but ONLY one.  The presence of one of them indicates the type of error checking bytes stored after the tag.  This should the Error Check value acquired on the uncompressed bytes of the file.
NOTE 2. All single, two, and four byte tags that represent numeric values are stored in Intel bit and byte order format.  There is no option for any other format.
NOTE 3. The TAGS should be in numeric order.  This adds a measure of protection (however small) against attempting to read a header that isn't one at all.
NOTE 4.  Mandatory Header overhead size (shown with example):

SIGNATURE  3   TSG
Version    2   80h 01h
	CompType   2   81h 01h
	CRC        3   90h xxh  xxh (Using 16 bit CRC)
	OrigSize   5   B0 00h 00h 01h 00h 
	CompSize   5   B1 00h 80h 00h 00h
	Fname      2+  'FileName' 
	EOH        1   FFh

	Total =  23 plus filename string
END OF SPECIFICATION DOCUMENT