https://bugs.winehq.org/show_bug.cgi?id=17195 --- Comment #147 from Luke Kenneth Casson Leighton <lkcl(a)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. -- 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.