What are the differences between pipes in Windows and Linux?

Question

score 25 · Accepted Answer · answered Oct 10 '08 at 16:37

25

One difference that I know of, is that named pipes under Linux are actual entries in the filesystem (you'll see it in a directory listing, they have a special type), whereas on Windows they are stored in some magical repository somewhere (they are all accessed via the path "\\.\pipe\".

Secondly, in Linux you can just write/read from pipes as if they were any other file, using standard file IO methods. Whereas on windows, you have to use the special 'Pipe' functions which are part of the Win32 API.

I like linux's method better, because it lets me use pipes with any app I want. Eg:

mkfifo pipe.wav
decodeMP3 song.mp3 --out pipe.wav &
encodeAVI video.mpeg pipe.wav --out video.avi

This lets me pipe the output of the MP3 decoder directly into the video decoder, instead of having to first decode the entire MP3 into a WAV file on disk. It's handy if you have a dual-core CPU, because then you are running both operations at once, for a nice speedup.

answered Oct 10 '08 at 16:37

davr

18,877
17
76
99

3

Downvote. On Windows I can use CreateFile, ReadFile, WriteFile, ReadFileEx, WriteFileEx function to named pipes. Only server have to use CreateNamedPipe. There are pipes' functions for synchronization of pipe creation and binding but these can be replaced by usage of named wait events if not networked pipes needed. – Dzmitry Lahoda Jan 25 '13 at 10:06
1

And Windows local Named Pipes use Memory Mapped Files beneath. It means that pipe stores data in memory or in pagefile.sys. – Dzmitry Lahoda Jan 25 '13 at 10:14
Instead of using a root filesystem, Windows has a root object tree that gets persisted in the registry and populated dynamically. The ``\\.\`` and ``\\?\`` UNC-like prefixes (they're not really UNC) get mapped to the native object manager `\??` virtual directory. This looks in your logon session device links in `\Sessions\0\DosDevices\[LOGON ID]` and then the system device links in `\Global??`. – Eryk Sun Mar 29 '17 at 10:29
The system device `\Global??\Pipe` is an object symbolic link to `\Device\NamedPipe`. This device is managed by the NamedPipe file system (i.e. `\FileSystem\Npfs` in the object tree). You can list all of the named pipes on the system. It doesn't support real directories, but often pipes are created with backslash in the name to emulate this, e.g. `\Device\NamedPipe\Winsock2\CatalogChangeListener-xxx-0`. – Eryk Sun Mar 29 '17 at 10:36
@ErykSun if I create a namedpipe, Is it possible to find it in registry or somewhere else?@Eryk Sun – vincent Jul 10 '20 at 06:10
1

@vincent, I don't completely follow the intent of your question. The pipe file is created in the named-pipe filesystem, which is mounted at the root path of the pipe device, i.e. "//./pipe/". You can list the pipes in the directory via `FindFirstFileW(L"//./pipe/*", &findData)` and `FindNextFileW`. You can check for the existence of a named pipe via `GetFileAttributesW(L"//./pipe/SomeNamedPipe")`, but it does consume a pipe connection. If it fails with `ERROR_PIPE_BUSY` (231), then the pipe exists but no instance is available. – Eryk Sun Jul 10 '20 at 07:14
@ErykSun That's what I want to know. Thanks alot. – vincent Jul 10 '20 at 08:22

lkreinitz · Answer 2 · 2016-07-21T19:09:49.110

10

Another important difference

Under windows

A | B | C

Until A is done with it's output B does not start reading, The same for B output being read by C

*nix hooks the input and output together so that C can read B's output and B can read A's output while A and B are still running

The throughput is about the same but output shows up faster with *nix.

edited Jul 21 '16 at 19:09

answered Jul 21 '16 at 19:04

lkreinitz

281
3
9

This is what I was looking for: I seemed to remember this was the case but wasn't sure. Thx! – EvertW Sep 10 '19 at 11:33
1

A consquence of this is that the size of the buffers can be much smaller on UNIX. UNIX pipes let you handle any amount of data, whereas Windows pipes grind to a halt when chewing on enough data. – EvertW Sep 10 '19 at 11:37

score 5 · Answer 3 · answered Oct 10 '08 at 19:23

Under Linux (and *ix in general), "everything is a file". You can read/write/seek pipes and sockets and devices with no restrictions, insofar as those operations make sense.

Whereas Windows has a far less unified architecture for these different types of objects. Though I couldn't tell you the details, I know that buffering of pipes is considerably different between Windows and Linux, so you may run into difficulties there.

Also, one common Unix-y use of pipes is to fork() a subprocess and then communicate with it via a pipe (the parent opens one end, the child opens the other end). Under Windows, that kind of thing just isn't possible. IPC mechanisms are quite different.

A child process in Windows obviously can inherit a pipe handle, so I suppose you mean `fork()` isn't possible. The kernel can fork; it's a pretty straight-forward use of basic memory manager services, but implementing this in the Windows API is probably almost impossible. Even on Unix, improper use of fork can be a disaster, and that's on a system that was designed for it where people are creating solutions with fork in mind. — Eryk Sun, Mar 29 '17 at 10:43

score 4 · Answer 4 · edited May 23 '17 at 12:17

4

What are the differences between pipes in Windows and Linux?

4 Answers4