Yes, you're right; the word pipe in this context is related to pipelines in the Unix-like world (and, as we just covered in the last chapter, in PowerShell). The pipelines we worked with were unnamed and resided in the shell. The named pipe concept, on the other hand, gives the pipe a name, and by having a name, it utilizes the filesystem so that interaction with it is like interacting with a file. Remember the purpose of our pipelines, to take the output of a command and pipe it as input to another command. This is the easier way of looking at it: behind the scenes, each command fires off a process. So what the pipe is doing is allowing processes to communicate with each other with shared data. This is just one of several methods for achieving Inter-process Communication (IPC). Hence, to put it together, a named pipe is a file that processes can interact with to achieve IPC.

Don't forget one of the enduring themes of our adventures through Windows security: Microsoft has always liked doing things their own way. Named pipes in Windows have some important distinctions from the concept in Unix-like systems. For one, whereas named pipes can persist beyond process life time in Unix, in Windows they disappear when the last reference to them disappears. Another Windows quirk is that named pipes, although they work a lot like files, cannot actually be mounted in the filesystem. They have their own filesystem and are referenced with \.pipe[name]. There are functions available to the software developer to work with named pipes (for example CreateFile, WriteFile, and CloseHandle), but the user isn't going to see them.

Let's examine the concept as implemented in Windows a little deeper. I gave examples of functions for working with named pipes. Those are pipe client functions. The initial creation of the named pipe can be done with the CreateNamedPipe function—a pipe server function. The creator of a named pipe is a pipe server, and the application attaching to and using the named pipe is a pipe client. The client connects to the server end of the named pipe and uses CreateFile and WriteFile to actually communicate with the pipe. Although named pipes can only be created locally, it is possible to work with remote named pipes. The period in the named pipe path is swapped with a hostname to communicate with remote pipes:

The server-client terminology is no accident. The pipe server creates the named pipe and handles pipe client requests.