[Bug 17195] Multiple applications and games need support for named pipe message mode (NamedPipe datagrams need to be _really_ datagrams)

wine-bugs at winehq.org wine-bugs at winehq.org
Sun Mar 26 14:44:14 CDT 2017


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

--- Comment #182 from Jacek Caban <jacek at codeweavers.com> ---
> And I see no Sign-offs or Froms mentioning Sebastian (and Co.:) here, so an
> update on current situation / work being carried out would be very
> interesting to get (from Sebastian, Jacek or esp. Alexandre).


Sure, here is an overview of the sutuation. If you're interested in patch
reviews, see wine-devel. All my commits to server (and some to ntdll) since
October were related.

I revisited what was already discussed in the bug: implement named pipes
entirely in wineserver. The implementation uses wineserver-based I/O
implemented by Alexandre in a generic way when he was implementing implementing
device-based I/O. What we have in the tree since last Friday is named pipe
implementation inside wineserver, where we can control everything, including
data flow and blocking. The committed series of patches contained all features
that previous Wine client-side implementation had, but I tried to move as much
as possible out of the series to limit the scope of a single very risky commit.
So app-visible fixes we have already are:

- zero length message reads
- peek bound to message size
- buffer handling and blocking identical to Windows
- proper behaviour on pipe end close

That should cover compatibility with applications that use
NAMED_PIPE_MESSAGE_STREAM_WRITE flag (without NAMED_PIPE_MESSAGE_STREAM_READ).
I believe that this bug is mostly about NAMED_PIPE_MESSAGE_STREAM_READ, which
is easy to fix now, but one more patch is still needed:
https://source.winehq.org/patches/data/131854

wine-staging has a different and nicely working message mode implementation.
The way it's implemented by Sebastian has its advantages. Most notably, its
performance is very good. Unfortunately, it has also a problem of being not
portable. That was actually my direct reason to revisit the bug: I needed
something working on macOS, so I couldn't use Sebastian's patches. The result
of my work is portable across all platforms that Wine supports. The interesting
thing is that both implementations don't really conflict with each other.
wine-staging implementation is mostly on client side and is very much like what
we still use for byte mode, so Sebastian may rebase it if he wishes.

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



More information about the wine-bugs mailing list