https://bugs.winehq.org/show_bug.cgi?id=17195
--- Comment #182 from Jacek Caban jacek@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.