Pipes come in several varieties:
Most of these attributes are determined when the pipe is created.
The first set of terms—inbound, outbound, and duplex—distinguishes the direction in which information flows through the pipe. Inbound and outbound describe one-directional pipes, where one side only writes and the other side only reads. An inbound pipe lets the client send and the server receive. An outbound pipe lets the server send and the client receive. A duplex pipe allows both sides to send and receive.
What the participants write determines whether the pipe should have a reading mode of type byte or type message. The reading mode helps the system decide when a read operation should stop. With a byte-mode pipe, a read operation stops when it either reaches the last byte of data in the pipe or else fills its reading buffer. With a message-mode pipe, however, a read operation stops when it reaches the end of a single message.
Internally, the system marks messages in a message-mode pipe by prefacing each newly written segment with a header stating its length. The programs on either end of the pipe never see the message headers, but ReadFile commands on a message-mode pipe automatically stop when they reach the end of a segment.
Pipes may also be either blocking or nonblocking. This attribute affects read, write, and connect commands. When any of these commands fail on a nonblocking pipe, the command returns immediately with an error result. On a pipe that allows blocking, the commands do not return until they succeed or an error occurs. Table 15.1 summarizes the ways in which blocking and nonblocking modes affect three operations.
Table 15.1: The Effects of Blocking and Nonblocking Modes
| Operation | Blocking Mode | Nonblocking Mode |
| ConnectNamedPipe | Blocks until a client connects to the other end. | Returns FALSE immediately. |
| ReadFile | If the pipe is empty, blocks until a message arrives. | If the pipe is empty, returns an error immediately. |
| WriteFile | If the pipe is nearly full, blocks until another process reads from the other end. | If the pipe is nearly full, returns immediately. For a byte-mode pipe, WriteFile will first write as much as it can. For a message-mode pipe, WriteFile returns TRUE and writes no bytes. |
A pipe may be named, in which case the creator has endowed it with an identifying name string, or it may be anonymous, meaning it has no name string. Like synchronization objects, such as mutexes and semaphores, a pipe may be given a name to help other processes identify it. Windows 98 does not support named pipes; it currently supports only anonymous pipes.
Anonymous pipes require less overhead but perform only a limited subset of the services named pipes can perform. They pass messages in only one direction: either server to client or client to server, but not both. Also, anonymous pipes do not work over networks. The server and client must inhabit the same machine.
Named pipes, which are supported by Windows NT, can do several things that anonymous pipes cannot. They can pass information in both directions through one pipe, connect across a network to a process on a remote machine, exist in multiple instances, and use more pipe modes. The ability to exist in multiple instances permits a named pipe to connect one server with many clients. Each instance is an independent channel of communication. Messages in one instance do not interfere with messages in another instance. Multiple instances of a single pipe result when one or more servers pass the same identifying name to CreateNamedPipe.
Under Windows 98, you cannot compile an application to use named pipes. Or, more accurately, you can compile the application without any errors, but any calls to the CreateNamedPipe API, which are integral to using named pipes, will simply fail.
The curious side of this is that you can compile the application under Windows NT and, once it has been compiled, it will run under Windows 98.
Rather unhelpfully, if you debug the NamedPipe demo (also discussed later in this chapter) under Windows 98, the ShowErrorMsg function will display a system error message reporting, “This function is only valid in Win32 mode.”