[Bug 38204] New: WriteFileEx/ReadFileEx C Ubuntu 14.04 LTS
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(a)winehq.org Reporter: kotomixkyou(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=38204 --- Comment #1 from kotomixkyou(a)gmail.com --- Identical problem in 1.7.34 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=38204 Bruno Jesus <00cpxxx(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |hardware Distribution|--- |Ubuntu Summary|WriteFileEx/ReadFileEx C |WriteFileEx/ReadFileEx |Ubuntu 14.04 LTS |problem -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=38204 --- Comment #2 from Bruno Jesus <00cpxxx(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=38204 --- Comment #3 from kotomixkyou(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=38204 --- Comment #4 from kotomixkyou(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=38204 --- Comment #5 from Alexandre Julliard <julliard(a)winehq.org> --- 17 is ctrl-Q (XON), probably software flow control is mistakenly enabled on that link. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=38204 --- Comment #6 from kotomixkyou(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=38204 --- Comment #7 from kotomixkyou(a)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 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=38204 Alex Henrie <alexhenrie24(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID CC| |alexhenrie24(a)gmail.com --- Comment #8 from Alex Henrie <alexhenrie24(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=38204 Frédéric Delanoy <frederic.delanoy(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #9 from Frédéric Delanoy <frederic.delanoy(a)gmail.com> --- Closing INVALID bugs. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
participants (1)
-
wine-bugs＠winehq.org