writing to stdout in an windows app without a console

Duncan Coutts duncan.coutts at worc.ox.ac.uk
Tue Feb 15 16:47:43 EST 2005


This might be a bug report but it's definitely a question on what the
behaviour should be:

On windows if you link using "--subsystem windows" then your program
starts without popping up a console. This is good for GUI apps (and we
would like to make it the default when using gtk2hs on win32 by adding
--subsystem windows to the linker flags in the gtk package file).

Apparently, Windows default behaviour if a program without a console (ie
a gui program linked using --subsystem windows) writes to stdout is to
silently discard the output. Though exactly which bit of the windows
tech stack implements this behaviour I am not sure.

With ghc on windows, upon writing to stdout you get an IO exception:
Fail: <stdout>: hPutChar: failed (Bad file descriptor)

One can see how this is reasonable behaviour since there really isn't
any output handle (unlike on unix where there would be a valid stdout fd
but it'd be connected to /dev/null). On the other hand it is not so
helpful since it means anyone who's not aware of this behaviour will
bring their program to a immediate halt without any obvious explanation
as to what went wrong.

In fact the only way to see what really happened is from a windows
console:

hello.exe 2> err.txt

So the stdout is still disconnected from the console (despite launching
the program from the console!) but stderr, where the IO exception
message gets written, can be captured.

So I'm wondering if it would be better to arrange that output to
stdout/stderr gets silently discarded in the case that stdout/stderr are
not connected rather than raising an exception. I have no idea how
difficult this hack would be to implement.

Otherwise for our windows users who ask:
        "how do I get rid of that ugly black window behind my gui app?"
we'll have to say
        "use --subsystem windows BUT!... never use print/putStr and
        friends or your program will be killed instantly! This includes
        making sure any other Haskell libraries you use do not use the
        standard output or print any error messages (eg using
        Debug.Trace)"

Duncan



More information about the Glasgow-haskell-users mailing list