redirecting debug output to a file on Windows

Dirk Hohndel dirk at
Thu Feb 2 15:04:10 PST 2017

On Fri, Feb 03, 2017 at 12:46:51AM +0200, Lubomir I. Ivanov wrote:
> ok, so i've created a standalone test case and it appears that this
> type of redirection never worked.
> that's because the application EXE is a GUI application (-mwindows)
> and even if we redirect text to some console (via AttachConsole()), we
> cannot redirect the output of the executable call to a file, like so:
> gui_windows_test.exe > test.log
> because the GUI executable itself has no output, if that makes sense.

I would have bet that it worked. But I looked through the email archive
and couldn't find actual PROOF that it worked...

> solutions:
> 1) my last writes separate log files for stderr / stdout
> it can write the output to the same file with this (mod in
> windows.c::subsurface_console_init()):
> const char *location = logfile ? "subsurface.log" : "CON";
> console_desc.out = freopen(location, "w", stdout);
> *stderr = *stdout; // seems safe
> setvbuf(stderr, NULL, _IONBF, 0); // disable buffering
> setvbuf(stdout, NULL, _IONBF, 0);

I think having it write to two files is fine. I really see this as a very
rarely used oddity if we really need someone to be able to capture debug
output on Windows. This shouldn't be necessary and I don't want us to
spend too much time on making it perfect.

One question, though: is the other win32console option still needed?

> 2) create a windows console application
> stderr / stdout redirection of a windows console application will work for sure.
> QMAKE had this:
> CONFIG += console
> for CMAKE:

I guess I'm confused what the pros and cons are... i.e., we gain the
ability to rediret stdout/stderr, what do we lose?


More information about the subsurface mailing list