FW: locales, unicode and ansi with msvcrt (bug 8022)

[Ann & Jason Edmeades]

Detlef - Thanks... You can see what I added as an afterthough!

Eric, Thanks for taking the time to look at this and for your answers 

>- ensure that all msvcrt's function needing to write unicode strings 
>behave as follows:
>    + if the output handle is a console handle, use WriteConsoleW -> 
>this is the only way to get the proper output
>    + if not, convert the unicode string to ansi string and use WriteFile
>For the implementation, note that the call to WriteConsoleW will fail if 
>the output stream is not a console handle, ie has been redirected to a 
>file, pipe... => which makes the coding rather straightforward

I disagree... 

- My tests have shown that when writing to files as well, the output depends
on whether the file was opened as text or binary. If opened as text, then it
comes out in ansi. 

- What makes you say calling WriteConsoleW is the only way to get proper
output. WriteFileA will call WriteConsoleA for a console handle, so the
calling code can then not need to care if it's a console or file handle.

- As has been seen when trying to work out what windows does, it converts as
it parses character by character which is better than formatting into
Unicode, then converting to ansi (possibly twice with a heapalloc inbetween
to allocate a temporary buffer). This is exactly the change my patch
introduces.

- Finally, debugging under windows seems to show it uses _putwc which does
wctomb in memory, followed by a flush which results in a writefile (even for
a console) call.

All of this would point at the fact the patch as written is functionally
correct, I think. What do you think?
 
>the current issue is that all the w-functions end up calling WriteFile 
>which is wrong
Right, that's what I am looking at solving, and the patch will address all
the *printf calls. There may be another exercise to look into some of the
other msvcrt calls but I'm concentrating on the issue at hand to start with.

>NB : in your test cases, don't use L"xxx" strings, they won't work when 
>your test case is compiled under linux

Sure - I was doing it so the simplicity of the tests stood out (and I was
compiling them on windows and running under wine). The tests added in msvcrt
did not use this syntax...

Jason