Hi,

I noticed a handful of differences in the "lifecycle" of named pipes between Windows and Wine, and I figured I'd post about them here. I wrote a standalone one-file C++ program that demonstrates the differences I found. (In that test, the pipe handles are always overlapped and PIPE_WAIT.) I tested using wine-1.9.12.

The differences were:

1. With Windows, there can be multiple concurrent ConnectNamedPipe operations on a pipe. With Wine, the second ConnectNamedPipe call fails with ERROR_INVALID_HANDLE.

2. With Windows, DisconnectNamedPipe aborts ConnectNamedPipe operations with the error ERROR_PIPE_NOT_CONNECTED. The DisconnectNamedPipe call succeeds, and the pipe is no longer listening. With Wine, the DisconnectNamedPipe call itself fails with ERROR_PIPE_LISTENING, and the pipe is still listening.

3. With Windows, if the server breaks the pipe by closing its handle, the client can finish reading the remaining data in the pipe. Once the data is gone, reading from a broken pipe fails with ERROR_BROKEN_PIPE. Writing to a broken pipe fails with ERROR_NO_DATA. With Wine, once the server breaks the pipe, the client cannot read the remaining data, and I/O on a broken pipe fails with ERROR_PIPE_NOT_CONNECTED. (Exception: ReadFile on a server pipe still returns ERROR_BROKEN_PIPE.)

4. Calling ConnectNamedPipe on a broken server pipe fails with ERROR_NO_DATA on Windows, but ERROR_NO_DATA_DETECTED on Wine.

My test program is at: https://gist.github.com/rprichard/8dd8ca134b39534b7da2733994aa07ba. It passes on XP, Vista, Win7, and Win10, with the exception of testChangeMaxInstancesAfterClosingLastServerHandle, which passes on Vista and up. A couple of the more interesting tests are testDisconnectAtStartup and testReadFromBrokenClientPipe:

testDisconnectAtStartup:

// Calling DisconnectNamedPipe on a new pipe successfully transitions it to a

// "Not Connected" state. The second DisconnectNamedPipe call fails, and the

// client can't connect.

void testDisconnectAtStartup() {

const HANDLE server = assertValid(openServer(name(0)));

CHECK_SUCCESS(DisconnectNamedPipe(server));

CHECK(createFile(name(0)) == INVALID_HANDLE_VALUE);

CHECK_FAILURE(DisconnectNamedPipe(server), ERROR_PIPE_NOT_CONNECTED);

CHECK(createFile(name(0)) == INVALID_HANDLE_VALUE);

CHECK_SUCCESS(CloseHandle(server));

}

// If a client pipe is broken, rather than disconnected, the remaining data can

// still be read.

void testReadFromBrokenClientPipe() {

DWORD actual = 0;

Over over;

char buf[2] = {};

const HANDLE server = assertValid(openServer(name(0)));

const HANDLE client = assertValid(createFile(name(0)));

CHECK_SUCCESS(WriteFile(server, buf, 1, &actual, &over));

CHECK_SUCCESS(CloseHandle(server));

CHECK_SUCCESS(ReadFile(client, buf, 2, &actual, &over));

CHECK(actual == 1);

CHECK_FAILURE(ReadFile(client, buf, 2, &actual, &over), ERROR_BROKEN_PIPE);

CHECK_SUCCESS(CloseHandle(client));

}

I know that item #3 above breaks my winpty project (in principle), where a pipe server signals EOF by closing a pipe without disconnecting it. The winpty client can read all the output before hitting the broken pipe. I suspect winpty may not run on Wine anyway, though.

-Ryan