From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <3F0DC750.9040707@place.org>
From: Stephen Wynne <stevemw@place.org>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02
MIME-Version: 1.0
To: 9fans@cse.psu.edu
Subject: Re: [9fans] Fork: useless and painful?
References: <5b68877f993232fb23394caf30309e12@plan9.bell-labs.com> <3F0DC049.7030300@place.org> <006601c3471d$7a06de40$b9844051@insultant.net>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Date: Thu, 10 Jul 2003 13:06:40 -0700
Topicbox-Message-UUID: f4214f3a-eacb-11e9-9e20-41e7f4b1d025

And I just got a suggestion to use named pipes, presumably because
they have a richer set of buffering options.

I don't think named pipes help one with the situation where a
DOS program does direct console I/O. I think "net use" does
that when it prompts you for a password; you get the idea,
in any case. My line buffering app is cacls.exe (don't laugh).

I don't think I am going to work on this more right now, but
if I were, I would try to replace the standard I/O via plain pipes
connected to winsock sockets with standard I/O through dedicated
but hidden consoles for each connection. I think it's possible.

As an aside, UWIN's rshd is just as bad, and Cygwin's is worse.
I'm guessing Microsoft's telnetd is fairly brain dead in this
respect, as well.

boyd, rounin wrote:
>>Where is the joy in computing? Win32 is making me wonder.
>
>
> been there, done that.  a repeat of SysVile (sic) R3:
>
>     you could select on a socket or poll on a stream,
>     but they would not interoperate
>
> on NT you need to call WaitForMultipleObjects() iirc and
> that doesn't work on WinShlock (sic) sockets etc, so you
> have to use a threaded implementation.
>
> for extra points, if the NT CreateSocket() call finds that you
> are _not_ WinShlock (sic) the call fails and returns -6 iirc.
>
>