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