RE: writing to stdout in an windows app without a console
On Wed, 2005-02-16 at 14:49 +, Simon Marlow wrote: > On 16 February 2005 14:06, Duncan Coutts wrote: > > > On Wed, 2005-02-16 at 14:31 +0200, Krasimir Angelov wrote: > >> On Wed, 16 Feb 2005 12:01:06 +, Duncan Coutts > >> <[EMAIL PROTECTED]> wrote: > >>> What's your opinion of making writing to stdout fail without > >>> raising an exception when the application is compiled with > >>> --subsystem windows? > I've seen this behaviour vary between versions of Windows (maybe even > between versions of msvcrt, MS's C library). A strange experience we > had with the Visual Studio extension was that I was initially just doing > output to stderr from the DLL for debugging, which worked fine on my > machine but crashed on other people's machines. We had to remove all > uses of stdout/stderr from the Haskell DLL (including the runtime!) to > get it going reliably. Ok, fair enough. It sounds like with the improvements in ghc 6.4 we'll be able to turn the --subsystem windows on by default for gtk2hs when using ghc 6.4, though we'll still have to warn people not to use normal output functions. [and we'll have to fix all our demos! :-) ] Duncan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: writing to stdout in an windows app without a console
On 16 February 2005 14:06, Duncan Coutts wrote:
> On Wed, 2005-02-16 at 14:31 +0200, Krasimir Angelov wrote:
>> On Wed, 16 Feb 2005 12:01:06 +, Duncan Coutts
>> <[EMAIL PROTECTED]> wrote:
>>> What's your opinion of making writing to stdout fail without
>>> raising an exception when the application is compiled with
>>> --subsystem
>>> windows?
>>
>> I think the current behaviour is the right one. After all we don't
>> have valid stdout/stdin and I don't see any reason to hide this.
>
> True, but it's not the behaviour that other windows programming
> systems implement:
>
> For example MS's C library happily ignores output to stdout:
>
> #include
>
> int main () {
> int res_code = fprintf(stdout, "hello world!\n");
> fprintf(stderr, "res_code = %d\n", res_code);
>
> return 0;
> }
>
> now compiling with mingw's gcc:
> gcc testio.c -Xlinker --subsystem -Xlinker windows
>
> and from a windows console (ie not a msys / cygwin window)
>
> a.exe 2> err
>
> then saying "type err" gives us the output:
> res_code = 13
I've seen this behaviour vary between versions of Windows (maybe even
between versions of msvcrt, MS's C library). A strange experience we
had with the Visual Studio extension was that I was initially just doing
output to stderr from the DLL for debugging, which worked fine on my
machine but crashed on other people's machines. We had to remove all
uses of stdout/stderr from the Haskell DLL (including the runtime!) to
get it going reliably.
Cheers,
Simon
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: writing to stdout in an windows app without a console
On Wed, 2005-02-16 at 14:31 +0200, Krasimir Angelov wrote:
> On Wed, 16 Feb 2005 12:01:06 +, Duncan Coutts
> <[EMAIL PROTECTED]> wrote:
> > What's your opinion of making writing to stdout fail without raising an
> > exception when the application is compiled with --subsystem
> > windows?
>
> I think the current behaviour is the right one. After all we don't
> have valid stdout/stdin and I don't see any reason to hide this.
True, but it's not the behaviour that other windows programming systems
implement:
For example MS's C library happily ignores output to stdout:
#include
int main () {
int res_code = fprintf(stdout, "hello world!\n");
fprintf(stderr, "res_code = %d\n", res_code);
return 0;
}
now compiling with mingw's gcc:
gcc testio.c -Xlinker --subsystem -Xlinker windows
and from a windows console (ie not a msys / cygwin window)
a.exe 2> err
then saying "type err" gives us the output:
res_code = 13
which is the number of characters output. Upon an error it would have
been negative (according to the fprintf man page).
As I said before I don't know which part of the windows stack implements
this behaviour (papering over the fact there is no stdout handle) but it
is apparently standard behaviour.
Duncan
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: writing to stdout in an windows app without a console
On Wed, 16 Feb 2005 12:01:06 +, Duncan Coutts <[EMAIL PROTECTED]> wrote: > What's your opinion of making writing to stdout fail without raising an > exception when the application is compiled with --subsystem > windows? I think the current behaviour is the right one. After all we don't have valid stdout/stdin and I don't see any reason to hide this. Cheers, Krasimir ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: writing to stdout in an windows app without a console
On Wed, 2005-02-16 at 09:18 +0200, Krasimir Angelov wrote: > Hi Duncan > > With ghc-6.4 the output from Debug.Trace.trace will be redirected to > the debug console when the application is compiled with --subsystem > windows. You can see the trace messages with any Windows debuger. The > error messages from any uncaught exception will be displayed in > message box. That's better since it will not appear to users that the program suffered instant unexplained death if they get an exception. What's your opinion of making writing to stdout fail without raising an exception when the application is compiled with --subsystem windows? Duncan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: writing to stdout in an windows app without a console
Hi Duncan With ghc-6.4 the output from Debug.Trace.trace will be redirected to the debug console when the application is compiled with --subsystem windows. You can see the trace messages with any Windows debuger. The error messages from any uncaught exception will be displayed in message box. Cheers, Krasimir On Tue, 15 Feb 2005 21:47:43 +, Duncan Coutts <[EMAIL PROTECTED]> wrote: > 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: : 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 > > ___ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
