my $in = new FileHandle "<&STDIN";
    my $out = new FileHandle ">&STDOUT";
    autoflush $out;
[download]

What this allows you to do is to treat STDIN and STDOUT (keyboard and monitor, essentially) as if they were any old descriptor. Thus, you can have a commandline app that doesn't care if it's talking to a person at the keyboard or a telnet session.

This works under Unix cause everything in Unix is treated (for all practical purposes) as if it's happening on a VT-100 terminal. Each window is treated by the kernel as its own process with its own input and output. The input and output (generally) is the same for all your windows, but the kernel doesn't make that optimization.

Windows does, which means that STDIN isn't an attribute of a given window, but of the OS as a whole. Thus, the problem.

It's easy to get around - you just have to telnet to yourself. :)

I still don't get it. With that fragment, my code can write to $out and it goes to the same place as STDOUT, right?

use strict;
use warnings;
use FileHandle;

    my $in = new FileHandle "<&STDIN";
    my $out = new FileHandle ">&STDOUT";
    autoflush $out;

print $out "Hello World!\n";
[download]

This works just fine for me, in that the string appears on the console window just like it normally does.

That's exactly the point. Now, imagine this - you have a program that can be launched either from the commandline or set up as a telnet server. Doing this kind of binding, your code will always work the same, irregardless of whether or not you're a telnet server or commandline.