Date: Tue, 22 Oct 91 14:08:09 EDT
From: Charles Lasner <lasner@watsun.cc.columbia.edu>
Subject: MSBMKB bug

When inputting a filename from a device specified (because it isn't on
the log drive), the d: part appears in the name field in the .BOO file
instead of merely the name as expected.

------------------------------

Date: Thu Oct 10 1991 12:00:00 EDT
From: Charles Lasner <lasner@watsun.cc.columbia.edu>
Subject: Release of Additional Kermit-12 Utilities

    While quite popular in the MS-DOS world for file distribution purposes,
.BOO format as originally designed has an inherent weakness that makes
reliable use on OS/8 family systems impossible.  I have designed an
extension to the format to make .BOO format sufficiently reliable to allow
implementation of an encoder and decoder for OS/8 systems.

    The relevant problem with .BOO format has to do with file length
anomalies that are a consequence of the format itself.  .BOO files either
end on a repeat compression field or a complete three-byte data field
expressed as four characters, each only six bits significant.  Should a
file end with only one or two eight-bit data bytes, two or one additional
null bytes will be appended to pad out the last data field.  This leads to
files that are one or two bytes longer than intended.  At least this is the
behavior on systems like MS-DOS which maintain a file byte count.  Note
also that this problem can be cumulative in that repeated transmission
between systems where the file is stored locally in some decoded form, and
then encoded locally before transmission to another site, can cause the
problem to worsen indefinitely.  (It has also been noted that widely
distributed .BOO encoding programs exist on certain systems which exhibit
defects such as erroneous appendage of additional null bytes onto the end
of the file not indicated by the file's contents.  This is clearly a
program bug and not an inherent problem with .BOO format design.)

    The method chosen to correct the existing .BOO anomaly is to append a
correction field to the end of every file requiring it.  The basic
correction unit is ~0 which means literally a repeat compression field with
a count of zero.  This construct is ignored by most .BOO decoders because
it contributes nothing to the file. (At the bare minimum, .BOO decoders
should implement the robustness of ignoring this type of data.  It is
conceivable that due to design error, a decoding program could "blow up"
when encountering this data.  Imagine a file lengthened by 2^32 null bytes!
The exact amount of extraneously generated null bytes would likely be
2^{how many bits wide are integers on the machine} or one less than that.)

    .BOO-encoded files may now contain either ~0 or ~0~0 at the end to
indicate whether one or two bytes are to be "taken back" respectively.
Tests on MSBPCT.BAS and MSBPCT.C as currently distributed by CUCCA indicate
that these corrections are perfectly ignored, thus decoded files are
erroneously inflated by one or two bytes.  This is the expected behavior of
these older decoders.

------------------------------