Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!thunder.mcrcim.mcgill.edu!snorkelwacker.mit.edu!think.com!zaphod.mps.ohio-state.edu!hobbes.physics.uiowa.edu!ns-mx!uunet!sugar!peter From: peter@Sugar.NeoSoft.com (Peter da Silva) Newsgroups: comp.sys.amiga.advocacy Subject: Re: De-macification of the Amiga (Re: The Amiga's Future) Message-ID: <1991Jun20.175529.21808@Sugar.NeoSoft.com> Date: 20 Jun 91 17:55:29 GMT References: <50849@ut-emx.uucp> <1991Jun20.005257.9400@sugar.hackercorp.com> <50885@ut-emx.uucp> Organization: Sugar Land Unix -- Houston, TX Lines: 28 In article <50885@ut-emx.uucp> awessels@ccwf.cc.utexas.edu (Allen Wessels) writes: > The file gets uploaded as a binary and downloaded into its component parts > by the Mac. The conversion is handled by the download protocol, i.e. > MacBinary. The host machine doesn't need to know about the resource fork, > although when I'm downloading BinHexed files from my Sun account, I use > mcvert to convert the BinHex file back to mac binary format. In other words, the data and resource forks are merged and stored in a mini-archive. Like I said, it's an alien format to everyone else. One of the many design decisions that make Macs a cute little world isolated from the mainstream of computers. > How does the application know what is in the file? It is easier to check a > 4 character file type resource than to read in some arbitrary number of bytes > of the file to figure out what is in it. No, it's exactly the same operation to read an IFF file header and to scan a resource fork for a file type. Except that the file "type" in the IFF header allows interchange with other systems.The factt hat IFF is defined in a system independent manner is yet another advantage... > Woo, such a substantive criticis I find the Mac use of resources pretty > useful. Useful, yes. But it could have been done without breaking interoperability. -- Peter da Silva. `-_-' . 'U` "Have you hugged your wolf today?"