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.