https://bugs.winehq.org/show_bug.cgi?id=17195
--- Comment #147 from Luke Kenneth Casson Leighton lkcl@lkcl.net --- guys,
the work adding proper named pipes support is now five years old. a large number of programs critically depend on this working. there have been four other duplicate bugs and there are two blockers, one of which has *eighteen* further duplicates.
i did not tackle this particular functionality without a good reason, because i know how critical and low-level it is. i am amazed that it was not tackled over a decade ago when wine was first starting out.
now, one of the problems is that because it is so low-level, it is actually very hard to even get wine executables started to the point where tests can be run.
to make that clear: this is such low-level functionality that even *STARTING WINE* is itself a pretty much full and complete test.
to reiterate: by the time you get to the point where the test executables can *be run*, there will have *already* been hundreds of function calls involving NamedPipe MessageMode datagrams.
additionally, i already pointed out that the use of sockets is not very appropriate. the GNU/Linux OS and the BSD OSes simply do not have the fundamental OS-level concept of reliable streamed datagrams, and emulating them in a single-threaded environment (wineserver) is a bitch and a half.
also, i have pointed out that to use sockets you need to make wineserver multi-threaded. mr alexandre jiullard has told everyone that everything that i say is total shit, and i am not interested in educating mr jiullard.
also, i have pointed out that if you keep using a single-threaded wineserver the only other way to properly implement reliable streamed datagrams (in a fast manner) is to put the data into shared memory (then use fixed-length (semaphored) message encoding via wineserver to communicate between user-level processes where that data may be obtained). mr jiullard has also said that this idea is shit. i am not intereested in educating mr jiullard.
you _could_ implement streamed reliable datagrams in a single-threaded wineserver by placing the datagram's data into files (one file per packet) and, again, use the single-threaded wineserver to communicate with a fixed-length (semaphore-protected) message where the datagram's data could be obtained. however this _would_ actually be shit, because it would be unbelievably slow.
so the summary is: we basically know where the problem lies, and it is in the attitude of mr jiullard. he doesn't like the fact that i have expertise in this area. until he gets over his psychiatric problem this bug is going to continue to be blocked and a huge number of applications - some of them quite prominent - will be excluded from the list of applications that wine is capable of running.