Re: GLib 2.5.4 released [unstable]

[Tor Lillqvist <tml iki fi>]

(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