SetNamedPipeHandleState function

[Chebanenko Igor]

http://msdn.microsoft.com/en-us/library ... 85%29.aspx

Sets the read mode and the blocking mode of the specified named pipe. If the specified handle is to the client end of a named pipe and if the named pipe server process is on a remote computer, the function can also be used to control local buffering.

[oiaohm]

Chebanenko Igor not that simple.

http://wiki.winehq.org/NamedPipes
http://lkcl.net/namedpipes/namedpipes-emulation.txt

Wine includes some named pipe emulation in wineserver. Over network requires behaving with samba. There are open bugs on the topic.

Chebanenko Igor exactly what application is requiring extra functionality and its it already associated with one of the namedpipe bugs?

[Chebanenko Igor]

http://bugs.winehq.org/buglist.cgi?quic ... andleState

[oiaohm]

Chebanenko Igor there are two particular named-pipe bugs relating to what you are talking about.
http://bugs.winehq.org/show_bug.cgi?id=17195
http://bugs.winehq.org/show_bug.cgi?id=17273

But without application I cannot tell you what one it owns in. Yes their are proto patches to wine for both. When wine implements features its so applications work. This requires applications as test items.

Wine does not implement as the MSDN says. Over the years the developers have found many cases where the MSDN is plain wrong to how windows is implemented.

Every time you ask is X function implemented you will be asked for what application.

[Chebanenko Igor]

But what if Wine team will implement function as MSDN says?(Maybe for some test cases at least)

[oiaohm]

But what if Wine team will implement function as MSDN says?(Maybe for some test cases at least)

I have lived this first hand when Direct X 7 in wine was implemented based on MSDN and tests against Microsoft software reference implementation. Over half the real world applications failed. Why more functionality than real world applications expected to find had been implemented.

Windows developed applications a lot depend on bugs in API implementations. Wine project started with the goal of implementing every windows API perfectly. Result wine could not run almost anything. This is why today policy is also what it is with bug to bug compatibility.

History simple says implement as per the MSDN if it wrong you will cause more failures than you can dream. The test cases required are the real world applications to show how those functions are really used to make test cases that test the real world usage.

What is written in the MSDN is nothing more than a guide. A guide on how they hoped to implement those functions not how they have.

[Chebanenko Igor]

Windows developed applications a lot depend on bugs in API implementations.

Windows developers trying to use BUG as a feature? MS in some cases makes things using /dev/ass,isn't it?