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