🚀 go-pugleaf

Posting-Front-End: GNU Emacs 18.41.7 of Fri Aug 28 1987 on teknowledge-vaxc (berkeley-unix)


The latest version of MacKermit is 0.8(35).  I mailed a three-part
posting of the BinHex to the comp.binaries.mac address over a month
ago, and a "did this get there?" followup last week.  No response to
either, and it hasn't appeared in the comp.binaries.mac newsgroup.
I'm not sure what happened to it... perhaps the path to the newsgroup
moderator is broken somewhere (I mailed c/o wrl.dec.com, I believe).

The "mouse freezup" problem has been discussed before in this
newsgroup and/or Info-Mac.  As I recall, it can be triggered by damage
to the resource fork of an application file (or any other sort of file
that has the "bundle" bit set).  The finder attempts to locate the
bundle and icon of the file, and becomes seriously confused while
attempting to display the window within which the file exists.  One
way to identify the offending file is to use a program called
DeskCheck, which examines the icons, bundles, and other information in
all files on a particular volume and identifies those files whose
resources don't adhere to the standards.  You can probably find
DeskCheck in a comp.binaries.mac archive, or get a copy from a
friendly, well-stocked Mac BBS or user-group library.

As far as avoiding this problem: if you're downloading a MacBinary
file from a BBS or mainframe and the download aborts prematurely, or
if you run BinHex on an encoded file and the translation fails (CRC
error, premature end-of-file, etc.), you should use a desk accessory
such as Delete File or DeskTop to delete the resulting partially-build
Mac file ->before<- exiting back to the Finder... a partially-built
application file could have a munged resource fork, and cause the
Finder to enter a state of acute confusion when it tries to add the
file's bundle to the desktop file.