On Sun, Dec 22, 2019 at 10:04:20PM +0000, Adam D. Ruppe via Digitalmars-d-learn wrote: [...] > Regardless, I'm pretty well of the opinion that fwrite is the wrong > thing to do anyway. fwrite writes bytes to a file, but we want to > write strings to the console. There's other functions that do that. [...]
Would it make sense for std.stdio.write* (the package global functions, as opposed to File.write*) to use the Windows console output functions instead of proxying to libc? Alternatively, we could change std.stdio.File to check if the current file descriptor is the console (fd == stdout && stdout == console, however you figure that out in Windows), and silently switch to the Windows console output functions instead of libc. We *are* already wrapping libc's FILE*, why not wrap the Windows console output functions as well. Mixing raw libc printf with std.stdio.write* is a bad idea anyway; do we really need to support that?? Though calling fflush(stdout) may not be amiss, just to alleviate sudden breakage and ensuing complaints. And of course, this only applies to Windows. On Posix libc is pretty much still the standard way of working with console output. T -- VI = Visual Irritation