lamy@utai.UUCP (Jean-Francois Lamy) (01/16/86)
I have just downloaded RedRyder 7.0. Would some kind soul send me
the documentation (if any)? I have figured out most of the stuff by
myself, but the following are still mysterious
a) What does "Disable MacBinary format" do?
b) Is there a simple way to transfer a file as with xbin + macput +
MacTerminal, i.e. what you get after the transfer is directly
useable?
c) Does anybody have a working termcap entry?
--
Jean-Francois Lamy
Department of Computer Science, University of Toronto,
Departement d'informatique et de recherche operationnelle, U. de Montreal.
CSNet: lamy@toronto.csnet
UUCP: {utzoo,ihnp4,decwrl,uw-beaver}!utcsri!utai!lamy
CDN: lamy@iro.udem.cdn (lamy%iro.udem.cdn@ubc.csnet)tim@ism780c.UUCP (Tim Smith) (01/18/86)
In article <1170@utai.UUCP> lamy@utai.UUCP (Jean-Francois Lamy) writes: > >a) What does "Disable MacBinary format" do? > It causes RR to not check to see if incomming files are in MacBinary format ( see below ). >b) Is there a simple way to transfer a file as with xbin + macput + >MacTerminal, i.e. what you get after the transfer is directly >useable? Well, yes and no. There is a format, called MacBinary ( explained in the latest MacTutor, by the way ), for transfering and storing Macintosh files. There is a 128 byte header, which has the finder info, and some magic numbers, and then the two forks. If a terminal program supports this format, then it will check the data being recived when a file is transfered ( usually with xmodem or kermit ), and if the first 128 bytes looks like a MacBinary header, and do the same sort of thing Macterminal does with macput. This format will be supported by Macterminal 2.0 ( if it ever exists! :-) ). The current version of Macterminal, when it thinks it is talking to another mac, uses a modified xmodem protocol. It essentially does three xmodem transfers, one for the header, one for the data fork, and one for the resource fork. This is not compatable with any standard xmodem, and so will not work with other terminal emulators. In particular, it uses a different handshake at the start to get the transfer going. *sigh* Macput is designed to work with Macterminal. It knows about this funny version of xmodem. If you had a straight xmodem program on Unix ( or modified macput ), you should be able to construct a proper MacBinary file from the .info, .data, and .rsrc files that xbin produces. Kermit should work also. I tried going "cat foo.info foo.data foo.rsrc > file; kermit s file" but was never able to get it to fully work. RR would recognize that a MacBinary file was being transfered, but there was a disagreement about the length of the file. You are pretty much stuck with downloading the unxbined file, and using binhex on the Mac, or downloading from someplace like Compuserve, which uses straight xmodem. -- Tim Smith sdcrdcf!ism780c!tim || ima!ism780!tim || ihnp4!cithep!tim
tdn@spice.cs.cmu.edu (Thomas Newton) (01/19/86)
MacBinary is the protocol currently used on MAUG for transferring binary
files to/from a Macintosh. A MacBinary receive is triggered by doing an
XMODEM receive of a file that has certain magic numbers in several of the
bytes comprising the first packet. However, it is possible (though unlikely)
for a non-MacBinary file to have the same numbers in the same places. The
"Disable MacBinary format" option is thus useful when you are transferring
non-Mac binaries and don't want a MacBinary receive triggered by accident.
-- Thomas Newton
Thomas.Newton@spice.cs.cmu.edujimb@amdcad.UUCP (Jim Budler) (01/19/86)
In article <277@ism780c.UUCP> tim@ism780c.UUCP (Tim Smith) writes: >I tried going "cat foo.info foo.data foo.rsrc > file; kermit s file" >but was never able to get it to fully work. RR would recognize that >a MacBinary file was being transfered, but there was a disagreement >about the length of the file. Each of the two forks are to be null padded to a 128 byte boundary. So when you did "cat foo...." RR ate a chunk of the beginning of the rsrc fork into the data fork, truncated the data fork to it's reported length, and came up short for the rsrc fork. -- Jim Budler Advanced Micro Devices, Inc. (408) 749-5806 Usenet: {ucbvax,decwrl,ihnp4,allegra,intelca}!amdcad!jimb Compuserve: 72415,1200
espen@well.UUCP (Peter Espen) (01/20/86)
In article <1170@utai.UUCP>, lamy@utai.UUCP (Jean-Francois Lamy) writes: > I have just downloaded RedRyder 7.0. Would some kind soul send me > the documentation (if any)? I have figured out most of the stuff by > myself, but the following are still mysterious > > a) What does "Disable MacBinary format" do? > > b) Is there a simple way to transfer a file as with xbin + macput + > MacTerminal, i.e. what you get after the transfer is directly > useable? > > c) Does anybody have a working termcap entry? > -- > To answer question b. first...With Red Ryder, files that are in the .bin format can be Xmodem-ed or Kermit-ed straight to RR7.0. Red Ryder wil convert the .bin file being sent to it to an executable file on the fly, thus there is no need to use the macput scheme. Likewise with Red Ryder you can SEND an executable file to someone and Red Ryder will convert it to the .bin format on the fly. The 'Disable MacBinary format' disables this on the fly conversion. I don't have a working termcap with me, but I will find one and post it in a few days. Peter Espen
dafa@ihwpt.UUCP (David Fay) (01/21/86)
> The current version of Macterminal, when it thinks it is talking to > another mac, uses a modified xmodem protocol. It essentially does > three xmodem transfers, one for the header, one for the data fork, > and one for the resource fork. This is not compatable with any > standard xmodem, and so will not work with other terminal emulators. > In particular, it uses a different handshake at the start to get > the transfer going. *sigh* I used to think MacTerminal was just perverse in it's insistence on a nonstandard XMODEM protocol until a friend pointed out to me that MacTerminal protocol is "sender initiated" rather than "receiver initiated". What this means is that if I do a macput on the Unix end (the sender), I don't have to do anything on the Mac end (if it is running MacTerminal). This is a wonderful feature since it means I can easily download multiple files with no human intervention on the mac end. I can even call a Mac that is unattended but running MacTerminal and transfer files to my heart's content (or, more accurately, until the disk is full). Compare this to a MacBinary transfer as implemented in Red Ryder for example. Since MacBinary transfer uses standard XMODEM protocol, it is receiver initiated. This means that I have to do something on the Mac end first before the file transfer can take place. Thus I can't transfer multiple files without telling Red Ryder repeatedly to initiate the transfer. I realize that it can be probably be done with Service Procedures, but what a pain compared to MacTerminal. Even worse, if the user interface is poorly written, as it is on Red Ryder, I will even have to name the file before the transfer begins. This is stupid since the MacBinary format includes the name of the file, which will overide my name anyway. The correct way to do this, as suggested by Dennis Brothers, in his original MacBinary proposal, is to ask the user for a name at the end, not the beginning of the transfer, and only if it turns out that it wasn't a MacBinary transfer at all but a simple XMODEM transfer. By the way, MacTerminal 2.0 is out. My local dealer received his dealer copy today (Monday). MacTerminal 2.0 supports both MacTerminal and vanilla MacBinary transfers. It also apparently includes a menu selection for Saving Screen, which implies to me that the annoying default save has been turned into an option. David Fay ihnp4!ihexp!dafa -- -------------------- David Fay AT&T Bell Laboratories Naperville, IL 60566 ihnp4!ihexp!dafa
mlr0@bunny.UUCP (Martin Resnick) (01/22/86)
> > By the way, MacTerminal 2.0 is out. My local dealer received his dealer > copy today (Monday). MacTerminal 2.0 supports both MacTerminal > and vanilla MacBinary transfers. It also apparently includes a menu > selection for Saving Screen, which implies to me that the annoying > default save has been turned into an option. > What, if any, is the upgrade policy for MacTerminal??
tim@ism780c.UUCP (Tim Smith) (01/22/86)
I agree that a sender initiated protocol can be nice. But I think it should be done by having the sender send something that means "I am starting an xmodem ( or kermit, or whatever ) transfer", and then using a standard xmodem or kermit or whatever. Then if you have a terminal program that knows about this, it can receive the file automatically, and if you have one that doesn't, you can do a receive command manually ( or menuly :-) ). -- Tim Smith sdcrdcf!ism780c!tim || ima!ism780!tim || ihnp4!cithep!tim
jimb@amdcad.UUCP (Jim Budler) (01/25/86)
In article <298@ism780c.UUCP> tim@ism780c.UUCP (Tim Smith) writes: >I agree that a sender initiated protocol can be nice. But I think it >should be done by having the sender send something that means "I am >starting an xmodem ( or kermit, or whatever ) transfer", and then >using a standard xmodem or kermit or whatever. Then if you have a >terminal program that knows about this, it can receive the file >automatically, and if you have one that doesn't, you can do a receive >command manually ( or menuly :-) ). Correct me if I'm wrong, but isn't this what you get in MacTerminal when you select xmodem - other ( as opposed to Mac-to-Mac). -- Jim Budler Advanced Micro Devices, Inc. (408) 749-5806 Usenet: {ucbvax,decwrl,ihnp4,allegra,intelca}!amdcad!jimb Compuserve: 72415,1200
dafa@ihwpt.UUCP (David Fay) (01/25/86)
> What, if any, is the upgrade policy for MacTerminal 2.0??
MacTerminal owners can copy MacTerminal 2.0 at their dealers.
I have used MacTerminal 2.0 for several evenings now and have some
comments. I like several new features. It now does MacBinary
transfers in addition to MacTerminal as well as several flavors of XMODEM.
I was disappointed with the MacBinary transfer though, because you have to
select "Receive File" and provide a file name to start the transfer.
I was hoping they would handle the handshaking like they did with
MacTerminal transfers.
Another new feature is a speeded up cursor movement command. You can
still move the cursor with option-click, and the cursor still takes
the most circuitous route it can find. However, you can now use
command-option-click to get "straight line" movement across the screen.
Why didn't they do this in the first place?!?
You can finally shut off that notorious screen-save "feature". In
fact the default is now no-screen-save.
The only problem I've run into so far is that I can't get autodial
to work on my U.S.Robotics Courier 2400. The old MacTerminal would
autodial if I set modem to "other". That no longer works. Instead,
MacTerminal goes offhook when I select "Dial.." but as soon as it
hears dialtone, it puts the modem into transmit mode, which then
puts out carrier and never generates touchtones. Anyone got any
solutions for this one?
--
--------------------
David Fay
AT&T Bell Laboratories
Naperville, IL 60566
ihnp4!ihexp!dafadafa@ihwpt.UUCP (David Fay) (01/26/86)
> In article <298@ism780c.UUCP> tim@ism780c.UUCP (Tim Smith) writes: > >I agree that a sender initiated protocol can be nice. But I think it > >should be done by having the sender send something that means "I am > >starting an xmodem ( or kermit, or whatever ) transfer", and then > >using a standard xmodem or kermit or whatever. Then if you have a > >terminal program that knows about this, it can receive the file > >automatically, and if you have one that doesn't, you can do a receive > >command manually ( or menuly :-) ). > > Correct me if I'm wrong, but isn't this what you get in MacTerminal > when you select xmodem - other ( as opposed to Mac-to-Mac). No. When you select xmodem - other in MacTerminal, you are selecting a vanilla xmodem protocol, which is receiver initiated. You can tell, because selecting it (as opposed to xmodem - macterminal) activates the Receive File item under the File menu. In order for the transfer to take place, the receiving machine must send out a signal that it is ready to receive (which is what the program does when you select Receive File). The transfer then takes place with a normal xmodem protocol. Selecting xmodem - macterminal, on the other hand, puts MacTerminal in a mode in which it is constantly looking for an ESCAPE followed by an "a". If it gets one it immediately goes into receive file mode and the "thermometer" appears on the screen. This is what is called a sender initiated transfer. The receiving machine doesn't have to send anything out to initiate the transfer. What Tim Smith is proposing, and I think he is right on the mark, is that all transfers be sender initiated. A sender would precede the transfer with a signal identifying the type of transfer. The terminal program would constantly be looking for these signals. When it saw one, it would go into the appropriate mode. The facility for doing this is already built into MacTerminal and MacBinary transfers. MacTerminal transfers are initiated with "ESC a", as already mentioned, and MacBinary with "ESC b". It is a natural extension to initiate Kermit transfers with "ESC k" or some such. In fact I am told that Kermit, which I have never used, does sender initiated transfers so I assume it is already set up with a some kind of request-for-transfer signal. It is a mystery to me why authors of terminal programs have ignored the identifying signal of MacBinary. Dennis Brothers put it into the MacBinary proposal specifically so that MacBinary could be sender initiated. Yet no program to my knowledge takes advantage of it. A friend and I have been working on this stuff recently because we are setting up a Mac bulletin board running on a Unix machine. My friend will be sending out a new version of macput shortly that moves it in the direction that Tim Smith proposes. -- -------------------- David Fay AT&T Bell Laboratories Naperville, IL 60566 ihnp4!ihexp!dafa