by Michael S. Kaplan, published on 2010/12/01, original URI: http://blogs.msdn.com/b/michkap/archive/2010/12/01/10098812.aspx
I remember a few years ago when I had someone who was doing some programming work in the console asked why there had to be separate encoding settings for the inout stream and the output stream in the console.
I pointed out to him that these were streams, and that every stream had its contents in some encoding....
He admitted this was true, though he still felt it was needlessly complex.
Then just yesterday, in a comment to my Conventional wisdom is retarded, aka What the @#%&* is _O_U16TEXT? blog, NB asked:
Can you somehow use this to make a "pipe-utility-program" which converts the standard output of other console programs (outputting OEM/ANSI/"utf8") to O_U16TEXT?
Maybe there is something like that already?
And suddenly a new answer to the old question appears!
Because if you set the encoding on the input handle to the encoding that the one program outputs, this has no impact on what you do with the output stream.
You can then even use the techniques in Conventional wisdom is retarded, aka What the @#%&* is _O_U16TEXT? to make the output UTF-16, easily!
Now it is soon after this that the metaphor breaks down a bit...in the way thet STDOUT and STDERR are two different streams.
It makes sense to be able to treat them separately at times, to be sure.
But the case for them needing to be encoded differently is really quite a stretch, you know?
Now one of the most original uses of all this functionality I have ever seen related to a program that was changing the input and output code pages in all kinds of different ways with text that was also separately encrypted I doubt anyone would ave much luck trying to get anything out of it given the huge additional layers of complexity that were added....