https://bugs.winehq.org/show_bug.cgi?id=38204
Bug ID: 38204 Summary: WriteFileEx/ReadFileEx C Ubuntu 14.04 LTS Product: Wine Version: 1.6.2 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs@winehq.org Reporter: kotomixkyou@gmail.com Distribution: ---
Created attachment 50995 --> https://bugs.winehq.org/attachment.cgi?id=50995 Full description of bug
Previously posted here: https://forum.winehq.org/viewtopic.php?f=8&t=24271 or see attached document
General problem: Wine 1.6.2 Ubuntu 14.04 LTS
ReadFileEx CompletionRoutine does not take the expected dwNumberOfBytesTransfered in Ubuntu-Wine compared with windows. In windows dwNumberOfBytesTransfered is less than or equal to nNumberOfBytesToRead corresponding to the amount of data available to be read from an external device, but in Ubuntu-Wine nNumberOfBytesTransfered is always equal to nNumberOfBytesToRead/Write. Changing COMMTIMEOUTS.ReadIntervalTimeout to be MAXDWORD does return a smaller chunk of data but does not remedy the problem as it cuts off the packet.
When attempting to write into an external device that isn't turned on but connected by USB, WriteFileEx returns success in both windows and Ubuntu-Wine, but does not create the correct windows error 87, and the CompletionRoutine does not execute after the second WriteFileEx.
https://bugs.winehq.org/show_bug.cgi?id=38204
--- Comment #1 from kotomixkyou@gmail.com --- Identical problem in 1.7.34
https://bugs.winehq.org/show_bug.cgi?id=38204
Bruno Jesus 00cpxxx@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |hardware Distribution|--- |Ubuntu Summary|WriteFileEx/ReadFileEx C |WriteFileEx/ReadFileEx |Ubuntu 14.04 LTS |problem
https://bugs.winehq.org/show_bug.cgi?id=38204
--- Comment #2 from Bruno Jesus 00cpxxx@gmail.com --- If you could reproduce the problem with a small piece of code and a loopback serial device it would be simpler for others to reproduce.
https://bugs.winehq.org/show_bug.cgi?id=38204
--- Comment #3 from kotomixkyou@gmail.com --- (In reply to Bruno Jesus from comment #2)
If you could reproduce the problem with a small piece of code and a loopback serial device it would be simpler for others to reproduce.
Unfortunately the problem is mainly with how this program / device expects specific lengths of packets / data to be read after transmitting into the device other specific packets. So I don't know how useful running a small piece of code on a loopback serial device would be.
https://bugs.winehq.org/show_bug.cgi?id=38204
--- Comment #4 from kotomixkyou@gmail.com --- After further analysis, it seems that a specific value (0X11U in hexadecimal or 17 in decimal) is always missing or not read by the ReadFileEx function. For instance when querying the XY coordinates set by the device, reading byte by byte (ReadFileEx with a nNumberOfBytesToRead of 1) recursively always fails when it would get to a value of 0x11U or 17.
e.g. terminal output when steadily increasing the coordinates and reading from the device
Normally each packet consists of 11 bytes:
syn sequence datalength checksum 55 4a 5 c7
data(ID (3 bytes) x y) 8b 0 0 f a
checksum high / low 15 c1 Sample output:
55 4a 5 c7 8b 0 0 f a 15 c1 XY Input: (15, 10) 55 52 5 67 8b 0 0 f a 15 c1 XY Input: (15, 10) 55 5a 5 e2 8b 0 0 e a ba 82 XY Input: (14, 10) 55 62 5 8 8b 0 0 f a 15 c1 XY Input: (15, 10) 55 6a 5 8d 8b 0 0 e a ba 82 XY Input: (14, 10) 55 72 5 2d 8b 0 0 f a 15 c1 XY Input: (15, 10) 55 7a 5 a8 8b 0 0 10 a 51 e8 XY Input: (16, 10) 55 82 5 d1 8b 0 0 b 6e 72 55 82 5 d1 8b 0 0 b 6e 72 55 82 5 d1 8b 0 0 b 6e 72 55 82 5 d1 8b 0 0 b 6e 72 55 82 5 d1 8b 0 0 b 6e 72
The final line has the 10 byte message 55 82 5 d1 8b 0 0 b 6e 72 repeated 5 times (number of times the program will check for a message before throwing error)
This is evident elsewhere in the code as well where a fixed 0x11U or 17 value fails to be read as a part of the start up sequence of the program.
Any idea what could be causing this? The only possible connection I can find is that in the ASCII table 0x17U or 23 stands for End transmission blocks. Perhaps this is in connection with all the aforementioned problems experienced.
https://bugs.winehq.org/show_bug.cgi?id=38204
--- Comment #5 from Alexandre Julliard julliard@winehq.org --- 17 is ctrl-Q (XON), probably software flow control is mistakenly enabled on that link.
https://bugs.winehq.org/show_bug.cgi?id=38204
--- Comment #6 from kotomixkyou@gmail.com --- (In reply to Alexandre Julliard from comment #5)
17 is ctrl-Q (XON), probably software flow control is mistakenly enabled on that link.
How can I go about testing or disabling software flow control? Nothing in the code mentions "11U" "17" or any combination of flow control. Nor does the software documentation.
https://bugs.winehq.org/show_bug.cgi?id=38204
--- Comment #7 from kotomixkyou@gmail.com --- (In reply to kotomixkyou from comment #6)
(In reply to Alexandre Julliard from comment #5)
17 is ctrl-Q (XON), probably software flow control is mistakenly enabled on that link.
How can I go about testing or disabling software flow control? Nothing in the code mentions "11U" "17" or any combination of flow control. Nor does the software documentation.
Sorry ignore this I just went through and tested it with stty. Seems to resolve this issue at least.
Thank you
https://bugs.winehq.org/show_bug.cgi?id=38204
Alex Henrie alexhenrie24@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID CC| |alexhenrie24@gmail.com
--- Comment #8 from Alex Henrie alexhenrie24@gmail.com --- I'm closing this because there has been no activity for over a year and Alexandre pointed out that the problem does not appear to be in Wine.
https://bugs.winehq.org/show_bug.cgi?id=38204
Frédéric Delanoy frederic.delanoy@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #9 from Frédéric Delanoy frederic.delanoy@gmail.com --- Closing INVALID bugs.
-
wine-bugs＠winehq.org