When you operate on named pipes, you have a choice of opening them in PIPE_WAIT mode or PIPE_NOWAIT mode. When you read from a PIPE_WAIT pipe, the read blocks until data becomes available in the pipe. When you read from a PIPE_NOWAIT pipe, then the read completes immediately even if there is no data in the pipe. But how is this different from a PIPE_WAIT pipe opened in asynchronous mode by passing FILE_FLAG_OVERLAPPED?

The difference is in when the I/O is deemed to have completed.

When you issue an overlapped read against a PIPE_WAIT pipe, the call to Read­File returns immediately, but the completion actions do not occur until there is data available in the pipe. (Completion actions are things like setting the event, running the completion routine, or queueing a completion to an I/O completion port.) On the other hand, when you issue a read against a PIPE_NOWAIT pipe, the call to Read­File returns immediately with completion—if the pipe is empty, the read completes with a read of zero bytes and the error ERROR_NO_DATA.

Here's a timeline, for people who prefer tables.

Event Asynchronous PIPE_WAIT PIPE_NOWAIT
pipe initially empty
ReadFile Returns immediately with ERROR_IO_PENDING Returns immediately with ERROR_NO_DATA
I/O completes with 0 bytes
time passes
Data available I/O completes with n > 0 bytes

If you use the PIPE_NOWAIT flag, then the only way to know whether there is data is to poll for it. There is no way to be notified when data becomes available.

As the documentation notes, PIPE_NOWAIT remains solely for compatibility with LAN Manager 2.0. Since the only way to use pipes created as PIPE_NOWAIT is to poll them, this is obviously not a recommended model for a multitasking operating system.