jimb@silvlis.com (Jim Budler) (01/23/91)
In article <1991Jan21.045022.9593@silvlis.com> I write: >In article <42005@nigel.ee.udel.edu> johnston@oscar.ccm.udel.edu writes: >>In article <1991Jan17.171813.19497@comp.vuw.ac.nz>, marder@rata.vuw.ac.nz >>(Stephen Marder) writes... > >BinHex 5.0 abandoned any attempt at binary to ASCII encoding because >it was no longer needed on the commercial networks. Yves proposed it >as a standard, and it was accepted by a committee composed of sysops >from several networks and terminal program vendors. > >This became MacBinary. Later it became MacBinary I, when a similar >committee voted on a downward compatible extension called MacBinary II. >New capability was mainly the addition of the new Finder flags in the >header introduced with MultiFinder. It didn't take long for someone to correct me 8^) First, Yves didn't propose the standard, he just did an implementation of it, BinHex 5. Second, I'm told the new Finder flags have nothing to do with Multifinder. Third, I'm told there was considerable more new capability than the Finder flags, including future expansion capabilities and header CRC, but I will stand by my use of the word "mainly" above. An expansion capability that is little used to date is hardly a main feature, even if it is desirable. That last one is my opinion. My correspondent works at a software company, and they may plan to use one of these expansion features. Therefore to them the existence of the feature is a main portion of the standard. 8^) jim -- __ __ / o / Jim Budler jimb@silvlis.com | Proud / / /\/\ /__ Silvar-Lisco, Inc. +1.408.991.6115 | MacIIsi /__/ / / / /__/ 703 E. Evelyn Ave. Sunnyvale, Ca. 94086 | owner
jackb (Jack Brindle) (01/23/91)
In article <1991Jan22.165727.2454@silvlis.com> jimb@silvlis.com (Jim Budler) writes: > >Second, I'm told the new Finder flags have nothing to do with Multifinder. > I believe this is correct. There was quite a bit of additional info that we were ignoring in the additional bits, such as where the icon was (desktop or folder), and a few other things. This info was added when HFS was released, way before MultiFinder. By the way, there was much discussion about where the additional byte of flags should be placed. The most logical was adjacent to the old flags. Unfortunately, this byte was also used as a MacBinary indicator. Thus, it was moved up to an unused area so we could maintain backwards compatibility. > >Third, I'm told there was considerable more new capability than >the Finder flags, including future expansion capabilities and header >CRC, but I will stand by my use of the word "mainly" above. An >expansion capability that is little used to date is hardly a main >feature, even if it is desirable. The CRC feature was a "biggie." A major problem with MacBinary I decoders was a tendency to "false" on some non-MacBinary files. 1-2-3 files were some of the worst. That protocol relied on three bytes being null. Thus, almost any file that had those three bytes null would be recognized as MacBinary. The newer version added detection information (look at the top of the header) that is now used to indicate MacBinary files. The CRC simply adds a degree of protection to make sure that this really is MacBinary. > >That last one is my opinion. My correspondent works at a software >company, and they may plan to use one of these expansion features. >Therefore to them the existence of the feature is a main portion >of the standard. 8^) Glad to see someone thinks we knew what we were doing :-). - Jack Brindle