home *** CD-ROM | disk | FTP | other *** search
/ kermit.columbia.edu / kermit.columbia.edu.tar / kermit.columbia.edu / bin / msvv90sea.exe / MSBOOFLS.EXE / MSBMKB.BWR < prev    next >
Internet Message Format  |  1992-07-30  |  3KB
  1. Date: Tue, 22 Oct 91 14:08:09 EDT
  2. From: Charles Lasner <lasner@watsun.cc.columbia.edu>
  3. Subject: MSBMKB bug
  4.  
  5. When inputting a filename from a device specified (because it isn't on
  6. the log drive), the d: part appears in the name field in the .BOO file
  7. instead of merely the name as expected.
  8.  
  9. ------------------------------
  10.  
  11. Date: Thu Oct 10 1991 12:00:00 EDT
  12. From: Charles Lasner <lasner@watsun.cc.columbia.edu>
  13. Subject: Release of Additional Kermit-12 Utilities
  14.  
  15.     While quite popular in the MS-DOS world for file distribution purposes,
  16. .BOO format as originally designed has an inherent weakness that makes
  17. reliable use on OS/8 family systems impossible.  I have designed an
  18. extension to the format to make .BOO format sufficiently reliable to allow
  19. implementation of an encoder and decoder for OS/8 systems.
  20.  
  21.     The relevant problem with .BOO format has to do with file length
  22. anomalies that are a consequence of the format itself.  .BOO files either
  23. end on a repeat compression field or a complete three-byte data field
  24. expressed as four characters, each only six bits significant.  Should a
  25. file end with only one or two eight-bit data bytes, two or one additional
  26. null bytes will be appended to pad out the last data field.  This leads to
  27. files that are one or two bytes longer than intended.  At least this is the
  28. behavior on systems like MS-DOS which maintain a file byte count.  Note
  29. also that this problem can be cumulative in that repeated transmission
  30. between systems where the file is stored locally in some decoded form, and
  31. then encoded locally before transmission to another site, can cause the
  32. problem to worsen indefinitely.  (It has also been noted that widely
  33. distributed .BOO encoding programs exist on certain systems which exhibit
  34. defects such as erroneous appendage of additional null bytes onto the end
  35. of the file not indicated by the file's contents.  This is clearly a
  36. program bug and not an inherent problem with .BOO format design.)
  37.  
  38.     The method chosen to correct the existing .BOO anomaly is to append a
  39. correction field to the end of every file requiring it.  The basic
  40. correction unit is ~0 which means literally a repeat compression field with
  41. a count of zero.  This construct is ignored by most .BOO decoders because
  42. it contributes nothing to the file. (At the bare minimum, .BOO decoders
  43. should implement the robustness of ignoring this type of data.  It is
  44. conceivable that due to design error, a decoding program could "blow up"
  45. when encountering this data.  Imagine a file lengthened by 2^32 null bytes!
  46. The exact amount of extraneously generated null bytes would likely be
  47. 2^{how many bits wide are integers on the machine} or one less than that.)
  48.  
  49.     .BOO-encoded files may now contain either ~0 or ~0~0 at the end to
  50. indicate whether one or two bytes are to be "taken back" respectively.
  51. Tests on MSBPCT.BAS and MSBPCT.C as currently distributed by CUCCA indicate
  52. that these corrections are perfectly ignored, thus decoded files are
  53. erroneously inflated by one or two bytes.  This is the expected behavior of
  54. these older decoders.
  55.  
  56. ------------------------------
  57.