Win32 NamedPipes and "All pipe instances are busy"

When I began using named piped with the excellent Win32 implementation of Smalltalk from http://www.object-arts.com/ called Dolphin Smalltalk. I was convinced that Windows XP named pipes had been abandoned for sockets.
I would open a pipe, receive

All pipe instances are busy

so I would try with Perl. No problem. Then the real evil: open a named pipe with Perl and Perl could write and read. Open a named pipe with Perl and then try to write or read with Tcl and

resource temporarily unavailable

yet again.

What was infuriating was that even with the disconnect issues noted in my last blog, Perl would reconnect clients to my pipe in a single shot. Tcl could not even read that pipe.

Had I been using the screen utility under Cygwin, the answer might have come earlier. It required 4 CMD sessions to be open on my left monitor. The top 2 opened the same pipe with Perl. Perl began writing to an instance of the pipe in screen 3 and screen 1 dutifully echo'd the output. Now amazement: in screen 4 I simply redirected my bothersome buffered interpreter to dump pages of docs to that same pipe and PRESTO screen 2 was dumping that output from an instance of the named pipe.

Now more evil. I close everything. Open one instance of that same named pipe. Now anyone can read and write to the pipe. Including Tcl.

No, I do not have any anti-virus software running: I suspect that this is a gift from Microsoft security upgrades.
Now when I want a pipe for the console of my choosing, I create it, close it, create it again. No problem. The 'one instance' accepts the first client.
There is a commercial ACL utility which could no doubt pin down the access issue.
Now just wait until I upgrade to Vista ...

Now to get a utility pkg written for Dolphin Smalltalk to allow read and write streams to interact correctly with a Win32 named pipe as if it were a file.