(Dropped gnome-hackers and gnome-announce-list from the To: list. Not that I presumably would be able to post to them anyway.) Harring Figueiredo writes: > - Don't open console windows [Tor] > > does that mean that even if we write to stderr/stdout, it will not open the > console window ? Yes, if it's a GUI application. But it didn't earlier either! If you just wrote to stderr or stdout using printf() etc, or to file descriptors 1 or 2 using write(), no console window would open. The only GLib-related thing that opened a console window were the g_warning(), g_error(), g_log() etc functions. Please note that this applies only to GUI (or "Windows") applications, which you have explicitly specified when linking with the -mwindows option (gcc and ld) or /link /subsystem:windows (MSVC and LINK). By default both gcc and MSVC produce "console" applications where then standard output and standard error are connected to the console window in which they were started. (And if you start such an application from Explorer (by double-click on the file name, shortcut, or Start Menu), Windows will allocate a console window automatically.) (MSYS's shell and/or rxvt terminal amulator, and maybe Cygwin's shell if you set the CYGWIN environment variable suitably, do some special magic, and the standard output and standard error of GUI applications also are visible in the shell's window.) > If so, where is that being redirected to ? Nowhere. I.e. not even to the NUL: device. The file descriptors (a C library level concept on Windows) 1 and 2 aren't connected to valid Win32 file handles. The standard ferror() function doesn't notice anything odd. You have to test for _get_osfhandle(fileno(stdout)) == INVALID_HANDLE_VALUE (and ditto for stderr). --tml _______________________________________________ gtk-list@xxxxxxxxx http://mail.gnome.org/mailman/listinfo/gtk-list
