On Wed, 3 Aug 2011, Francois Gouget wrote: [...]
I sort of modeled this after ipconfig's ipconfig_vprintfW() function. However that function has a WriteFile() fallback in case WriteConsole() fails. But I don't see what's the point of this or when using WriteFile() instead of WriteConsole() would work. So I'm hoping someone can enlighten me as I see no reason for these two tools to handle things so differently. But in any case I see this as being the subject of a separate patch so I think this one can go in.
So I think I figured that part out. If I write a simple test application that just does a WriteConsoleW() call and run it on Windows XP SP3, I get the following:
* foo.exe -> Works.
* foo.exe >foo.txt -> WriteConsoleW() fails, foo.txt is empty.
* foo.exe | more -> WriteConsoleW() fails, the message is lost.
So ipconfig must have been written so that it works on Windows even if its output is redirected. In Wine applications don't need to fall back to WriteFile() because that's already done by WriteConsoleW().
So the question is: Do we care if these applications don't work right on Windows if their output is redirected?
Or from a different point of view: Should these applications take advantage of this Wine-specific behavior or stick to the letter of the API?
(Similarly Wine's WriteConsole() will accept a NULL lpNumberOfCharsWritten parameter, not Windows (up to XP SP3 at least). So if we decide our apps are Wine-only, then we could get rid of these annoying 'count' variables.)