https://bugs.winehq.org/show_bug.cgi?id=17195
--- Comment #166 from Sebastian Lackner sebastian@fds-team.de --- Hi,
@Adam: The main advantage of using the wineserver is that such a solution is platform independent. Nevertheless your approach had several disadvantages - writing was always nonblocking, it was theoretically possible to flood the wineserver with too many messages, so that no further memory can be allocated, ... besides that it didn't follow the wineserver style convention, and used wrong or no error codes at some places, but thats easy to fix of course.
If we want to use a wineserver solution, then we have to do a lot more work, to implement everything properly (blocking writes, but different partial writes after each other shouldn't result in interleaved output, ...). I personally would prefer having a kernel solution, but at the end its not really my decision. The next step will be to get all my >1000 lines of additional tests upstream, and talking to some kernel developers in the meantime.
Encoding the "end-of-message" flag in the data stream is not possible, since you have no control how many bytes are returned ... unless you do a peek first, but then its subject to race conditions.
@Luke: One socket pair per message also doesn't sound like a good solution, what about weird programs sending one byte after each other? Moreover in byte read mode the messages have to be merged again, which would also lead to race conditions, when NtReadFile only operates only on one socket at a specific time.
I have also no idea why you think its not possible to implement "blocking" behaviour in the wineserver. It is possible of course, and in fact used already in some places, it just works by allocating a wait handle, and then temporarily returning control to the application. While inside a wineserver call no APCs can be handled, so it wouldn't be a good idea anyway, and wouldn't even work in a multithreaded environment. A multithreaded wineserver would be good for performance reasons, but it makes a lot of other things much more difficult, and I doubt that anyone would be able to change all that without introducing new regressions.
And, it was already said multiple times: Please just leave out all your insults and anger, this bug report is not the right place for that. Even if you have a different opinion, you have to accept that Alexandre is the maintainer, and he decides which features are good enough to included in the official version. Noone keeps you from adding experimental features in your own builds.
Regards, Sebastian