locales, unicode and ansi with msvcrt (bug 8022)

[Ann & Jason Edmeades]

>> Anything else I can test, or am I ok to put file tests into msvcrt test
>> buckets and allow the msvcrt unicode printf and friends to convert to
>> non-unicode using the console codepage before being output to the file
>> handle?

>Why don't you simply run native MSVCRT under +relay,+snoop and see how it
>does things under win9x and NT based systems instead of inventing the
wheel?

I started with that, but the problem is msvcrt doesn't call anything in
order to do the translations, which are definitely happening. What I think
is being done is that at startup msvcrt uses GetACP to retrieve a codepage,
and then converts 0x00, 0x01, 0x02 -> 0xff into wide chars. It then does
some playing around producing non-unicode versions in upper and lowercase
plus a character mapping so it knows what each character is (LCMapString) so
I strongly suspect it is simply using caching to do the conversion.

However, since I cant snoop, relay or debug (I tried - far too confusing),
that left the 'replicate via tests' alternative...

I was surprised that GetACP was the only codepage call I could see msvcrt
making (rather than consolecp - I guess its because you don't know/care if
its going to the console or a file?).

My current plan, unless you have strong objections, is to make the wprintf
msvcrt routines use WideCharToMultiByte on the string into the GetACP
codepage before being written out, and add file tests for this into the
msvcrt testsuite

Jason