Macintosh Binary Transfer Format ("MacBinary III") Standard Proposal
These are the new changes to the MacBinary Standard, as generally agreed upon in December of 1996. This document includes all necessary information needed from the original MacBinary and MacBinary II standard documents to implement MacBinary III.

   The new standard will be very similar to the MacBinary II standard as described in [MacBinary II Standard]. (Reading the original MacBinary and MacBinary II standard documents are recommended for a full understanding of implementation and philosophy behind the MacBinary I, II and III 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 III 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-31)
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 - isAlias. Bit 6 - isInvisible. Bit 5 - hasBundle. Bit 4 - nameLocked. Bit 3 - isStationery. Bit 2 - hasCustomIcon. Bit 1 - reserved. Bit 0 - hasBeenInited.
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) Bit 7 - hasNoInits Bit 6 - isShared Bit 5 - requiresSwitchLaunch Bit 4 - ColorReserved Bits 1-3 - color Bit 0 - isOnDesk
*102	Long Word	signature for indentification purposes ('mBIN')
*106	Byte	script of file name (from the fdScript field of an fxInfo record)
*107	Byte	extended Finder flags (from the fdXFlags field of an fxInfo record)
108-115		Unused (must be zeroed by creators, must be ignored by readers)
116	Long Word	Length of total files when packed files are unpacked. As of the writing of this document, this field has never been used.
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 III that the uploading program is written for (the version is 130 for MacBinary III)
123	Byte	Minimum MacBinary version needed to read this file (set this value at 129 for backwards compatibility with MacBinary II)
124	Word	CRC of previous 124 bytes

*These fields have changed for MacBinary III.

   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 (in MacBinary II) to include the sending of the "Get Info comment" after the resource fork was sent, if the length for such comment, given in offset 99, is not zero. Prior to the release of System 7, there was no approved API for access to this information and so most existing implemenations of MacBinary II will not include this. However you may find some modern implemenations of MacBinary II which do include it now that it is possible to do so. Although not required, it is recommend that MacBinary III supporting applications read and write this information.

   To determine if a header is a valid MacBinary header, first take advantage of the new MacBinary III signature located at offset 102. If it matches, then you know that this is a valid MacBinary III header and can continue as such including the restoration of the new extended Finder info.

   If it is not a MacBinary III header, start by checking bytes 0 and 74 - they should both be zero. If they are both zero, either (a) the CRC should match, which means it is a MacBinary II file, or (b) byte 82 is zero, which means it may be a MacBinary 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 MacBinary II header, the program will check the minimum version byte (offset 123), to see if it knows enough to decode the file. If the minimum version in the header is greater than the version that the program was written for, it will download the file as raw binary. The program may also choose to notify the user that conversion is needed because the MacBinary version was too high.

   If the header does NOT represent a valid MacBinary II header, the program must at minimum check byte 82 to be zero--if it is not zero, the file is not a MacBinary 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.

  In November of 1996, Apple made it known to developers that a version of Finder due out in 1997 would begin using the extended Finder information (FXInfo - additional Finder related information originally introduced with the Hierarchical File System (HFS) in System 3.0/Finder 5.0 but not actually used to any extent until now). These changes are indeed present in Finder 8.0, which is part of Mac OS 8 (code named "Tempo").

   This proposal was drafted by as a result of a series of EMail discussions concerning the need for a Macintosh binary transfer format that stores the extended Finder information. The group decided that rather than creating a new format, or adopting another exsting format that users were unfamiliar with and that wasn't as well supported by application developers (such as AppleSingle), that a simple (backwards compatible) change to the existing MacBinary II specification would suffice.

Those participating in the discussions included:

Leonard Rosenthol	Aladdin Systems	leonardr@aladdinsys.com
Victor Tan	Aladdin Systems	victor@aladdinsys.com
Ed Tecot	Apple Computer/Microsoft	tecot@cs.stanford.edu
Patrick McClaughry	Apple Computer	patmc@apple.com
Quinn	Apple Computer	quinn@quinn.echidna.id.au
James W. Matthews	Dartmouth University	James.W.Matthews@Dartmouth.EDU
Amanda Walker	Intercon Systems/Ascend	amanda_walker@ascend.com
Alex Hopmann	Microsoft	hopmann@holonet.net
John Norstad	Northwestern University	j-norstad@nwu.edu
Pete Resnick	Qualcomm	presnick@qualcomm.com
Steve Dorner	Qualcomm	sdorner@qualcomm.com
Chuck Shotton	Quarterdeck	chuck@starnine.com
Peter N Lewis	Stairways Software	peter@stairways.com.au