Re: DTR Flow Control
On Sun, 3 Mar 2002 00:42:39 -0500 (EST), you wrote:
>
> Oops, I guess that was not the way to do it. Could you try this
> instead:
>
> diff -ur was/dlls/kernel/comm.c is/dlls/kernel/comm.c
> --- was/dlls/kernel/comm.cFri Mar 1 15:19:45 2002
> +++ is/dlls/kernel/comm.c Sun Mar 3 00:37:11 2002
> @@ -1248,6 +1248,7 @@
> {
> case 0:
> lpdcb->Parity = NOPARITY;
> + lpdcb->fParity = FALSE;
> break;
> case PARENB:
> lpdcb->Parity = EVENPARITY;
>
>
>
Beware, it is possible for serial communication to have parity in one
direction only. My banking program uses parity when it sends data, but
there is no parity on the received characters. It is the opposite of
the case that is handled here, but the (il)logic is the same.
Rein.
--
Rein Klazes
[EMAIL PROTECTED]
Re: DTR Flow Control
On Thu, 28 Feb 2002, Michael Cardenas wrote:
> The parts of the source I'm using are not very different from yours.
>
> I picked up the latest source and tried the app and it still has the same
> behavior. It can talk to the modem enough to get it to connect to the ppp
> server, but it cannot communicate over the network.
>
> I've attached a trace using my app with the latest source. The application
> seems to be stuck waiting for data and using ClearCommError to check the
> number of bytes received. It calls GetOverlappedResult along with
> GetLastError to check when the pending io operation has completed.
>
> Maybe there's something wrong with the way overlapped io is implemented when
> it interacts with a serial port. The documentation calls for the user to
> manually set the file pointer when using overlappedio, which doesn't seem
> like it would work on a serial port. The set_file_pointer function in
> server.c doesn't check for serial ports, but I'm not familiar enough with
> serial communications under linux to know if it matters. I tried to disable
> set_file_pointer for serial ports, but this didn't seem to have any effect.
>
> michael
Oops, I guess that was not the way to do it. Could you try this
instead:
diff -ur was/dlls/kernel/comm.c is/dlls/kernel/comm.c
--- was/dlls/kernel/comm.c Fri Mar 1 15:19:45 2002
+++ is/dlls/kernel/comm.c Sun Mar 3 00:37:11 2002
@@ -1248,6 +1248,7 @@
{
case 0:
lpdcb->Parity = NOPARITY;
+ lpdcb->fParity = FALSE;
break;
case PARENB:
lpdcb->Parity = EVENPARITY;
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/.;
Re: DTR Flow Control
On Thu, 28 Feb 2002, Michael Cardenas wrote:
> The parts of the source I'm using are not very different from yours.
>
> I picked up the latest source and tried the app and it still has the same
> behavior. It can talk to the modem enough to get it to connect to the ppp
> server, but it cannot communicate over the network.
>
> I've attached a trace using my app with the latest source. The application
> seems to be stuck waiting for data and using ClearCommError to check the
> number of bytes received. It calls GetOverlappedResult along with
> GetLastError to check when the pending io operation has completed.
>
> Maybe there's something wrong with the way overlapped io is implemented when
> it interacts with a serial port. The documentation calls for the user to
> manually set the file pointer when using overlappedio, which doesn't seem
> like it would work on a serial port. The set_file_pointer function in
> server.c doesn't check for serial ports, but I'm not familiar enough with
> serial communications under linux to know if it matters. I tried to disable
> set_file_pointer for serial ports, but this didn't seem to have any effect.
>
That doesn't make much sense to me. I can't see why a comm port should
be lseekable, if that is what you mean. I don't much trust Microsoft
doco either. The app doesn't seem to be doing set_file_pointer on the
modem either.
> michael
I don't know about that yet, but it seems to me that GetCommState is
incorrectly creating lpdcb with fParity - if that is indeed what it is
and the structure and names are correct, and then the dumb app is just
using it. Could you try it this helps?
diff -ur was/dlls/kernel/comm.c is/dlls/kernel/comm.c
--- was/dlls/kernel/comm.c Fri Mar 1 15:19:45 2002
+++ is/dlls/kernel/comm.c Sat Mar 2 23:22:09 2002
@@ -1235,19 +1235,17 @@
default:
ERR("unknown size %x \n",port.c_cflag & CSIZE);
}
-
-if(port.c_iflag & INPCK)
-lpdcb->fParity = TRUE;
-else
-lpdcb->fParity = FALSE;
+
#ifdef CMSPAR
switch (port.c_cflag & (PARENB | PARODD | CMSPAR))
#else
switch (port.c_cflag & (PARENB | PARODD))
#endif
{
+lpdcb->fParity = TRUE;
case 0:
lpdcb->Parity = NOPARITY;
+lpdcb->fParity = FALSE;
break;
case PARENB:
lpdcb->Parity = EVENPARITY;
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/.;
Re: DTR Flow Control
On Thu, Feb 28, 2002 at 06:42:28AM -0800, Michael Cardenas wrote: > The parts of the source I'm using are not very different from yours. > > I picked up the latest source and tried the app and it still has the same > behavior. It can talk to the modem enough to get it to connect to the ppp > server, but it cannot communicate over the network. > > I've attached a trace using my app with the latest source. The application > seems to be stuck waiting for data and using ClearCommError to check the > number of bytes received. It calls GetOverlappedResult along with > GetLastError to check when the pending io operation has completed. > > Maybe there's something wrong with the way overlapped io is implemented when > it interacts with a serial port. The documentation calls for the user to > manually set the file pointer when using overlappedio, which doesn't seem > like it would work on a serial port. The set_file_pointer function in > server.c doesn't check for serial ports, but I'm not familiar enough with > serial communications under linux to know if it matters. I tried to disable > set_file_pointer for serial ports, but this didn't seem to have any effect. Just for the record: I've also got some program which uses overlapped transmission and which also doesn't work (some NEC 78K uController demo kit). -- Andreas MohrStauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604http://home.nexgo.de/andi.mohr/
Re: DTR Flow Control
The parts of the source I'm using are not very different from yours. I picked up the latest source and tried the app and it still has the same behavior. It can talk to the modem enough to get it to connect to the ppp server, but it cannot communicate over the network. I've attached a trace using my app with the latest source. The application seems to be stuck waiting for data and using ClearCommError to check the number of bytes received. It calls GetOverlappedResult along with GetLastError to check when the pending io operation has completed. Maybe there's something wrong with the way overlapped io is implemented when it interacts with a serial port. The documentation calls for the user to manually set the file pointer when using overlappedio, which doesn't seem like it would work on a serial port. The set_file_pointer function in server.c doesn't check for serial ports, but I'm not familiar enough with serial communications under linux to know if it matters. I tried to disable set_file_pointer for serial ports, but this didn't seem to have any effect. michael - Original Message - From: "Mike McCormack" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Monday, February 25, 2002 6:37 PM Subject: Re: DTR Flow Control > How about showing us the source you are using, so we can help you > debug it? winehqtrace.tgz Description: application/compressed
Re: DTR Flow Control
Original message from: [EMAIL PROTECTED] > >On Mon, 25 Feb 2002, Michael Cardenas wrote: > >> Attached is the output of +relay,+file,+comm. .. >May we see a > >wine --version, please? Michael, How about showing us the source you are using, so we can help you debug it? thanks in advance ;-) Mike -- mailto:[EMAIL PROTECTED] ph +82 16 430 0425 __ Get your free Australian email account at http://www.Looksmart.com.au
Re: DTR Flow Control
On 2002.02.25 16:38 [EMAIL PROTECTED] wrote: > 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. > Hmm.. I am pretty sure that Windows 9x and NT do use RTS/CTS flow control. The standard win3.11 drivers don't IIRC, but 95 and above and NT always do if you have the hardware flow control radio box checked in the properties for the modem (and the app doesn't override it itself). [SNIP] One thing I would like to mention is that I think almost all Gateway 2000 486 computers have an incorrectly wired 25-pin serial port. DTR is not on the correct pin on the 25-pin D connector but is on the correct pin on the 10pin connector that is on the motherboard (which to my knowledge is the same for almost every motherboard that uses this type of serial connection). If you upgraded the motherboard in one of these old cases and did not use the new serial ports that came with the new mobo this may cause you some trouble. Fortunately my USR v.Everything has a DIP switch setting to turn off DTR control. The downside is that with DTR turned off you cannot just drop DTR to hang up but must instead use +++ATH. Fortunately I got rid of that 486 board many computers ago. (Un)fortunately I no longer use the v.Everything modem for much since I have a cable modem. It's almost a shame too, it's a really nice modem, connects with everything under the sun. -Dave
Re: DTR Flow Control
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.
Re: DTR Flow Control
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---
Re: DTR Flow Control
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. 08d06170:Call kernel32.CreateFileA(41f4f34c "COM1",c000,,,0003,4080,) ret=6c11415d trace:file:CreateFileA COM1 GENERIC_READ GENERIC_WRITE OPEN_EXISTING FILE_FLAG_OVERLAPPED attributes 0x4080 trace:file:CreateFileA opening device 'COM1' trace:file:DOSFS_CreateCommPort COM1 c000 4080 trace:file:CreateFileA returning 0328 08d06170:Ret kernel32.CreateFileA() retval=0328 ret=6c11415d 08d06170:Call kernel32.SetupComm(0328,5f38,2000) ret=6c1144eb fixme:comm:SetupComm insize 24376 outsize 8192 unimplemented stub 08d06170:Ret kernel32.SetupComm() retval=0001 ret=6c1144eb 08d06170:Call kernel32.GetCommState(0328,443e6e6c) ret=6c114503 trace:comm:GetCommState handle 808, ptr 0x443e6e6c trace:comm:GetCommState OK trace:comm:GetCommState bytesize 8 baudrate 115200 fParity 1 Parity 0 stopbits 1 trace:comm:GetCommState ~IXON ~IXOFF trace:comm:GetCommState CRTSCTS 08d06170:Ret kernel32.GetCommState() retval=0001 ret=6c114503 08d06170:Call kernel32.SetCommState(0328,443e6e6c) ret=6c114565 trace:comm:SetCommState handle 808, ptr 0x443e6e6c trace:comm:SetCommState bytesize 8 baudrate 115200 fParity 1 Parity 0 stopbits 1 trace:comm:SetCommState ~IXON ~IXOFF trace:comm:SetCommState CRTSCTS 08d06170:Ret kernel32.SetCommState() retval=0001 ret=6c114565 08d06170:Call kernel32.SetCommTimeouts(0328,443e6ea0) ret=6c1141ca trace:comm:SetCommTimeouts (328,0x443e6ea0) 08d06170:Ret kernel32.SetCommTimeouts() retval=0001 ret=6c1141ca 08d06170:Call kernel32.PurgeComm(0328,000f) ret=6c1141f2 trace:comm:PurgeComm handle 808, flags f 08d06170:Ret kernel32.PurgeComm() retval=0001 ret=6c1141f2 08d06170:Call kernel32.EscapeCommFunction(0328,0005) ret=6c114224 trace:comm:EscapeCommFunction handle 808, function=5 trace:comm:EscapeCommFunction SETDTR 08d06170:Ret kernel32.EscapeCommFunction() retval=0001 ret=6c114224 08d06170:Call kernel32.CreateEventA(41f51260,0001,,) ret=6c111bfc 08d06170:Ret kernel32.CreateEventA() retval=032c ret=6c111bfc 08d06170:Call kernel32.CreateThread(,,78002432,41f511f0,,443e6e8c) ret=78002426 08b947e0:Ret kernel32.CreateThread() retval=0320 ret=78002426 08b947e0:Call kernel32.Sleep(0001) ret=6c1106ce 08b947e0:Ret kernel32.Sleep() retval=0102 ret=6c1106ce 08b947e0:Call kernel32.Sleep(0001) ret=6c1106ce 08b947e0:Ret kernel32.Sleep() retval=0102 ret=6c1106ce 08b947e0:Call user32.PeekMessageA(405b620c,,,,0003) ret=60f0119b 08b947e0:Ret user32.PeekMessageA() retval=0001 ret=60f0119b 08b947e0:Call user32.TranslateMessage(405b620c) ret=60f011b4 08b947e0:Ret user32.TranslateMessage() retval= ret=60f011b4 08b947e0:Call user32.DispatchMessageA(405b620c) ret=60f011ba 08b947e0:Call window proc 0x60f05450 (hwnd=0001002a,msg=WM_USER+04d8,wp=,lp=) 08b947e0:Call kernel32._llseek(0108,00430e24,) ret=60f0f86e trace:file:SetFilePointer handle 264 offset 4394532 high 0 origin 0 08b947e0:Ret kernel32._llseek() retval=00430e24 ret=60f0f86e 08b947e0:Call kernel32._hread(0108,405b5eac,001a) ret=60f0f883 trace:file:ReadFile 264 0x405b5eac 26 0x405b5db4 (nil) 08b947e0:Ret kernel32._hread() retval=001a ret=60f0f883 08b947e0:Call kernel32._llseek(0108,00430e3e,) ret=60f0f027 trace:file:SetFilePointer handle 264 offset 4394558 high 0 origin 0 08b947e0:Ret kernel32._llseek() retval=00430e3e ret=60f0f027 08b947e0:Call kernel32._hread(0108,41f511a0,0040) ret=60f0f048 trace:file:ReadFile 264 0x41f511a0 64 0x405b5dd4 (nil) 08b947e0:Ret kernel32._hread() retval=0040 ret=60f0f048 08d06360:Starting thread (entryproc=0x78002432) 08d06360:Call PE DLL (proc=0xbfe21038,module=bfe2,type=2,res=(nil)) 08d06360:Ret PE DLL (proc=0xbfe21038,module=bfe2,type=2,res=(nil)) retval=1 08d06360:Call PE DLL (proc=0x40839b80,module=40829000,type=2,res=(nil)) 08d06360:Ret PE DLL (proc=0x40839b80,module=40829000,type=2,res=(nil)) retval=1 08d06360:Call PE DLL (proc=0x4079f7d0,module=40791000,type=2,res=(nil)) 08d06360:Ret PE DLL (proc=0x4079f7d0,module=40791000,type=2,res=(nil)) retval=1 08d06360:Call PE DLL (proc=0x40a90350,module=40a82000,type=2,res=(nil)) 08d06360:Ret PE DLL (proc=0x40a90350,module=40a82000,type=2,res=(nil)) retval=1 08d06360:Call PE DLL (proc=0x40682b1c,module=4065a000,type=2,res=(nil)) 08d06360:Ret PE DLL (proc=0x40682b1c,
Re: DTR Flow Control
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. [EMAIL PROTECTED] wrote: [EMAIL PROTECTED]"> 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 flowcontrol 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, butEscapeCommFunction 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 toprevent 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 overlappedIO when using a modem. It establishes a modem connection, but then itcan't send any data over the connection. I'm using an external modem ona serial port. Probably a logfile fromwine --debugmsg +file,+comm yourapp.exe 2>&1 | tee logfilewould mean more to me than excerpts from code I help maintain. +relaynever hurts, except it takes so much space, but traces gzip pretty well.I expect Mike McCormack, the other person who is willing to touch Wineserial 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/. trace:file:CreateFileA COM1 GENERIC_READ GENERIC_WRITE OPEN_EXISTING FILE_FLAG_OVERLAPPED attributes 0x4080 trace:file:CreateFileA opening device 'COM1' trace:file:DOSFS_CreateCommPort COM1 c000 4080 trace:file:CreateFileA returning 032c fixme:comm:SetupComm insize 24376 outsize 8192 unimplemented stub trace:comm:GetCommState handle 812, ptr 0x443e6e6c trace:comm:GetCommState OK trace:comm:GetCommState bytesize 8 baudrate 9600 fParity 0 Parity 0 stopbits 1 trace:comm:GetCommState IXON ~IXOFF trace:comm:GetCommState ~CRTSCTS trace:comm:SetCommState handle 812, ptr 0x443e6e6c trace:comm:SetCommState bytesize 8 baudrate 115200 fParity 1 Parity 0 stopbits 1 trace:comm:SetCommState ~IXON ~IXOFF trace:comm:SetCommState CRTSCTS trace:comm:SetCommTimeouts (32c,0x443e6ea0) trace:comm:PurgeComm handle 812, flags f trace:comm:EscapeCommFunction handle 812, function=5 trace:comm:EscapeCommFunction SETDTR trace:file:SetFilePointer handle 264 offset 4394532 high 0 origin 0 trace:file:ReadFile 264 0x405b5fd4 26 0x405b5f78 (nil) trace:file:SetFilePointer handle 264 offset 4394558 high 0 origin 0 trace:file:ReadFile 264 0x41f515c0 64 0x405b5f98 (nil) trace:comm:GetCommModemStatus 4126 -> MS_DSR_ON MS_CTS_ON trace:comm:ClearCommError handle 812 cbInQue = 0 cbOutQue = 0 trace:file:ReadFile 812 0x4453623c 3200 0x44536208 0x4453621c FIXME:pthread_rwlock_rdlock FIXME:pthread_rwlock_unlock trace:file:FILE_SetDosError errno = 11 Resource temporarily unavailable trace:comm:ClearCommError handle 812 cbInQue = 0 cbOutQue = 0 trace:file:ReadFile 812 0x4453623c 3200 0x44536208 0x4453621c FIXME:pthread_rwlock_rdlock FIXME:pthread_rwlock_unlock trace:file:FILE_SetDosError errno = 11 Resource temporarily unavailable fixme:comm:SetupComm insize 24376 outsize 8192 unimplemented stub trace:comm:GetCommState handle 812, ptr 0x443e6e3c trace:comm:GetCommState OK trace:comm:GetCommState bytesize 8 baudrate 115200 fParity 1 Parity 0 stopbits 1 trace:comm:GetCommState ~IXON ~IXOFF trace:comm:GetCommState CRTSCTS trace:comm:SetCommState handle 812, ptr 0x443e6e3c trace:comm:SetCommState bytesize 8 baudrate 115200 fParity 1 Parity 0 stopbits 1 trace:comm:SetCommState ~IXON ~IXOFF trace:comm:SetCommState CRTSCTS trace:comm:ClearCommError handle 812 cbInQue = 0 cbOutQue = 0 trace:file:ReadFile 812 0x4453623c 3200 0x44536208 0x4453621c FIXME:pthread_rwlock_rdlock FIXME:pthread_rwlock_unlock trace:file:FILE_SetDosError errno = 11 Resource temporarily unavailable trace:file:SetFilePointer handle 264 offset 4940906 high 0 origin 0 trace:file:ReadFile 264 0x405b5dc8 26 0x405b5d6c (nil) trace:file:SetFilePointer handle 264 offset 4940932 high 0 origin 0 trace:file:ReadFile 264 0x41e0d768 3144 0x405b5d8c (nil) trace:comm:ClearCommError handle 812 cbInQue = 0 cbOutQue = 0 trace:file:SetFilePointer handle 264 offset 4940906 high 0 origin 0 trace:file:ReadFile 264 0x405b5dd0 26 0x405b5d74 (nil) trace:file:SetFilePointer handle 264 offset 4940906 high 0 origin 0 trace:file:_hwrite 264 0x405b5dec 26 trace:file:WriteFile 264 0x405b5dec 26 0x405b5d94 (nil) trace:file:_hwrite 264 0x41e0d768 3144 trace:file:WriteFile 264 0x41e0d768 3144 0x40
Re: DTR Flow Control
On Sun, 24 Feb 2002 [EMAIL PROTECTED] wrote: > This is the key point, because if the application itself supports DTR/DSR > handshaking, then all the support which it needs is the ability to sense > DSR and to set/reset DTR. > > -- Chuck Crayne > --- > [EMAIL PROTECTED] > --- Yes, it should be able to do that. Lawson
Re: DTR Flow Control
In <[EMAIL PROTECTED]>, on 02/24/02 at 07:34 PM, Mike McCormack <[EMAIL PROTECTED]> said: :> Is DTR flow control supported? :No. However the Win32 API uses very confusing names, so make sure the app :is really asking for DTR/DSR flow control. This is the key point, because if the application itself supports DTR/DSR handshaking, then all the support which it needs is the ability to sense DSR and to set/reset DTR. -- Chuck Crayne --- [EMAIL PROTECTED] ---
Re: DTR Flow Control
Hi Michael, > Is DTR flow control supported? No. However the Win32 API uses very confusing names, so make sure the app is really asking for DTR/DSR flow control. DTR_CONTROL_ENABLE does not mean DTR/DSR flow control is enabled, it means turn on the DTR line permanently. Only DTR_CONTROL_HANDSHAKE means the serial port should use DSR/DTR handshaking. (AFAIK, DTR_CONTROL_ENABLE and DTR_CONTROL_DISABLE flags are not correctly handled in the current wine... they should actively turn on or turn off DTR). Additionally, there were some problems in the GetCommState/SetCommState code that saw DTR_CONTROL_HANDSHAKE accidently turned on, so make sure that it is really the application that is requesting it. As Marcus pointed out, the linux kernel itself does not support DTR/DSR flow control, but given the time and motivation, we could solve the problem if you really need to make this work... Mike -- mailto:[EMAIL PROTECTED] ph +82 16 430 0425 __ Get your free Australian email account at http://www.Looksmart.com.au
Re: DTR Flow Control
On Fri, Feb 22, 2002 at 05:36:53PM -0800, Michael Cardenas wrote: > Is DTR flow control supported? > > There's a comment in comm.c in SetCommState that says it's not, but > EscapeCommFunction has a SETDTR case and a CLRDTR case. To my knowledge the serial driver of Linux does not support DTR flow control. So it might be a bit hard to implement in WINE. There is an article from Rein Klazes, http://www.winehq.com/hypermail/wine-users/2001/12/0209.html could you try his suggestions? Ciao, Marcus
Re: DTR Flow Control
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/.
