DTR Flow Control

[lawson_whitney at juno.com]

On Mon, 25 Feb 2002, Michael Cardenas wrote:

> Attached is the output of +relay,+file,+comm.
>
> It looks like ClearCommError is returning 20, which is "ERROR_BAD_UNIT",
> system cannot find the device specified. Shouldn't this be returning
> ERROR_IO_PENDING for overlapped io?
>
> I changed files/file.c to call SetLastError(ERROR_IO_PENDING) after the
> call to read(...) in the FD_TYPE_OVERLAPPED case instead of calling
> FILE_SetDosError, but that caused my app to not even be able to talk to
> the modem to get it to connect, so apparently that's not the problem.
>
May we see a

wine --version, please?

If I am not mistaken,

FIXME:pthread_rwlock_rdlock
FIXME:pthread_rwlock_unlock

went away 11 December 2001, and were absent from the Boxing Day FTP
release of Wine, which is already obsolete:

wine --version
Wine version 20020122

IIRC, you are using an external modem.  How do you know that it is
connected with a good modem cable?  That it works for Windows means
nothing.  I am reasonably sure Windows simply does not do hardware flow
control at all.  If it works for Linux pppd, I would have more
confidence in it, but I would still check every line with a voltmeter.
Also, the settings of the modem matter.  I have a no-name V.34 that does
what it calls "CTS flow control" by default.  It is essentially unusable
for Linux unless I give it an AT\Q3 to command it to use RTS/CTS flow
control, then it works fine.  Of course, any modem would probably have a
different AT command for that.  If CRTSCTS is set in the termios, Linux
does _strict_ RTS/CTS flow control.

If your modem works with Linux pppd, why would you even want to run a
Windows comms app?  8-D

I'm not convinced the GLE 20 is not a hangover from something that
happened before.

Lawson

Constants aren't, and variables won't.