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---