MacBinary II

Macintosh Binary Transfer Format ("MacBinary II") Standard Proposal
These are the new changes to the MacBinary Standard, as generally agreed upon in the MacBinary II Conference 6/21/87, and as changed in the followup conference 6/28/87. Revised 7/24/87 to reflect suggestions and clarifications that came later, and to include all necessary information needed from the original MacBinary standard document to implement MacBinary II.

The new standard will be very similar to the original MacBinary standard as described in [MacBinary Standard]. (Reading the original standard is recommended for a full understanding of implementation and philosophy behind the MacBinary I and II formats.) The binary format consists of a 128-byte header containing all the information necessary to reproduce the document's directory entry on the receiving Macintosh; followed by the document's Data Fork (if it has one), padded with nulls to a multiple of 128 bytes (if necessary); followed by the document's Resource Fork (again, padded if necessary). The lengths of these forks (either or both of which may be zero) are contained in the header.

The format of the header for MacBinary II is as follows:

Offset

Length
Contents

000

Byte
old version number, must be kept at zero for compatibility

001

Byte
Length of filename (must be in the range 1-63)

002

1 to 63 Bytes
filename (only "length" bytes are significant).

065

Long Word
file type (normally expressed as four characters)

069

Long Word
file creator (normally expressed as four characters)

073

Byte
original Finder flags
Bit 7 - Locked.
Bit 6 - Invisible.
Bit 5 - Bundle.
Bit 4 - System.
Bit 3 - Bozo.
Bit 2 - Busy.
Bit 1 - Changed.
Bit 0 - Inited.

074

Byte
zero fill, must be zero for compatibility

075

Word
file's vertical position within its window.

077

Word
file's horizontal position within its window.

079

Word
file's window or folder ID.

081

Byte
"Protected" flag (in low order bit).

082

Byte
zero fill, must be zero for compatibility

083

Long Word
Data Fork length (bytes, zero if no Data Fork).

087

Long Word
Resource Fork length (bytes, zero if no R.F.).

091

Long Word
File's creation date

095

Long Word
File's "last modified" date.

099

Word
length of Get Info comment to be sent after the resource fork (if implemented, see below).

*101

Byte
Finder Flags, bits 0-7. (Bits 8-15 are already in byte 73)

*116

Long Word
Length of total files when packed files are unpacked. This is only used by programs that pack and unpack on the fly, mimicing a standalone utility such as PackIt. A program that is uploading a single file must zero this location when sending a file. Programs that do not unpack/uncompress files when downloading may ignore this value.

*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.

*122

Byte
Version number of Macbinary II that the uploading program is written for (the version begins at 129)

*123

Byte
Minimum MacBinary II version needed to read this file (start this value at 129

*124

Word
CRC of previous 124 bytes

*This is newly defined for MacBinary II.

All values are stored in normal 68000 order, with Most Significant Byte appearing first then the file. Any bytes in the header not defined above should be set to zero.

The original MacBinary format was ammended to include the sending of the FCMT (Get Info comment) after the resource fork was sent, if the length for such comment, given in offset 99, is not zero. To the best of our knowledge, no program has implemented this feature, due to Apple's stated position that no program should read or write these comments. The definition remains in MacBinary II, so that should Apple ever provide a documented way of reading and writing these comments, terminal programs will be able to take advantage of this feature.

   All Finder flags and information would be uploaded, however, a downloading program should clear the Finder flag bits of
   0 - Set if file/folder is on the desktop (Finder 5.0 and later)
   1 - bFOwnAppl (used internally)
   8 - Inited (seen by Finder)
   9 - Changed (used internally by Finder)
   10 - Busy (copied from File System busy bit)

Also, fdLocation and fdFldr should be zeroed

To determine if a header is a valid MacBinary header, check bytes 0 and 74 to be both zero. If they are both zero, either (a) the CRC should match, which means it is a MB II file, or (b) byte 82 is zero, which means it may be a MB I file. (Note that, at the current version level, byte 82 is kept zero to maintain compatibility with MacBinary I. If at some point the MacBinary versions change sufficiently that it is necessary to keep MacBinary I programs from downloading these files, we can change byte 82 to non-zero.)

If the header is a MB II header, the program will check the minimum version byte, to see if it knows enough to decode the file. If the minimum version in the header is greater than the version that the terminal program was written for, it will download the file as pure XModem (creating a "TEXT" file) and notify the user that conversion is needed because the MacBinary version was too high.

   If the header does NOT represent a valid MB II header, the program must at minimum check byte 82 to be zero--if it is not zero, the file is not a MB I file. It is possible to write a much more robust routine, by checking the following:
   Offsets 101-125, Byte, should all be 0.
   Offset 2, Byte, (the length of the file name) should be in the range of 1-63.
   Offsets 83 and 87, Long Word, (the length of the forks) should be in the range of 0-$007F FFFF.

   If any of these tests fail, the file is not a valid MacBinary file. It may still be desirable to distinguish between text files and foreign binary files (for stripping line feeds or similar helpful acts). Some tests that would prove useful include:
   A quantity of bytes in the first block with the high bit set would point to a binary file (though this could be fooled by files with many extended ascii characters, such as generated by the option key on a Mac).
   A large quantity of zero bytes (nulls) would also point to a binary file.

This proposal was adopted at two conferences attended by representatives from CompuServe, Delphi and BIX networks, and many terminal software publishers.

A partial list of those participating is:
   Peter Olson/ICONtac
   Larry Loeb/BIX
   Neil Shapiro/Maug
   Mark Hagerman
   Michael Pester
   William Bond
   Bill Steinberg
   Don Brown
   Bill Davis
   Jean Hess
   Scott Watson
   Clay Maeckel
   Harry Chesley
   Jack Brindle
   Raines/BMUG
   Harry Conover
   Chris Allen/Dreams of the Phoenix

Offset	Length	Contents
000	Byte	old version number, must be kept at zero for compatibility
001	Byte	Length of filename (must be in the range 1-63)
002	1 to 63 Bytes	filename (only "length" bytes are significant).
065	Long Word	file type (normally expressed as four characters)
069	Long Word	file creator (normally expressed as four characters)
073	Byte	original Finder flags Bit 7 - Locked. Bit 6 - Invisible. Bit 5 - Bundle. Bit 4 - System. Bit 3 - Bozo. Bit 2 - Busy. Bit 1 - Changed. Bit 0 - Inited.
074	Byte	zero fill, must be zero for compatibility
075	Word	file's vertical position within its window.
077	Word	file's horizontal position within its window.
079	Word	file's window or folder ID.
081	Byte	"Protected" flag (in low order bit).
082	Byte	zero fill, must be zero for compatibility
083	Long Word	Data Fork length (bytes, zero if no Data Fork).
087	Long Word	Resource Fork length (bytes, zero if no R.F.).
091	Long Word	File's creation date
095	Long Word	File's "last modified" date.
099	Word	length of Get Info comment to be sent after the resource fork (if implemented, see below).
*101	Byte	Finder Flags, bits 0-7. (Bits 8-15 are already in byte 73)
*116	Long Word	Length of total files when packed files are unpacked. This is only used by programs that pack and unpack on the fly, mimicing a standalone utility such as PackIt. A program that is uploading a single file must zero this location when sending a file. Programs that do not unpack/uncompress files when downloading may ignore this value.
*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.
*122	Byte	Version number of Macbinary II that the uploading program is written for (the version begins at 129)
*123	Byte	Minimum MacBinary II version needed to read this file (start this value at 129
*124	Word	CRC of previous 124 bytes