On 3 February 2017 at 01:04, Dirk Hohndel <[email protected]> wrote: > 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 patch...it 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?
yes, it is. but it's only viable for a GUI build (-mwindows) and if the user starts the the EXE from a shortcut. in such a case a console window will be created explicitly, so that the user can look at stdout/stderr if she/he needs to. --win32log on the other hand will create a console window (so performs a win32console, not really needed), but leaves it empty and writes all output to log files. that's how it works ATM. it's not super refined, but it's for debugging after all. > >> 2) create a windows console application >> stderr / stdout redirection of a windows console application will work for >> sure. >> >> also define WIN32_CONSOLE_APP (-DWIN32_CONSOLE_APP) >> >> QMAKE had this: >> CONFIG += console >> >> for CMAKE: >> http://stackoverflow.com/questions/2753761/how-do-i-tell-cmake-not-to-create-a-console-window > > 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? > a console window is always created when the user starts the EXE which is a -mconsole application (not a -mwindows GUI application). so imagine a desktop shortcut on Windows - the users starts it, but first a console windows pops up (as this EXE is a console app) and only then the GUI appears. if the user closes the console Window the GUI will close as well. that can be classified as a downside, but depends on the POV. lubomir -- _______________________________________________ subsurface mailing list [email protected] http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
