Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!sun-barr!decwrl!shelby!csli!anderson
From: anderson@csli.Stanford.EDU (Steve Anderson)
Newsgroups: comp.sys.mac
Subject: White Knight and Zmodem
Keywords: White Knight ZTerm ZModem autoreceive
Message-ID: <11143@csli.Stanford.EDU>
Date: 26 Nov 89 20:00:35 GMT
Sender: anderson@csli.Stanford.EDU (Steve Anderson)
Organization: Center for the Study of Language and Information, Stanford U.
Lines: 89


I apologize for this further expenditure of net bandwidth on the
burning question of whether or not White Knight is capable of
autoreceiving ZModem file transfers, but there actually is a problem
and I hope someone can sort it out on the basis of a little more
information. 

In a recent posting to comp.sys.mac (as well as in a personal note to
me), Norm Goodger explains what WK expects a UN*X host running sz to
send as the message to initiate a ZModem file transfer:

norm>When I type sz filename (CR) on my unix system, it sends the following
norm>
norm>rz
norm>**B000000000000

(The "norm>" at the beginning of each line here is inserted so that
those of you reading this with WK won't see your macs go into
autoreceive mode - it's not something transmitted by sz!)

He goes on to say that when WK sees this string,

norm>WK instantly opens the file transfer dialog and begins downloading
norm>the file. I understand there are a variety of versions of Chuck's zmodem
norm>out there, we have 2.10 here, and I read a previous msg that someone had
norm>2.12 installed at their site. While I would assume that they should all
norm>work the same, perhaps this is not the case. 

Now in fact, those of us who have been complaining that WK won't
autoreceive ZModem transfers have reason to believe he is correct on at
least the first count, because (as a couple of postings have
indicated), our machines running WK go spontaneously (and
inappropriately) into autoreceive mode when reading Norm's message.

However, he is also correct in saying that perhaps not all zmodem
programs on UN*X hosts work the same. In fact, the most common version
of the rz/sz package to be found on these hosts is the one that
appeared some time ago in comp.sources.unix. That's version 1.34. I'm
currently using a slightly later version myself (1.44, dated 3/3/88),
but as far as this question is concerned it's the same as the widely
distributed 1.34.

The point is that when I issue an sz command on my Sun to initiate the
transfer of a small file, what gets sent is:

me>sz: 1 file 62976 bytes 1.3 minutes
me>**B00000000000000

(again, the line prefix "me>" is intended to keep those of you running
a communications program that recognizes THIS string from having
it go into a strange state while reading this message).

Notice the two differences: (a) "rz" vs."sz: (file transfer data)", and
(b) number of 0's (12 vs. 14).

Now ZTerm (0.8, 0.85) recognizes this string and goes into
autoreceivemode. On the other hand, I can read Norm's message with
ZTerm just fine, and the control sequence in it doesn't set off
autoreceive. This might be because either (a) ZTerm is smarter than WK
about when to look for a "receive ZModem transfer" command, though this
seems unlikely; or (b) the two programs are looking for different
commands, which seems the most reasonable explanation. I've been unable
to locate a copy of sz version 2.XX to see if it sends something that
ZTerm understands.

So the problem that has been widely reported would seem to come down to
the definition of the zmodem protocol (what string does a server send
to initiate a transfer?), and to the extent to which various mac
implementations (ZTerm and WK, in particular) are based on the same
definition. I have no idea where to look for the "official" standard,
just as I have no idea where to find a more recent version of sz. I
must also confess that I haven't spent enough time looking at the sz
sources to sort out exactly what constants are responsible for what it
sends. I hope someone else can add further clarification.

On another (related) note, I complained in a previous posting that when
I did get a ZModem transfer going, no "File Transfer Status" window
appeared. Norm pointed out in his message to me that various INITs that
muck with the WDEFs can cause this. I confirmed that it was WindChooser
that was causing the problem; when I replaced this with the recently
posted NeXT-color-wdef INIT, everything worked fine.

Steve Anderson
Cognitive Science Center
The Johns Hopkins University

anderson@sapir.cog.jhu.edu
anderson@cs.jhu.edu
anderson@csli.stanford.edu