info-mac@uw-beaver (03/20/85)
From: Moderator John Mark Agosta <INFO-MAC-REQUEST@SUMEX-AIM.ARPA>
INFO-MAC Digest Monday, 18 Mar 1985 Volume 2 : Issue 17
Today's Topics:
New files
Re: Details of Binhex 4.0 HQX Format Wanted
Serial Driver at 1200 baud
Finder 3.0X review
Bananas (demo)
256K DRAM chips
MacDraw file format?
Request for cliptalk info.
----------------------------------------------------------------------
Date: Sat 16 Mar 85 19:54:30-PST
From: Gustavo Fernandez <FERNANDEZ@SU-SCORE.ARPA>
Subject: New files
The following files are now on INFO-MAC. All have been verified
reliable.
MacWrite42.HQX - The latest (and hopefully final) version of MacWrite.
Note that some dealers got a version 4.1 which was buggy. This
version
fixes "the last bug" as of 3/9/85
DA-PaintGrabber.HQX, DA-SkipFinder.HQX, DA-SetFile.HQX - 3 desk
accessories
downloaded from Compuserve.
Gus Fernandez
------------------------------
Date: 17 Mar 85 (Sun) 00:40:45 EST
From: Dave Johnson <ddj%brown.csnet@csnet-relay.arpa>
Subject: Re: Details of Binhex 4.0 HQX Format Wanted
I have reverse engineered most of the format, and am planning to
release a new version of xbin.c fairly soon, which will convert files
from binhex.{hex,hcx, and hqx} formats into the form macput expects.
xbin was developed under 4.2BSD Unix, though it should be reasonably
easy to port to other machines.
Here's an informal description of the HQX format as I understand it:
----- The first and last characters are each a ':'. After the first
':', the rest of the file is just string of 6 bit encoded characters.
All newlines and carriage returns are to be ignored.
The tricky part is that there are holes in the translation string so
you have to look up each file character to get its binary 6 bit value.
I found the string by looking at a hex dump of BinHex:
!"#$%&'()*+,-012345689@ABCDEFGHIJKLMNPQRSTUVXYZ[`abcdefhijklmpqr
I can't see how this aids or abets any kind of error recovery, but if
you ran into a char not in the list, you would know something's wrong
and give up.
There is some run length encoding, where the character to be repeated
is followed by a 0x90 byte then the repeat count. For example, ff9004
means repeat 0xff 4 times. The special case of a repeat count of zero
means it's not a run, but a literal 0x90. 2b9000 => 2b90.
Once you've turned the 6 bit chars into 8, you can parse the header.
The header format consists of a one byte name length, then the mac
file name, then a null. The rest of the header is 20 bytes long, and
contains the usual file type, creator/author, file flags, data and
resource lengths, and the two byte crc value for the header.
The data fork and resource fork contents follow in that order. There
is a two byte file crc at the end of each fork. If a fork is empty,
there will be no bytes of contents and the checksum will be two bytes
of zero.
So the decoded data between the first and last ':' looks like:
1 n 4 4 2 4 4 2 (length)
+-+---------+-+----+----+----+----+----+--+
|n| name... |0|TYPE|AUTH|FLAG|DLEN|RLEN|HC| (contents)
+-+---------+-+----+----+----+----+----+--+
DLEN 2 (length)
+--------------------------------------+--+
| DATA FORK |DC| (contents)
+--------------------------------------+--+
RLEN 2 (length)
+--------------------------------------+--+
| RESOURCE FORK |RC| (contents)
+--------------------------------------+--+
------
Dave Johnson
Brown University Computer Science
ddj%brown@csnet-relay.arpa
{ihnp4,ulysses,allegra,linus,decvax}!brunix!ddj
------------------------------
Date: Sun, 17 Mar 85 20:40:51 EST
From: engel@harvard.ARPA (Stephen Engel)
Subject: Serial Driver at 1200 baud
I heard talk over the net a while back about the ROM serial driver
being buggy at 1200 baud. Does anyone remember exactly what the
problem was? I will post any help I receive.
Steve
engel@harvard.arpa
------------------------------
Date: Sun 17 Mar 85 20:41:09-PST
From: Barry Eynon <EYNON@SU-SCORE.ARPA>
Subject: Finder 3.0X review
Some initial reactions to Finder 3.0X, which I've been trying out this
weekend:
Overall: Fantastic improvement in performance. I have a hard time
resisting putting it on all my disks. The "long pause" before spinning
the disk has disappeared in copying files, and disks eject much
quicker. Cleanups are blindlingly fast. Programs also boot noticeably
faster, and it seems like some programs even run a bit faster
(possibly due to new versions of some system resources added by the
"sfupdate" program that was on the disk). However, there are some
remaining problems I think should be cleaned up before this goes out
for general release (or gets burned into a ROM).
Specific comments (good and bad, no particular order):
1) The default disk has been changed, such that programs now will
assume you want to save files on the disk with the system folder,
rather than the disk with the application program. Since I run with
the system and finder on a RAM disk, I have to hit the Disk button
once or twice every time I want to open or save a file. I can't
particularly think why they would change this, and it should be
returned to the way it was previously.
2) The New Folder command is a nice feature to save screen space, as
all those Empty Folders can (and do) go away.
3) The Print Catalog (with Page Setup) option is a nice idea, but at
the moment it is useless, since it does not show the contents of
folders. Unless you have a great number of unorganized files on a
disk, it isn't any better than a dump of the window with
command-shift-4. A recursive listing would be much better.It would
also be nice to have such a listing appear in a window or a file, so
it could be edited to make disk labels.
4) The View By options are much improved, as small icons appear next
to the text listings, and can even be manipulated by clicking or
lassoing to open programs or rearrainge files.
5) The CleanUp algorithm, though fast, seems to have some instability
in how it handles icons which are below the bottom of the window.
Instead of the icons lining up in complete rows below the window, they
chase each other around in various combinations on the next few lines
below the window (fun to watch), and never seem to stabilize. This
should be fixed.
6) There are new options on the Special menu. I'm not sure what Set
Quick Quit means (perhaps the system will eject and reboot when the
program this is set for exits?), but the Shut Down function is very
useful (doing exactly what the Quick Eject & Reset desk accessory does
now).
7) Every time a window is closed and then reopened, the icons are
shifted way over to the left hand side of the window, even to the
extent of chopping off parts of even medium-long names. The algorithm
which decides if the scroll bars should be grey or not also apparently
ignores the lengths of the names of files, so there is no convenient
way to see the complete names without grabbing the icons and moving
them around. This is awkward. If name lengths are being ignored
because of speed considerations, then at the very least a larger left
margin must be left in the window.
8) If you throw away the Clipboard file, and then use the clipboard,
the newly created Clipboard file still does not have the proper icon
when you return to the desktop. This is only an asthetic annoyance,
but it should have been caught by now.
9) Something about the editing sequence for file names has changed,
such that clicking on the name field selects the icon and the whole
name, rather than selecting the icon and putting an insert mark into
the name. I'm not sure of the reason for this change, but it doesn't
decrease the probability of accidentally renaming files or disks if
the keyboard is bumped, and it seems more awkward if I want to edit
the name of a file to have to select the icon and then put the insert
in the name than previously. I would think that clicking the icon
should NOT select the name, and clicking the name should put down an
insert mark, as previously, which would reduce the renaming problem.
Well, there it is, both good and bad.I have not tested the new finder
with a hard drive, but even for those of us with lowly floppies, this
represents a considerable improvement in the utility of the Finder.
-Barry Eynon
------------------------------
Date: Tue, 12 Mar 85 23:11:51 pst
From: chavez%ucbcory@Berkeley (Thomas M. Chavez)
Subject: Bananas (demo)
Here is a fun little set of programs that a friend of mine created
recently. Many of you probably follow Bloom County in your local
paper, and know of Oliver Wendall Holmes and his Banana JR. PC 6000, a
mac look-a-like. Well, with a little help from the Resource Editor
(also on this board), he made a few changes to the system and finder
and voila! A Banana!
There are four files in all: banana.system.hqx, banana.finder.hqx,
banana.desktop.hqx, and banana.startup.hqx.
[ In info-mac the files are demo-banana-system.hqx
demo-banana-finder.hqx demo-banana-desktop.hqx demo-banana-startup.hqx
-jma ]
They take up about 220k, so you might want to do the transfer at night
to speed things up.
Any comments can be sent to me and I will pass them on to the creator,
or you can call him: his name is Dan Wood, and his phone is (415)
848-8560.
Have fun!
Tom Chavez chavez@cory.berkeley
------------------------------
Date: Mon 18 Mar 85 13:36:48-PST
From: J. Todd Bridges <B.BRI%LOTS-A%LOTS-A@SU-SCORE.ARPA>
Subject: 256K DRAM chips
Advertisement in the San Jose Mercury news of 18 March 85:
41256 - 150ns, min 100 pcs......$5.99
NEC, Fujitsu, Toshiba
Digital Innovations Corp. (408) 738-3893
No information is given regarding ordering procedure, handling or
shipping charges, etc. As usual, this is not an endorsement; merely a
report. On the phone, a salesman told me the qty 1 price would be
$9.00 and the qty 50 price would be $8.00. Note that one could upgrade
7 Macs with 112 chips, so maybe user groups will be interested.
Todd Bridges B.BRI%LOTS-A@SCORE.ARPA
------------------------------
Date: Mon 18 Mar 85 16:50:48-EST
From: LE.SO%MIT-EECS@MIT-MC.ARPA
Subject: MacDraw file format?
Does anyone know, or can give me a pointer to, the format of a MacDraw
file? I would like to write some routines that can examine and
manipulate one. Thanks in advance. ~Bosco~
------------------------------
Date: Mon, 18 Mar 85 15:16:06 EST
From: cadtroy!schoff@cadmus
Subject: Request for cliptalk info.
In DATA COMMUNICATIONS there was mention of a mac application called
cliptalk which transferred files across an appletalk between macs.
Does anyone have any details concerning this?
thanks,
marty {wanginst,seismo}!ucadmus!schoff schoff@cadmus.ARPA
------------------------------
End of INFO-MAC Digest
**********************