Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10 5/3/83; site spice.cs.cmu.edu
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!think!harvard!seismo!rochester!pt.cs.cmu.edu!spice.cs.cmu.edu!tdn
From: tdn@spice.cs.cmu.edu (Thomas Newton)
Newsgroups: net.news,net.micro.mac,net.news.group
Subject: Re: Cleaning up net.sources.mac (mod.sources...)
Message-ID: <482@spice.cs.cmu.edu>
Date: Wed, 20-Nov-85 01:20:46 EST
Article-I.D.: spice.482
Posted: Wed Nov 20 01:20:46 1985
Date-Received: Sat, 23-Nov-85 00:17:27 EST
Organization: Carnegie-Mellon University, CS/RI
Lines: 50
Xref: watmath net.news:4395 net.micro.mac:3526 net.news.group:4645

>> I don't understand this.  What is the importance of uuencode in the
>> discussion.  Binhex is used for the mac, and an excellent decoder of
>> binhex was posted to the net. (xbin). In source.

> It's not very important... but it *is* supposed to be the standard binary
> transfer program for mail and news. It's not that big a deal, though I would
> prefer to be able to do *something* with this code.

Macintosh files are slightly different from files on most other machines . . .
they may contain both a data fork and a resource fork.  Sending an arbitrary
Mac file using uuencode would require posting *two* binaries, and would have
the disadvantages that:
    (a) there might be more requests for reposts (if the two forks
        were sent in separate messages)
    (b) downloading programs from the net would require the ability
        to do 8-bit binary transfers (currently, BinHexed files can
	be converted back to a set of binary files on a Unix machine
        for downloading using MacTerminal, etc. OR can be downloaded
	to a Mac as a text file and decoded there using BinHex)
I don't see why you should have any more problems decoding a BinHex file on
your Unix machine than you would have decoding a uuencode file.  In case you
missed the point of the original message, xbin is a program *that runs under
Unix* and that can decode BinHex files into their separate binary forks.

> The important point is
> that if you can post IBM-PC sources to the net, why can't you do the same for
> Macintosh sources?

Some Macintosh sources have been posted.  But the enormous number of different
Macintosh development systems coupled with the fact that there's no "official"
native development system for anything other than assembly language means that
unless a program's binaries are posted, many of the readers of net.sources.mac
will be unable to use it.  I think that with a few exceptions, the most useful
way to make programs, etc. available on net.sources.mac is to post both source
and binary form.  Two exceptions:

  1) Fonts and other resources which are usually created in binary form
  2) Macintosh versions of large programs for which source has been made
     available at some previous date.  In this case, it's appropriate to
     post the binary version of the program and perhaps the Mac-specific
     sources.  The example which I'm thinking of is Kermit; if there was
     a Macintosh version of hack, it would also fall under this category.

Note also that MacWrite documents are often sent in BinHex form to preserve
formatting information; this *is* "source" as far as Mac users are concerned
although it is the equivalent of "binaries" for everyone else.

                                        -- Thomas Newton
                                           Thomas.Newton@spice.cs.cmu.edu
					   ..!seismo!spice.cs.cmu.edu!tdn