Date: Tue, 9 Feb 1993 15:37:11 +0800 
From: Peter N Lewis <peter@cujo.curtin.edu.au>
Subject: tech/macbinary2+specs.txt 

This is a priliminary specification of an extension to the MacBinary II 
Standard to allow MacBinary to incorporate a directory tree in a similar 
way to a unix tar file.  This is done by a fairly simple extension to 
the standard (which is documented seperately, and which you should be 
familiar with before reading this document).  This extension is implemented
by MacBinary II+ posted at the same time.

**** Cut here ****
MacBinary II+ Preliminary Specification

This is a priliminary specification of an extension to the MacBinary II 
Standard to allow MacBinary to incorporate a directory tree in a similar 
way to a unix tar file.  This is done by a fairly simple extension to 
the standard (which is documented seperately, and which you should be 
familiar with before reading this), basically, I defined a 128 byte 
block that marks the start of a folder, and another one that marks the 
end of the folder, and then set it up like this:

start block for folder "Folder1"
  file1 - standard macbinary format
  file2
  start block for "Folder2"
    file3
  end block
end block

While the end block doesn't actually need to contain any information, its 
format is similar to the header block for consistency.

Start Block:
  Offset 000-version 1 - this is incomptible with previous decoders.
  Offset 001-Byte, Length of foldername (must be in the range 1-63)
  Offset 002-1 to 63 chars, foldername (only "length" bytes are significant, 
             the rest should be zero).
  Offset 065-Long Word, file type - 'fold'
  Offset 069-Long Word, file creator - $FFFFFFFF
  Offset 073-Byte, original Finder flags of folder (high byte)
  Offset 074-Byte, zero fill, must be zero for compatibility
  Offset 075-Word, folder's vertical position within its window.
  Offset 077-Word, folder's horizontal position within its window.
  Offset 079-Word, folder's window or folder ID.
  Offset 081-Byte, "Protected" flag (in low order bit).
  Offset 082-Byte, zero fill, must be zero for compatibility
  Offset 083-Long Word, Data Fork length 0
  Offset 087-Long Word, Resource Fork length 0
  Offset 091-Long Word, Folder's creation date
  Offset 095-Long Word, Folder's "last modified" date.
  Offset 099-Word, length of Get Info comment to be sent after the resource
             fork (if implemented, see below).
 *Offset 101-Byte, Finder Flags, bits 0-7. (Bits 8-15 are already in byte 73)
 *Offset 116-Long Word, Length of total files when packed files are unpacked.
             This may be zero to avoid having to preparse the folder when
             creating the MacBinary file.
 *Offset 120-Word, Length of a secondary header.  If this is non-zero,
             Skip this many bytes (rounded up to the next multiple of 128)
             This is for future expansion only, when sending files with
             MacBinary, this word should be zero.
 *Offset 122-Byte, Version number of Macbinary II - 130
 *Offset 123-Byte, Minimum MacBinary II version needed to read this file - 130
 *Offset 124-Word, CRC of previous 124 bytes

NOTE: The secondary header length MAY be non-zero, and if so, the secondary 
header immediately follows the Start Block, padded to a multiple of 128 bytes 
as usual.

NOTE: The comment length MAY be non-zero, and if so, the comment immediately 
follows the Start Block or secondary header, padded to a multiple of 128 
bytes as usual.

End Block:
  Offset 000-version 1 - this is incomptible with previous decoders.
  Offset 065-Long Word, file type - 'fold'
  Offset 069-Long Word, file creator - $FFFFFFFE
 *Offset 116-Long Word, Length of total files when packed files are unpacked.
             This may be zero.
 *Offset 120-Word, Length of a secondary header.  If this is non-zero,
             Skip this many bytes (rounded up to the next multiple of 128)
             This is for future expansion only, when sending files with
             MacBinary, this word should be zero.
 *Offset 122-Byte, Version number of Macbinary II - 130
 *Offset 123-Byte, Minimum MacBinary II version needed to read this file - 130
 *Offset 124-Word, CRC of previous 124 bytes

NOTE: This block is static except for the total length field, which may be 
zero as well, in which case its totally static.

You should recognize the Start and End blocks by the version, file type and 
creator fields.  Decoders MUST NOT rely on ANY other fields in the End Block 
being valid.  Encoders MAY fill them out to look like a start block, or may 
zero-fill them.  Encoders SHOULD zero-fill any bytes not explicitly set - 
this applies to all header blocks and all padding.

All internal files should have version 0, MacBinary II version 129,129.

An extended MacBinary file MUST start with a Start Block.  Thus a 
MacBinary II+ file is either:
1) A MacBinary II file encoding a single file, OR
2) A MacBinary II+ file encoding a single folder.
**** Cut here ****