DTR Flow Control

[lawson_whitney at juno.com]

On Mon, 25 Feb 2002, Michael Cardenas wrote:

>
> Attached is the relevant part of the output of +file,+comm.
>
> It looks like the app is using ClearCommError to check for the number of
> bytes recieved. I've read that the TIOCOUTQ ioctl is buggy and not very
> reliable, but I'm not sure if that's been fixed or not in newer kernels.
>
My comms apps have been banging on ClearCommError for that since August
1997, but without the overlapped nonsense.  It works for me or I
wouldn't have gotten your letter.  This app appears to ask for
rts/cts flow control - at least that is what we give it.  Dumb
question:  is there a modem cable or null-modem cable involved?  If so,
is it a good one, with wires for each signal (properly crossed for a
null-modem cable), or is it a 3 wire Windows cable?  Wine actually does
use (cause the serial driver to use) rts/cts flow control if the app
asks for it, and it won't work on a 3 wire cable.  I don't believe
Windows actually does hardware flow control at all, no matter what the
app asks for.

I don't really know the overlapped stuff too well, but I would expect
having an overlapped read going on would keep cbInQue at zero:  as soon
as there are bytes available, they get read.  Maybe Windows doesn't do
it that way.  Maybe we don't either.

Mike?

Lawson
---oof---