[net.micro.mac] MacTerminal ? and how to disable the IW alert

nathan@reed.UUCP (Nathan Wilson) (07/12/85)

In the past I have always used the typical method of having the
present MacTerm document on the disk that is recieving the file.
However this last round of discussion on the topic brought an idea
into mind.  I remembered the reason that ':'s aren't allowed in
Mac file names.  Namely because the Mac interprets them as
Volume:Filename.  This can be rather unfortunate if you don't have
a disk named <Volume>, but it can also be useful as in this case.
I next looked at the man pages for macput and found a -n option
which supposedly renames the file that it sends.  I played with
this for a while and discovered fairly rapidly that it doesn't work
at all, even on the disk with the MacTerm document. (I tried both
the suggested syntax 'macput foo -n bar'  and 'macput -n bar foo'
both of which resulted in saving foo on the usual disk under the name
foo.  I then remembered that the names for foo had been generated
by xbin so maybe....  After finding the -n option of xbin, I
tried 'xbin -n OtherDisk:bar foo' this created the usual three forks
but with the names OtherDisk:bar.data etc.  I then tried
'macput OtherDisk:bar' and the disk with the MacTerm document whirred
then the other drive whirred and it deposited a functional version
of foo under the name of bar on OtherDisk!!!!!!!

I have since played with this method and discovered the following:

1)  It will work with large files (I used ResEdit).

2)  It will only work if there is enough space to recieve the file
on BOTH disks (ah, well there had to be a catch somewhere).

3)  It doesn't work to simply rename the files on the mainframe
after xbin'ing them.  (I was working on a VAX.)

4)  The Mac has to know about the disk your sending the file to
before you try sending it. (The easiest method that I found was to go
to Send File in the File menu, eject the present disk, insert the
destination disk and then cancel the send command.  It also works to
just put the disk in the external drive if you have one.)

and
5)  It works on a 128K, one drive mac and requires only two disk swaps
for a 96k document!!

End discovery one.

Discovery Two.
I only very rarely use the Print Selection... option in MacTerm
and would prefer to use the 24K of disk space that the imagewriter
takes up for other purposes.  However, I am also very annoyed by
the little dialog box that appears everytime I run MacTerm without
an imagewriter on it.  So I took out my hacking tools and got to 
work.  I first tried renaming the 0k clipboard file on my disk
Imagewriter which didn't work.  I then went in with ResEdit and
ripped out all the resources from the Imagewriter file.  This
resulted in 286 byte file, I then launched MacTerm and low and
behold now alert box!!!  Now I was curious what these 286 bytes were
and what there purpose was, also I wanted something that wasn't
named Imagewriter so that people wouldn't get confused.  Using FEdit
and IM I found out that all that was left was the bare minimum of a
resource fork. Interesting, what does MacTerm look for?  A file with
a resource fork and called Imagewriter?

I then tried another tack (due to a friends suggestion).
We opened up MacTerm to see if we could find the string Imagewriter
which quickly failed, then we went after the alert box itself.
After finding that the DITL 4196 had the offending string, we went
into ALRT 4196 and turned all the stage bits off (stg1boxDrawn etc.).
We then left ResEdit, threw out the Imagewriter and started up
MacTerm.  To our amazement this actually worked.  So I now have
a version of MacTerm that doesn't tell me about the fact that I don't
have an Imagewriter every time I start it up (a fact that has become
abundantly clear).  If I try to print with such a version it tells me
'-192 PrintCache:PrJobDialog failed..' a suitable hint as to what my
problem is.

	What other machine can you reprogram without the source, in under
30mins when you don't know what your looking for!!!

				-Nathan Wilson

					"The best things come in little pink boxes."