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

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

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.