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