Gads, I'd love to, but now I'm home, and you say it doesn't work in W2K, and it's trivial in unix... So I guess I'm sitting on my hands for the moment... *grin*

However, in rough, I set up a couple of braindead pipe scripts (server and client) using the Win32::Pipe module first. Of course, it worked for that case. In fact, it works almost always on my dev box. When we try it on the server, Dr. Watson steps in.
I've never managed to crash perl before...

So I have the scripts talk to each other briefly. It works perversely well. I then replace the client pipe stuff with the Win32API::File code you showed me earlier. Now, when the client sends "garbage" to the server, the server reports that it got something like

[garbage*
]
[download]

When the server responds to the client, the client shows only the smiley and newline, without the data I want.

Sheesh. This is probably either (1) never before seen or (2) some Windows-specific peculiarity I should already have figured out...it has that feel.

For completeness, I'm running AS build 620 on my dev box, NT4. The server was running 623/NT4. We downgraded the server to 620, no help.

I found version 20000216 of Win32::Pipe on roth.net, installed that, and now I'm able to do a vanilla perl file open, but it passes me the same sort of garbage the Win32API::File version was.

I am trying to interpret this as good news for me, but I haven't succeeded yet...

#  Vanilla file implementation

open( PIPE, "+<" . $PIPE_NAME )
    || die "couldn't open pipe";

print PIPE "vanilla!\0";

my $result = <PIPE>;
print "Server said [$result]\n";

foreach (split //, $result) {
    print  "[" . (ord $_) . "]";
}
print "\n";

close PIPE;
[download]

Server read: [vanilla! { require $path; };
]
[118][97][110][105][108][108][97][33][0][123]
[32][114][101][113][117][105][114][101][32][36]
[112][97][116][104][59][32][125][59][13][13][10]

and...

Server said [{ require $path; };
]
[123][32][114][101][113][117][105][114][101]
[32][36][112][97][116][104][59][32][125][59][13][10]
[download]

Perhaps I'd just fumbled the open call, earlier, when I couldn't get the vanilla file version working.

Clearly, though, I'm getting too many characters. The \0 at the end of my client send was pure desperation--sending a \n doesn't stop it correctly either.