Path: utzoo!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!samsung!zaphod.mps.ohio-state.edu!rpi!batcomputer!riley
From: riley@batcomputer.tn.cornell.edu (Daniel S. Riley)
Newsgroups: comp.sys.amiga
Subject: Re: Troubles with VT100
Message-ID: <9483@batcomputer.tn.cornell.edu>
Date: 31 Dec 89 00:10:34 GMT
References: <50143@bbn.COM>
Reply-To: riley@tcgould.tn.cornell.edu (Daniel S. Riley)
Organization: Cornell Theory Center, Cornell University, Ithaca NY
Lines: 25

In article <50143@bbn.COM> cosell@BBN.COM (Bernie Cosell) writes:
>How *do* you start and stop an ASCII send?  [as a side annoyance, somehow in
>the course of blundering around to try to turn OFF the ascii send so it'd ask
>me for a new filename, I managed to hit the CAPTURE menu item... well it didn't
>ask me for a filename either: it just used the same old filename... yup,
>trashing the file I was trying to upload...:-(].

There is a long standing "problem" in vt100's ASCII send code--when you
select ASCII send, it still waits for all the normal events that it usually
waits for.  The net result is that it doesn't start sending until it sees
an event (I think a mouse click will do).  With a full duplex connection,
one event will do, since the echoed characters keep the stream going (but
a few mouse clicks will speed it up).  With a half-duplex connection, this 
is a real problem.

My opinion is that vt100 should not wait at all in ASCII send--it should
just dump the data straight over the line.  I included a trivial change
to do this in a *big* list of bug fixes I sent Tony after 2.8 came out,
but I think my list must have been lost in the mail--none of my fixes 
appeared in vt100 2.9 (worst example:  vt100 is still doing a Wait() 
followed by a WaitIO() after every AbortIO()...the Wait() is redundant, 
and it *will* occasionally hang).

-Dan Riley (riley@tcgould.tn.cornell.edu, cornell!batcomputer!riley)
-Wilson Lab, Cornell University