[PATCH 2/2] ntdll: Make avail_mode always TRUE for serial ports.

[Alex Henrie]

2016-01-12 6:30 GMT-07:00 Alexandre Julliard <julliard at winehq.org>:
> Alex Henrie <alexhenrie24 at gmail.com> writes:
>
>> Cc: Eric Pouech <eric.pouech at orange.fr>
>> Cc: Sebastian Lackner <sebastian at fds-team.de>
>>
>> Fixes https://bugs.winehq.org/show_bug.cgi?id=39875
>>
>> avail_mode controls whether a read operation is considered a success as
>> long as at least one byte can be read, or whether the operation is
>> considered pending until the total number of requested bytes has been
>> received. For serial ports, avail_mode was TRUE if read operations
>> always finished immediately, and FALSE if read operations did not finish
>> until data was available or the request timed out.[1] However, whether
>> or not a zero-byte read is considered a success has nothing to do with
>> whether or not a one-byte read is considered a success.
>>
>> Since serial ports are essentially hardware-based pipes, it makes sense
>> that they behave the same as software pipes and sockets.
>
> Pipes and sockets don't have comm timeouts, it's not at all obvious that
> they should be identical. This will need tests; at the very least a test
> app, if using the testbot isn't possible.

You're right; my patch was incorrect. The attached test program never
finishes on Windows, but my patch caused it to finish on Wine.

I am now convinced that the problem is more mundane: Starcraft sets
ReadIntervalTimeout to 5ms, but Wine ignores this value and the read
never times out. I've tried editing server/serial.c to take the
interval timeout into account, but nothing I can think of is very
elegant. How do you want this feature implemented?

By the way, I'm happy to supply free RS-232 hardware to any other
developers that want to work on this.

-Alex
-------------- next part --------------
A non-text attachment was scrubbed...
Name: partial-serial-read.c
Type: text/x-csrc
Size: 3349 bytes
Desc: not available
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20160114/51b0d1a5/attachment-0001.c>