GNOME Bugzilla – Bug 141102
Console windows allocated by g_warning() etc look too DOS-like
Last modified: 2011-02-18 16:08:02 UTC
The g_warning() etc functions allocate a console window for the application if stdout and/or stderr aren't valid. This is the case for GUI applications that have been started without any stdout and/or stderr I/O redirection. It's very common for GIMP users on Windows to report that various warnings and error messages are shown in "DOS boxes", "MS-DOS windows" etc. Some even go so far as to hint that GIMP somehow actually is an MS-DOS program. Apparently the default 80x25 white-text-on-black-background console windows are so intuitively associated with MS-DOS that people immediately get into this "DOS box" mindframe. (Some even suggest "why not print the text in an error message window instead". Sheesh, isn't that what it is? And why call it a "box", other rectangular windows are not commonly called "boxes", are they? Few even know the real (AFAIK) meaning of a "DOS box", i.e. a virtual 16-bit machine.) The attached patch attempts to avoid this "DOS box" association by making the console window more wide and less high, and brightly coloured...
Created attachment 27089 [details] [review] Suggested patch Please test especially on Win9x.
Comment from bug #137796: BTW, a code example how to prevent console windows from being closed is at http://www.codeproject.com/cpp/cppforumfaq.asp#cons_appcloses . A bit of a hack, but presumably works. It looks up the HWND corresponding to the console window by setting the title temporarily to some hopefully unique string (this is the hackish part), then uses GetSystemMenu and DeleteMenu to remove the SC_CLOSE menu entry from the console window's system menu (which apparently also means that the 'X' button gets removed. On win2k and newer, there is also the GetConsoleWindow call.
After lengthy discussion on gimp-developer and gtk-app-devel, it seems that an overwhelming majority is of the opinion that GLib should never open any console window by itself. It's just too confusing to end-users. Developers can always redirect stdout and stderr of GUI applications to a file or pipe if they need to look at them. End-users can be instructed to do so if necessary. While working on gmessages.c, it would be a good idea to remove the pid from the messages on Windows. It is quite useless. Windows end-users aren't used to deal with pids. The program name is enough. If it hasn't been set with g_set_prgname(), ask Windows what the .exe's file name is, and use that. Also, there shouldn't longer (if there ever was) be any reason to use stdio and not write() in gmessages.c on Windows.
Created attachment 31853 [details] [review] Suggested patch Will apply this to HEAD right away, and to glib-2-4 too in a few days unless somebody objects?
Patch applied to HEAD and glib-2-4. Goodbye AllocConsole.
*** Bug 154979 has been marked as a duplicate of this bug. ***
*** Bug 156546 has been marked as a duplicate of this bug. ***
*** Bug 163740 has been marked as a duplicate of this bug. ***
This bug has nothing whatsoever to do with bug 163740. Please restore that bug to its prior status. xanthian.