Binding STDIN/STDOUT and why it doesn't work on Windoze

Ok. I think we've got a few misconceptions here.

Firstly, I'm not talking about logging into a computer via telnet, then running it. I'm talking about a program that acts as a telnet server as well as a console program.

Given that, the program doesn't know whether it is talking to a monitor or a telnet socket. So, it cannot have a line similar to "print STDOUT" or just "print". It has to talk completely in terms of descriptors, like $out.

Now, the way (on Unix) to do this is to bind STDIN and STDOUT so that you can address them as filehandles.

Tangent: a filehandle is really a descriptor. You're sending information to some place. From a syntatical point of view, it doesn't matter whether or not that place is a file, a monitor, or some IP connection to another machine. The OS is what routes the data to the file, monitor, or IP connection.

So, you are now able to (on Unix) address STDIN/STDOUT as descriptors.

The problem with Windows is that you cannot bind STDIN/STDOUT as descriptors. So, the way around is to telnet to yourself, and treat those as descriptors. The information simply routes right back to yourself. :)

Comment on Binding STDIN/STDOUT and why it doesn't work on Windoze

Replies are listed 'Best First'.
Re: Binding STDIN/STDOUT and why it doesn't work on Windoze by John M. Dlugosz (Monsignor) on Jul 16, 2001 at 19:05 UTC
From a syntatical point of view, it doesn't matter whether or not that place is a file, a monitor, or some IP connection to another machine. The OS is what routes the data to the file, monitor, or IP connection. ... The problem with Windows is that you cannot bind STDIN/STDOUT as descriptors. Under win32, the standard input, output, and error are file handles just like any others. The underlying OS primitive WriteFile is given a file handle and a buffer to write. If they couldn't be treated in a uniform manner, redirection on the command line wouldn't work, would it? I think I see what you're getting at. The program can run as a normal command-line, writing to stdout. Or, you can invoke it with some flag and it listens to a socket and accepts a connection, and then uses that socket instead of stdout. So, the program is written to use $out for all its writes. Why doesn't that work for you? It works fine for me. I've written code that takes a file descriptor as a parameter, and it has no problems with passing \*STDOUT. Other than being predefined, STDIN and STDOUT behave just like any other file descriptor in Perl. You could re-point STDOUT to the socket handle, for example, instead of using $out in all your print statements. (or you could use select to make $out the default). —John	[reply]
Re: Re: Binding STDIN/STDOUT and why it doesn't work on Windoze by dragonchild (Archbishop) on Jul 16, 2001 at 19:30 UTC
Check out 67963 for more info. (My old username was satchboost.) The problem wasn't so much writing to a bound STDOUT, but selecting on a bound STDIN. shrugs	[reply]
Re: Re: Re: Binding STDIN/STDOUT and why it doesn't work on Windoze by John M. Dlugosz (Monsignor) on Jul 16, 2001 at 22:54 UTC
re `select RBITS,WBITS,EBITS,TIMEOUT` on STDIN: ah, now there is a difference. Under Win32, it's only implemented for sockets! So bindings and handles etc. isn't really the issue. Rather, the particular function you wanted to use doesn't work on all concrete types. Specifically, yes on sockets, no on the Console streams. FWIW, that's because Win32 doesn't have a function exactly like `select` in Unix. But the implemetation of the sockets library does, to meet the Berkley Sockets standard. But that function only works for handles created by that system. Win32 has `WaitForMultipleObjects` and if the object in question is a file handle of some kind, it will be signaled when an asyncronous operation completed; or more specifically for the Console Input device, signaled when input is available. The way you normally structure such a program in Windows is not nativly supported by Perl. I suppose a XS module could be written... Or, a layer to emulate the `select` model using a helper thread and buffers would be a bit of effort, and I guess the function was not important enough for ActiveState to worry about <g>. —John	[reply] [d/l] [select]