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.

lawson_whitney@juno.com wrote:
On Fri, 22 Feb 2002, Michael Cardenas wrote:

Is DTR flow control supported?

I am not at all sure, because I don't know what it is.  Hardware flow
control as understood by the Linux C library is rts/cts flow control.
There's a comment in comm.c in SetCommState that says it's not, but
EscapeCommFunction has a SETDTR case and a CLRDTR case.

No necessary connection.  The app can manipulate those signals itself.
Flow control as I understand it is done by the modem and the OS to
prevent overrun of the FIFO and the OS's buffers, behind the app's back,
so to speak.

Below are the lines I'm talking about.

I'm working on an app that asks for DTR flow control and uses overlapped
IO when using a modem. It establishes a modem connection, but then it
can't send any data over the connection. I'm using an external modem on
a serial port.

Probably a logfile from

wine --debugmsg +file,+comm yourapp.exe 2>&1 | tee logfile

would mean more to me than excerpts from code I help maintain.  +relay
never hurts, except it takes so much space, but traces gzip pretty well.
I expect Mike McCormack, the other person who is willing to touch Wine
serial comms, will be along presently.

Lawson

---oof---


________________________________________________________________
GET INTERNET ACCESS FROM JUNO!
Juno offers FREE or PREMIUM Internet access for less!
Join Juno today!  For your FREE software, visit:
http://dl.www.juno.com/get/web/.