Re: DOS 3.3 File Compression

["Jeff Blakeney" <jeff.blakeney@a2central.com.remove-nvz-this>]

  To: Doug McComber
On Thu, 4 Dec 2008 12:00:29 +0000, Doug McComber wrote:

> Hi,
> 
> I have a BBS (complete with a dedicated dial-up line at 902-252-1944) 
> that I am populating with Apple II software amongst others.  My goal with 
> this is for the software to be in a format that someone calling the BBS 
> from an actual Apple II (vice emulator on a PC) can use natively.
> 
> One method I'm using is ShrinkIt for files and disks.  But what should I 
> use if I want to compress a handful of DOS 3.3 files but not the whole 
> disk?

ShrinkIt
========

ShrinkIt is the standard 8 bit archiving tool for Apple IIs.

ShrinkIt only supports compressing a list of files if they are on a
ProDOS disk.  This is a file archive and has the extension SHK.

Files on disks using something other than ProDOS (ie. DOS 3.3, CP/M) can
only be archived by compressing the contents of the entire disk.  This
is a disk archive and has the extension SDK.  SDK archives can contain
ProDOS disk images as well, but they were usually frowned upon because a
file archive was usually smaller.  This brings up the point that when
creating disk archives, it was considered good practice to format a new
blank disk and copy only the files that were needed to it and compress
that disk.  This is because, when you delete a file from a disk, the
data sectors were usually left on the disk and only the directory entry
was altered so that left over data would get compressed as well.  Using
a virgin blank meant that all unused data sectors were all zeros instead
of containing data.  An added bonus was that copying the files to a
newly formatted disk basically defragmented the disk so all the data
would be grouped together as would all the empty sectors making the
compression more efficient.

Another note about disk archives is that they can contain more than one
disk image if you want.  This usually wasn't done due to the fact that,
back in the day, most Apple II users didn't have any large storage
devices and needed the files they downloaded to be able to fit on a
5.25" floppy.  Today, that may not be such a concern.  I know that I
personally have started grouping stuff together in large archives but
admittedly, that is mostly with disk images for emulators.  Why keep six
disk images or zip files of the System 6.0.1 install disks when you can
keep a single zip file with all six disk images in it.

Binary II
=========

This brings us to the sometimes controversial topic of Binary II
headers.  Most systems that made Apple II files available for download
adopted the Binary II header as standard for all files.  Most Apple II
communications programs support automatically adding and removing Binary
II headers so they are easy to use and I, personally, find them very
handy.  An SHK and SDK file with a Binary II header uses the extension
BXY.  By adding this header, you are storing the original archive's
name, type, creation date and a few other bits of information.  When the
Binary II header is removed after downloading, the archive will have
those pieces of information set.  By using this you can have a file
available for download with the name "Apple IIgs System Software
v6.0.1", which isn't a legal ProDOS name, but when the Binary II header
is removed it will have a file name of "System6.0.1" which is a legal
ProDOS name.  Using communications software that automatically removes
Binary II headers, you never need to worry about editing a filename that
you download to be ProDOS legal.

Just to let you know, you can actually put a bunch of files into a
single file with a Binary II header and it would have an extension of
BNY.  All the information about the files would be preserved as it was
moved from place to place and would be restored when the Binary II
header was removed.  This wasn't done much as there was no compression
used and compressing the files meant less storage requirements on the
servers and shorter transfer times.

Also, there are separate programs available for adding and removing
Binary II wrappers from files.  You don't need to rely solely on
communications software to do it.

GSHK
====

GSHK, aka ShrinkItGS is the standard 16 bit archiving tool.

GSHK supports more than just ShrinkIt archives but the other formats are
more to allow getting files from other platforms that use other
archiving systems.  I seem to recall a limitation that GSHK has over
ShrinkIt in dealing with certain archive but I can't remember what it is
at the moment, just that sometimes you had to use ShrinkIt because GSHK
wouldn't do it.

MacBinary
=========

On the IIgs, there is another header that is sometimes added but it was
actually created for the Mac.  MacBinary is supported by Spectrum and it
will allow you to put a header on extended files (files with resource
forks) which Binary II doesn't allow you to do (although I do remember
reading a document for a newer version of Binary II that would allow
it).  Using GSHK to compress the files takes care of the lack of
extended file support in Binary II so it was never much of an issue.  I
have no idea if MacBinary files have a default extension as I almost
never use them.

Summary
=======

To summarize, most Apple II files are available as Binary II wrapped
ShrinkIt archives with a BXY extension.  The ShrinkIt archive name is a
ProDOS legal filename but the Binary II wrapped file can have whatever
name is legal for the system it resides on.