Actually, I think the issue might be that pipes are done differently on windows -- at least, this is true for any command-line usage (whether using the standard MS-DOS "command.com" or something else, like a windows port of bash). Based on my own experience using pipeline commands on windows and *nix, I have drawn the following conclusions (not backed up by any authoritative docs, but the behavior I observed seemed to make a pretty clear case):

Basically, on *nix, when a command line involves two or more processes in a pipeline, the processes are loaded in reverse order: last one on the command line starts first (and waits for input), and the first one is the last to be started. As data flow through the pipe, potentially all processes will be active simultaneously (unless the first one quits before its pipeline buffer fills -- I think a common buffer size is 8K); output from the tail end process will begin to appear as soon as it finishes its first buffers-worth of data.

On windows, the processes are run one at a time in lock-step: the first one runs, and the OS stashes its output in temp storage somewhere (presumably on disk, or using swap, or something). When its done, it exits, the next process starts, and the OS feeds it the stuff that was gathered from the first one. And so on for each successive process in the pipeline.

Would this mean that open2 would never work properly on windows? I don't know -- I never tried it.