DTR Flow Control

lawson_whitney at juno.com lawson_whitney at juno.com
Mon Feb 25 15:38:14 CST 2002

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.



More information about the wine-devel mailing list