[Bug 19713] New: Some serial port communication functions behave differently in Wine and Windows.

http://bugs.winehq.org/show_bug.cgi?id=19713

Summary: Some serial port communication functions behave
                    differently in Wine and Windows.
           Product: Wine
           Version: 1.1.27
          Platform: PC
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: kernel32
        AssignedTo: [e-mail]
        ReportedBy: [e-mail]

Created an attachment (id=23025)
 --> (http://bugs.winehq.org/attachment.cgi?id=23025)
Test program

This makes test program to hang in Wine, but in MS it is ok. Test program
attached.

[Bug 19713] Some serial port communication functions behave differently in Wine and Windows.

http://bugs.winehq.org/show_bug.cgi?id=19713

--- Comment #1 from Alexander Varnin   2009-08-12 14:19:41 ---
I'm testing barcode scanner with WinAPI application. When program starts, it
waits for data from serial. When data comes, it is doing some operations. In
Windows, it exits. But in Wine it hangs on GetOverlappedResult. I think it is
because of previous call to WaitForSingleObject, that clears some internal
buffers. That is a problem.

[Bug 19713] Some serial port communication functions behave differently in Wine and Windows.

http://bugs.winehq.org/show_bug.cgi?id=19713

--- Comment #2 from Alexander Varnin   2009-08-12 14:22:22 ---
Created an attachment (id=23026)
 --> (http://bugs.winehq.org/attachment.cgi?id=23026)
Test program results in wine

[Bug 19713] Some serial port communication functions behave differently in Wine and Windows.

http://bugs.winehq.org/show_bug.cgi?id=19713

--- Comment #3 from Alexander Varnin   2009-08-12 14:44:08 ---
Created an attachment (id=23027)
 --> (http://bugs.winehq.org/attachment.cgi?id=23027)
Test program results in windows

[Bug 19713] Some serial port communication functions behave differently in Wine and Windows.

http://bugs.winehq.org/show_bug.cgi?id=19713

Nikolay Sivov  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #23025|text/x-c++src               |text/plain
          mime type|                            |

[Bug 19713] Some serial port communication functions behave differently in Wine and Windows.

http://bugs.winehq.org/show_bug.cgi?id=19713

Nikolay Sivov  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #23026|application/octet-stream    |text/plain
          mime type|                            |

[Bug 19713] Some serial port communication functions behave differently in Wine and Windows.

http://bugs.winehq.org/show_bug.cgi?id=19713

--- Comment #4 from Juan Lang   2009-08-12 18:07:05 ---
Are you sure this isn't a race condition?  You create the event as an
auto-reset event, that is, with bManualReset = FALSE:
    ovOverlapped.hEvent = CreateEvent(NULL, FALSE/*TRUE*/, FALSE, NULL);
> From MSDN's remarks section on GetOverlappedResult:

Specify a manual-reset event object in the OVERLAPPED structure. If an
auto-reset event object is used, the event handle must not be specified in any
other wait operation in the interval between starting the overlapped operation
and the call to GetOverlappedResult. For example, the event object is sometimes
specified in one of the wait functions to wait for the operation's completion.
When the wait function returns, the system sets an auto-reset event's state to
nonsignaled, and a subsequent call to GetOverlappedResult with the bWait
parameter set to TRUE causes the function to be blocked indefinitely.

And this is what you do:  you call WaitForSingleEvent on the event until it's
signalled, then call GetOverlappedResult on it:
                 while (dwResult = WaitForSingleObject(ovOverlapped.hEvent, 50)
== WAIT_TIMEOUT)
(snip)
                        if (!(bOvResult = GetOverlappedResult(hSerial,
&ovOverlapped, &dwOvRes, TRUE)))

I'm curious why you commented out /*TRUE*/ when you created the event.  Based
on MSDN's comments, I think some more testing on more than one Windows version
and with more than one serial driver would be in order before concluding that
Windows *always* behaves this way.

[Bug 19713] Some serial port communication functions behave differently in Wine and Windows.

http://bugs.winehq.org/show_bug.cgi?id=19713

--- Comment #5 from Alexander Varnin   2009-08-13 13:36:31 ---
(In reply to comment #4)
> Are you sure this isn't a race condition?  You create the event as an
> auto-reset event, that is, with bManualReset = FALSE:
>     ovOverlapped.hEvent = CreateEvent(NULL, FALSE/*TRUE*/, FALSE, NULL);
>
> From MSDN's remarks section on GetOverlappedResult:
>
> Specify a manual-reset event object in the OVERLAPPED structure. If an
> auto-reset event object is used, the event handle must not be specified in any
> other wait operation in the interval between starting the overlapped operation
> and the call to GetOverlappedResult. For example, the event object is sometimes
> specified in one of the wait functions to wait for the operation's completion.
> When the wait function returns, the system sets an auto-reset event's state to
> nonsignaled, and a subsequent call to GetOverlappedResult with the bWait
> parameter set to TRUE causes the function to be blocked indefinitely.
>
> And this is what you do:  you call WaitForSingleEvent on the event until it's
> signalled, then call GetOverlappedResult on it:
>                  while (dwResult = WaitForSingleObject(ovOverlapped.hEvent, 50)
> == WAIT_TIMEOUT)
> (snip)
>                         if (!(bOvResult = GetOverlappedResult(hSerial,
> &ovOverlapped, &dwOvRes, TRUE)))
>
> I'm curious why you commented out /*TRUE*/ when you created the event.  Based
> on MSDN's comments, I think some more testing on more than one Windows version
> and with more than one serial driver would be in order before concluding that
> Windows *always* behaves this way.

It was not me, who have written this code. I've cut it from my colleague
program. The problem is, that part our well-working windows software doesn't
want to work on wine. It is very strange, that this code works in other way,
than written in MSDN.

Now i've tried to replace FALSE with TRUE. Now, it passes Checkpoint 2, but
comes to Checkpoint 3, while windows is coming to Checkpoint 4. It still
behaves differently. I'm not sure that it is bug, but it is incompability. What
policy do wine developer keep to?

[Bug 19713] Some serial port communication functions behave differently in Wine and Windows.

http://bugs.winehq.org/show_bug.cgi?id=19713

--- Comment #6 from Juan Lang   2009-08-14 15:41:02 ---
(In reply to comment #5)
> Now i've tried to replace FALSE with TRUE. Now, it passes Checkpoint 2, but
> comes to Checkpoint 3, while windows is coming to Checkpoint 4. It still
> behaves differently. I'm not sure that it is bug, but it is incompability. What
> policy do wine developer keep to?

This seems like a bug.  In general, a difference in behavior between Windows
and Wine is considered a bug.  With regards to the earlier program, with
bManualReset = FALSE, it *appears* to be a program bug rather than a Wine bug. 
It may well be that under Windows, with a particular program and serial driver,
the program doesn't deadlock.  However, with the large MSDN warning about
potential deadlock, I'd want to be certain that the deadlock _never_ happens,
with any serial driver and under any version of Windows, before I say that it
is a Wine bug.

So with the modified program, with bManualReset = TRUE, GetOverlappedResult
returns TRUE in Windows and FALSE in Wine, correct?

[Bug 19713] Some serial port communication functions behave differently in Wine and Windows.

http://bugs.winehq.org/show_bug.cgi?id=19713

--- Comment #7 from Alexander Varnin   2009-08-15 03:09:29 ---
(In reply to comment #6)
> This seems like a bug.  In general, a difference in behavior between Windows
> and Wine is considered a bug.  With regards to the earlier program, with
> bManualReset = FALSE, it *appears* to be a program bug rather than a Wine bug. 
> It may well be that under Windows, with a particular program and serial driver,
> the program doesn't deadlock.  However, with the large MSDN warning about
> potential deadlock, I'd want to be certain that the deadlock _never_ happens,
> with any serial driver and under any version of Windows, before I say that it
> is a Wine bug.

Lots of clients use this soft on their windows machines and they have never
reported about problems. I can say, that in windows it doesn't matter, if you
use manual-reset or auto-reset. Program behaves same way.
> So with the modified program, with bManualReset = TRUE, GetOverlappedResult
> returns TRUE in Windows and FALSE in Wine, correct?

Yes, it works so.

P.S. I'm leaving for two weeks, so i will not answer at this time.

[Bug 19713] Some serial port communication functions behave differently in Wine and Windows.

http://bugs.winehq.org/show_bug.cgi?id=19713

Alexander Varnin  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #23025|0                           |1
        is obsolete|                            |

--- Comment #8 from Alexander Varnin   2009-09-01 15:13:03 ---
Created an attachment (id=23367)
 --> (http://bugs.winehq.org/attachment.cgi?id=23367)
Test program 2

New test program, that better shows incompability problem.

[Bug 19713] Some serial port communication functions behave differently in Wine and Windows.

http://bugs.winehq.org/show_bug.cgi?id=19713

Alexander Varnin  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #23027|0                           |1
        is obsolete|                            |

--- Comment #9 from Alexander Varnin   2009-09-01 15:14:25 ---
Created an attachment (id=23368)
 --> (http://bugs.winehq.org/attachment.cgi?id=23368)
Test program 2 results in windows

[Bug 19713] Some serial port communication functions behave differently in Wine and Windows.

http://bugs.winehq.org/show_bug.cgi?id=19713

Alexander Varnin  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #23026|0                           |1
        is obsolete|                            |

--- Comment #10 from Alexander Varnin   2009-09-01 15:16:25 ---
Created an attachment (id=23369)
 --> (http://bugs.winehq.org/attachment.cgi?id=23369)
Test program 2 results in wine

[Bug 19713] Some serial port communication functions behave differently in Wine and Windows.

http://bugs.winehq.org/show_bug.cgi?id=19713

--- Comment #11 from Alexander Varnin   2009-09-01 15:21:47 ---
I've tried to research problem more, and found out, that it is possible, that
data comes incomplete. When i scan with barcode scaner, program captures the
event, but in wine it is impossible to read it, because data is got stuck
somewhere, while in windows, program reads data in first loop iteration(in
first query). Any suggestions, what can make data stuck?

[Bug 19713] Some serial port communication functions behave differently in Wine and Windows.

http://bugs.winehq.org/show_bug.cgi?id=19713

Mike Kaplinskiy  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]

--- Comment #12 from Mike Kaplinskiy   2009-09-03 13:06:13 ---
I think that we are just not setting the i/o status correctly - the events
should be set, but GetOverlappedResult will return false (since we never change
status_pending to anything else).

Does the patch at
http://www.nabble.com/Re:-Asynchronus-serial-port-p25268651.html help?

[Bug 19713] Some serial port communication functions behave differently in Wine and Windows.

http://bugs.winehq.org/show_bug.cgi?id=19713

--- Comment #13 from Alexander Varnin   2009-09-03 13:44:48 ---
Yes, it does!!!!!!!!!!!!!!!!!!!!
Great thanks for you! :)

Will it be included in wine main tree?

[Bug 19713] Some serial port communication functions behave differently in Wine and Windows.

http://bugs.winehq.org/show_bug.cgi?id=19713

--- Comment #14 from Alexander Varnin   2009-09-04 15:14:11 ---
Created an attachment (id=23429)
 --> (http://bugs.winehq.org/attachment.cgi?id=23429)
Patch that fixes first problem

[Bug 19713] Some serial port communication functions behave differently in Wine and Windows.

http://bugs.winehq.org/show_bug.cgi?id=19713

Alexander Varnin  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #23367|0                           |1
        is obsolete|                            |

--- Comment #15 from Alexander Varnin   2009-09-04 15:19:05 ---
Created an attachment (id=23430)
 --> (http://bugs.winehq.org/attachment.cgi?id=23430)
Test program 3

There is another problem of imcompability with Microsoft, caused by
asynchronous serial port realization. GetOverlappedResult fails, if using it
after ReadFile. Windows does well. Here is new test program.

[Bug 19713] Some serial port communication functions behave differently in Wine and Windows.

http://bugs.winehq.org/show_bug.cgi?id=19713

Alexander Varnin  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #23369|0                           |1
        is obsolete|                            |

--- Comment #16 from Alexander Varnin   2009-09-04 15:21:35 ---
Created an attachment (id=23431)
 --> (http://bugs.winehq.org/attachment.cgi?id=23431)
Test program 3 results in wine

[Bug 19713] Some serial port communication functions behave differently in Wine and Windows.

http://bugs.winehq.org/show_bug.cgi?id=19713

Alexander Varnin  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #23368|0                           |1
        is obsolete|                            |

--- Comment #17 from Alexander Varnin   2009-09-04 15:29:49 ---
Created an attachment (id=23432)
 --> (http://bugs.winehq.org/attachment.cgi?id=23432)
Test program 3 results in windows

[Bug 19713] Some serial port communication functions behave differently in Wine and Windows.

http://bugs.winehq.org/show_bug.cgi?id=19713

Alexander Varnin  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #23431|application/octet-stream    |text/plain
          mime type|                            |

[Bug 19713] Some serial port communication functions behave differently in Wine and Windows.

http://bugs.winehq.org/show_bug.cgi?id=19713

--- Comment #18 from Alexander Varnin   2009-09-04 17:39:48 ---
As i also find out, after 8 minutes of wait, while test program run in loop, it
finishes and acts like windows - correct. I can't imagine, what can make wine
wait for eight minutes, before sending data event.

[Bug 19713] Some serial port communication functions behave differently in Wine and Windows.

http://bugs.winehq.org/show_bug.cgi?id=19713

--- Comment #19 from Mike Kaplinskiy   2009-09-05 13:16:30 ---
Does replacing Sleep(50) by SleepEx(50, TRUE) fix your problem?

[Bug 19713] Some serial port communication functions behave differently in Wine and Windows.

http://bugs.winehq.org/show_bug.cgi?id=19713

--- Comment #20 from Alexander Varnin   2009-09-05 13:32:36 ---
No. It still waits 8 minutes. Why can event go so long?

[Bug 19713] Some serial port communication functions behave differently in Wine and Windows.

http://bugs.winehq.org/show_bug.cgi?id=19713

--- Comment #21 from Alexander Varnin   2009-09-06 06:25:43 ---
Created an attachment (id=23467)
 --> (http://bugs.winehq.org/attachment.cgi?id=23467)
Temp patch that fixes second problem

I've found a temporary fix. I've forced async wait timeout to 200 milliseconds,
and now it doesn't wait 8 minutes. It is rather unclean way, but it works. 
When i try to set too short timeout, barcode get cut. That mean, that something
happens in this 200 milliseconds, but wineserver doesn't report. To make it
report the event would be good universal fix.

[Bug 19713] Some serial port communication functions behave differently in Wine and Windows.

http://bugs.winehq.org/show_bug.cgi?id=19713

Alexander Varnin  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
            Version|1.1.27                      |1.1.29

[Bug 19713] Some serial port communication functions behave differently in Wine and Windows.

http://bugs.winehq.org/show_bug.cgi?id=19713

Dmitry Timoshkov  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
            Version|1.1.29                      |1.1.27

--- Comment #22 from Dmitry Timoshkov   2009-09-06 07:20:55 ---
Please don't change the version field.

[Bug 19713] Some serial port communication functions behave differently in Wine and Windows.

http://bugs.winehq.org/show_bug.cgi?id=19713

--- Comment #23 from Alexander Varnin   2009-09-06 08:40:50 ---
Why? It is still actual for 1.1.29.

[Bug 19713] Some serial port communication functions behave differently in Wine and Windows.

http://bugs.winehq.org/show_bug.cgi?id=19713

--- Comment #24 from Dmitry Timoshkov   2009-09-06 09:57:09 ---
Adding a comment is enough.

[Bug 19713] Some serial port communication functions behave differently in Wine and Windows.

http://bugs.winehq.org/show_bug.cgi?id=19713

Ken Sharp  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |hardware, source

[Bug 19713] Some serial port communication functions behave differently in Wine and Windows.

http://bugs.winehq.org/show_bug.cgi?id=19713

[e-mail] changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]

--- Comment #25 from [e-mail]  2009-10-03 12:50:30 ---
http://www.winehq.org/pipermail/wine-devel/2009-September/078435.html

Isn't setting commio->iosb->u.Status racy?
commio->iosb may be set from wait_for_event() which is called by an extra 
thread or by io_control().
Couldn't it happen that
    wait_on starts the thread
    wait_for_event sets the commio->iosb->u.Status to STATUS_SUCCESS
    wait_on returns to io_control STATUS_PENDING
    io_control overwrites commio->iosb->u.Status with STATUS_PENDING

I think io_control() should set commio->iosb->u.Status to STATUS_PENDING 
before calling wait_on(). After wait_on() io_control() should not set 
commio->iosb->u.Status if wait_on() returns STATUS_PENDING. Here the idea:

------------------
    case IOCTL_SERIAL_WAIT_ON_MASK:
         if (lpOutBuffer && nOutBufferSize == sizeof(DWORD))
         {
             piosb->u.Status = STATUS_PENDING;
             piosb->Information = sz;
             if (!(status = wait_on(hDevice, fd, hEvent, piosb, lpOutBuffer)))
                 sz = sizeof(DWORD);
             else if (status == STATUS_PENDING)
                 return status;
         }
         else
             status = STATUS_INVALID_PARAMETER;
         break;
-------------------

I'm just pasting this here, so that the idea won't get lost.

[Bug 19713] Some serial port communication functions behave differently in Wine and Windows.

http://bugs.winehq.org/show_bug.cgi?id=19713

--- Comment #26 from Alexander Varnin   2009-10-04 16:23:29 ---
Yeah, thanks. I'll take a look as soon as i have some free time.

[Bug 19713] Some serial port communication functions behave differently in Wine and Windows.

http://bugs.winehq.org/show_bug.cgi?id=19713

Graham Inggs  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]

[Bug 19713] Some serial port communication functions behave differently in Wine and Windows.

http://bugs.winehq.org/show_bug.cgi?id=19713

--- Comment #27 from [e-mail] 2013-05-29 11:18:28 CDT ---
This has not been updated for over 1000 days.

Is this still an issue in 1.5.31 or higher or is this abandoned ?

[Bug 19713] Some serial port communication functions behave differently in Wine and Windows.

http://bugs.winehq.org/show_bug.cgi?id=19713

--- Comment #28 from Alexander Varnin  2013-05-29 12:04:38 CDT ---
I don't have motivation to check this issue, because i'm not on that task any
more. Test program is here, if somebody is interested, he can test it.

[Bug 19713] Some serial port communication functions behave differently in Wine and Windows.

http://bugs.winehq.org/show_bug.cgi?id=19713

--- Comment #29 from Graham Inggs  2013-05-30 07:21:22 CDT ---
I believe #25083 may be a duplicate of this bug:
http://bugs.winehq.org/show_bug.cgi?id=25083

I will try to build Alexander's test program and see if I can reproduce the
problem.

[Bug 19713] Some serial port communication functions behave differently in Wine and Windows.

http://bugs.winehq.org/show_bug.cgi?id=19713

--- Comment #30 from Bruno Jesus  2013-05-30 08:50:35 CDT ---
I tried to test using the attached program but it requires the serial port to
receive data, I didn't have any device that could do that at the moment but
I'll try again when I do.

[Bug 19713] Some serial port communication functions behave differently in Wine and Windows.

http://bugs.winehq.org/show_bug.cgi?id=19713

--- Comment #31 from Graham Inggs  2013-05-31 07:09:15 CDT ---
Created attachment 44609
  --> http://bugs.winehq.org/attachment.cgi?id=44609
Test program 4 (for loopback)

Confirming this is still an issue in Wine 1.5.31.

I have modified Alexander's program so that it will send keypresses out over
COM1 and therefore can be used with a loopback adapter (connect pins 2 & 3
together).

You will need to run the test program in Wine CMD (wine start cmd) in order for
it to be able to read keypresses.

[Bug 19713] Some serial port communication functions behave differently in Wine and Windows.

http://bugs.winehq.org/show_bug.cgi?id=19713

Helder 'Lthere' Magalhães  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]

[Bug 19713] Some serial port communication functions behave differently in Wine and Windows.

https://bugs.winehq.org/show_bug.cgi?id=19713

Bruno Jesus  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]

[Bug 19713] Some serial port communication functions behave differently in Wine and Windows.

https://bugs.winehq.org/show_bug.cgi?id=19713

--- Comment #32 from Bruno Jesus  ---
Still in wine 1.7.33.

[Bug 19713] Some serial port communication functions behave differently in Wine and Windows.

https://bugs.winehq.org/show_bug.cgi?id=19713

--- Comment #33 from Graham Inggs  ---
Still occurring in Wine 1.7.50.

Why does this bug still show UNCONFIRMED?

[Bug 19713] Some serial port communication functions behave differently in Wine and Windows.

https://bugs.winehq.org/show_bug.cgi?id=19713

Bruno Jesus  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever confirmed|0                           |1

--- Comment #34 from Bruno Jesus  ---
Confirmed by at least 3 people.

[Bug 19713] Some serial port communication functions behave differently in Wine and Windows.

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=19713

Zeb Figura  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|kernel32                    |serial