Dealing with stdin/stdout/stderr is much harder on Windows than on Unix. On Unix, you have the stdio layer (FILE *) and the file descriptor layer. On Windows,

Dealing with stdin/stdout/stderr is much harder on Windows than on Unix. On Unix, you have the stdio layer (FILE *) and the file descriptor layer. On Windows, you have multiple stdio layers (one for each C runtime you have loaded in your process), multiple file descriptor layers (again, one for each C runtime), and the native "standard handles" layer (GetStdHandle/SetStdHandle). On Unix, to redirect stdout is just a dup2() call, perhaps preceded by a fflush. But on Windows, there's no handle equivalent of dup2() (DuplicateHandle can duplicate a handle, but it will give you a new handle; you cannot use it to replace an existing handle). So you have to either use SetStdHandle, which won't work well on multithreaded programs (see the comments for the blog post at http://blogs.msdn.com/b/oldnewthing/archive/2013/03/07/10399690.aspx http://blogs.msdn.com/b/oldnewthing/archive/2013/03/07/10399...), or call a dup2() equivalent on each C runtime the process is using, which won't work if (as in the second bug report in this article) another component is directly using the underlying handle.