I/O problem (stdio and stderr redirection to txt files)

[Marco_Tarini]

I didn’t know [stdio redirection] crashed SDL though, that should be fixed.

-Sam Lantinga"

Stdio and stderr redirection is probably the worst idea I’ve heard these years.

Honestly, I was shocked when I’ve seen it, I almost lost my confidence is STL in
a second.

How bad stdio/stderr redirection is? I dunno where to start. It’s just too bad.

1- If, say, the video initialization fails, your application is totally dumb to
the user, it will not even have the breath to say “cannot initalize video
because…” in any way that an honest end-user would expect. Totally dumb. Maybe
use loud voice from the speakers to communicate error messages ?

2- It cannot be turned off, it will last all the way down to the final release
and to the final user. Who will be really puzzled/pissed.

3- Your binary will not run double clicking it, if it is stored on a write-only
media like a CD-rom. But admittedly this is just a guess of mine. Is it really
the case? Even if crashes are avoided, the “from-CD” applcation functionality
would be still impaired (no output).

3- It’s useless. Us window users are used to the “window disappearing before you
read the message” problem and known sensible ways to get around it during
developement. Thank you.

4- If I wanted my messages (a log, whatever) to be written in a file rather than
on the screen I would just do that, really, I’ve no problem with that.

5- If the final user wanted the textual output of the application to be written
on a file rather than on the screen he would just do that, as with any other
application, using the “>” command-line syntax (yes, that works in windows too).
Also, if you want to do that for them you can write a “.bat” file for them. Just
as for any other application!

5- If two applications are executed from the same directory, or the same
application is executed twice, their output collide! This is my case. I’m
developing a client server application and to test it I execute the
just-compiled executable twice - once as client and once as server. Of course
this can be worked around, but it really is annoying.

5- The time I executed my first SDL application it costed me, as for many other
I guess, a puzzling quarter-of-hour before I found the shocking true on the web.

6- It needlessy negates, forever, any and every access I should have to the
command line screen. Now, just how bad is that? SDL is supposed to be the key
unlocking cross-platorm-programming and yet it denies me the access to the
single most cross-platform feature of C, namely, the stdout. Heck, I could have
a 1980’s machine with no monitor at all, just a printer and still enjoy my
standard textual output fine.

7- It negates many possibile elegant solutions. For example, in my client-server
application the “waiting to connect” phases takes place before even initializing
the video or opening any window - which is nice. Using SDL, I cannot do that. I
bet there would be similar examples.

8- As noticed, it is a unneeded element of behaviour dependence of the same code
on the system where it is complied. Bad, bad.

9- It negates a quick useful way to let the user know what the thing is doing
(and why it is taking so long).
As in: "Loading textures… " “done”.
does not get written to txt files.

So I my personal suggestion is:

Don’t just give the possibility to turn it off (leaving it on by default).
Don’t just turn it off by default (leaving the possibility to turn it on).
Instead, remove it. It is evil. Take it to Mount Doom!

Can I be of any help about this? It seems to me that this is just a choice, not
a matter of “finding someone who implements it”, but if that is not the case…

Since I’ve been such a negative critic in this contribution, let me add how much
I liked most of the rest of SDL. It is really great. Too bad for this (and a
very few other) “minor” details.

Marco Tarini

[Brian_Barrett]

what i can’t figure out is why is it in there. i wouldn’t mind it if
it was optional as it seems an easy way to create logs. it must serve
some purpose. does stout take the focus from the SDL window if you
print to it. i never use stout/err in my games but sdl seems to delete
these files it creates on leaving. does it do that if you print stuff?

i think marcos right about running it on read only media, again maybe
SDL checks this and doesn’t create the files if it can’t but does it
crash?

soem new flag like SDL_REDIRECTION coud be used. for backwards
compatability, it could be on by default

[Brian_Kropf]

I believe the IO redirection is there on windows because when a program
writes to stdout or stderr it’ll open up a cmd / DOS window, which can
disturb the same users that an earlier poster was talking about. Many
(non-programmer) users on windows try to stay away from the command line
interface and are confused when their windows application is suddenly
opening other windows when they haven’t asked for them.

I myself have mixed feelings about the redirection. I see it’s
usefulness, but wish there would be some message when sdl crases. While
developing, I use libraries configured to not use stdio redirection
(mingw/msys: configure it with --enable-stdio-redirect=no)

• brian

Brian Barrett wrote:>what i can’t figure out is why is it in there. i wouldn’t mind it if

it was optional as it seems an easy way to create logs. it must serve
some purpose. does stout take the focus from the SDL window if you
print to it. i never use stout/err in my games but sdl seems to delete
these files it creates on leaving. does it do that if you print stuff?

i think marcos right about running it on read only media, again maybe
SDL checks this and doesn’t create the files if it can’t but does it
crash?

soem new flag like SDL_REDIRECTION coud be used. for backwards
compatability, it could be on by default

---

SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

[David_Olofson]

I believe the IO redirection is there on windows because when a
program writes to stdout or stderr it’ll open up a cmd / DOS window,
which can disturb the same users that an earlier poster was talking
about.

Another reason might be that some platforms simply don’t have any
useful implementation of stdout and stderr.

Anyway, just today, after cross compiling some stuff, I found myself
wondering for a moment where the output went… heh

Many (non-programmer) users on windows try to stay away from
the command line interface and are confused when their windows
application is suddenly opening other windows when they haven’t
asked for them.

One solution is to implement something like the startup console that
most Q3 based games pop up. However, next, people will want it themed
and whatnot, so I guess that’s better done as an add-on library…

The normal solution in desktop environments is to pop up a message
dialog when there is a problem, but that’s not really compatible with
the stdout/stderr interface…

I myself have mixed feelings about the redirection. I see it’s
usefulness, but wish there would be some message when sdl crases.

That’s two different things, actually;

1. critical internal SDL errors, and
2. application output through stdout and stderr.

In the case of 1), sure; if it’s something the application cannot
trap and handle appropriately, one would expect SDL to do what’s
expected on the respective platform. That is, the SDL parachute
should pop up a dialog on platforms that have no “natural” stderr
channel. Preferably, the error message should be very clear, so the
user at least understands that something went very wrong and the
application wasn’t even able to say anything about it.

As for 2), I think it’s basically a bad habit to just print messages
to stdout or stderr regardless of platform. Unfortunately, it’s the
only easy and portable way, so everyone keeps doing it. No matter how
trivial it may be to pop up a message dialog on Win32, Mac OS X or
whatever, it’s kinda’ tricky to implement and test it if you don’t
have access to those platforms.

Either way, 2) is still something that can - and probably should - be
handled by an add-on library.

Just a thought, BTW: Would it make sense to try to open a “minimal
requirements” SDL window and use that as a startup console, and for
displaying error messages when you can’t open a display with the
intended parameters?

That is, how likely is it that you hit a problem that prevents you
from opening up any kind of SDL display?

//David Olofson - Programmer, Composer, Open Source Advocate

.- Audiality -----------------------------------------------.
| Free/Open Source audio engine for games and multimedia. |
| MIDI, modular synthesis, real time effects, scripting,… |
`-----------------------------------> http://audiality.org -’
— http://olofson.net — http://www.reologica.se —On Wednesday 16 March 2005 18.25, Brian Kropf wrote:

[Brian_Kropf]

David Olofson wrote:

I believe the IO redirection is there on windows because when a
program writes to stdout or stderr it’ll open up a cmd / DOS window,
which can disturb the same users that an earlier poster was talking
about.

Another reason might be that some platforms simply don’t have any
useful implementation of stdout and stderr.

Anyway, just today, after cross compiling some stuff, I found myself
wondering for a moment where the output went… heh

Many (non-programmer) users on windows try to stay away from
the command line interface and are confused when their windows
application is suddenly opening other windows when they haven’t
asked for them.

One solution is to implement something like the startup console that
most Q3 based games pop up. However, next, people will want it themed
and whatnot, so I guess that’s better done as an add-on library…

The normal solution in desktop environments is to pop up a message
dialog when there is a problem, but that’s not really compatible with
the stdout/stderr interface…

I myself have mixed feelings about the redirection. I see it’s
usefulness, but wish there would be some message when sdl crases.

That’s two different things, actually;

1. critical internal SDL errors, and
2. application output through stdout and stderr.

In the case of 1), sure; if it’s something the application cannot
trap and handle appropriately, one would expect SDL to do what’s
expected on the respective platform. That is, the SDL parachute
should pop up a dialog on platforms that have no “natural” stderr
channel. Preferably, the error message should be very clear, so the
user at least understands that something went very wrong and the
application wasn’t even able to say anything about it.

As for 2), I think it’s basically a bad habit to just print messages
to stdout or stderr regardless of platform. Unfortunately, it’s the
only easy and portable way, so everyone keeps doing it. No matter how
trivial it may be to pop up a message dialog on Win32, Mac OS X or
whatever, it’s kinda’ tricky to implement and test it if you don’t
have access to those platforms.

Either way, 2) is still something that can - and probably should - be
handled by an add-on library.

Just a thought, BTW: Would it make sense to try to open a “minimal
requirements” SDL window and use that as a startup console, and for
displaying error messages when you can’t open a display with the
intended parameters?

That is, how likely is it that you hit a problem that prevents you
from opening up any kind of SDL display?

I pretty much agree with these, and to go a bit further with the thoughts:
part 1 above is great, as non-advanced users are used to messageboxes
giving error messages (don’t know easy a “cross platform” messagebox is
though).

For part 2, we’re pretty much talking about a logging library right?
I’d definitely find that more useful than simple stdio redirection.

• brian>On Wednesday 16 March 2005 18.25, Brian Kropf wrote:

//David Olofson - Programmer, Composer, Open Source Advocate

.- Audiality -----------------------------------------------.
| Free/Open Source audio engine for games and multimedia. |
| MIDI, modular synthesis, real time effects, scripting,… |
`-----------------------------------> http://audiality.org -’
— http://olofson.net — http://www.reologica.se —

---

SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

[Martin_Storsjo]

I believe the IO redirection is there on windows because when a program
writes to stdout or stderr it’ll open up a cmd / DOS window, which can
disturb the same users that an earlier poster was talking about. Many
(non-programmer) users on windows try to stay away from the command line
interface and are confused when their windows application is suddenly opening
other windows when they haven’t asked for them.

There seems to be a lot of misconecptions about this. In fact, whether a
console window is showed or not hasn’t got anything to do with if you
write anything to stdout/stderr. The only thing that matters is if you
link your program as a console or gui application.

If you link your your program as a gui application, no console window is
showed, and whatever you write to stdout/err simply goes nowhere. Which
imo is the solution that would be the best default.

I always link my SDL applications with a version of SDLmain compiled
without stdio redirection.

// MartinOn Wed, 16 Mar 2005, Brian Kropf wrote:

[David_Olofson]

[…]

I pretty much agree with these, and to go a bit further with the
thoughts:
part 1 above is great, as non-advanced users are used to
messageboxes giving error messages (don’t know easy a “cross
platform” messagebox is though).

I don’t think there is one, and that’s probably the main reason why it
isn’t done currently. If things go really wrong (no supported video
backends available, for example), it’s entirely possible that SDL
can’t open any normal window at all, so this has to be handled by
platform specific code - or stderr.

For part 2, we’re pretty much talking about a logging library right?
I’d definitely find that more useful than simple stdio redirection.

Well, I was primarilly thinking of some way to open up some kind of
text output channel; a Q3A style startup console, stdout or whatever
is most likely to minimize user confusion on the platform at hand.
Some API extension like this:

typedef void *SDL_ConsoleHandle;
SDL_ConsoleHandle SDL_OpenConsole(void);
SDL_CloseConsole(SDL_ConsoleHandle handle);
SDL_ConsolePrintF(SDL_ConsoleHandle handle, const char *format, …);
SDL_ConsoleVPrintF(SDL_ConsoleHandle handle,
const char *format, va_list ap);

(Maybe with some control codes defined for bold type, italics, colors
etc. Maybe just implement a subset of the ANSI terminal codes, so the
text can be sent directly to stdout on platforms where terminals
generally support it.)

The logging part (timestamps, tags, coloring, the actual logging etc)
would be application code, or a separate add-on library.

Making layers of abstraction too “thick” is a bad idea, I think; it
drastically reduces the chances of anyone using the library. Many
games already have a logging system of some kind, and if those can’t
just be plugged into something very similar to the stdio interface, I
don’t think people will bother.

If at all possible, it would probably be best to redirect the actual
stdout and stderr to the “Q3A console”.

Don’t know if there’s a portable way of doing that, but one would
think that there’s some way of doing it on any platform that can
redirect them to files… If you can’t redirect to a pipe or similar
construct, how about tailing the files? (Like the Un*x 'tail’
command, that is. If all else fails, you can implement it by opening
the file at regular intervals, checking if the length has changed.)

//David Olofson - Programmer, Composer, Open Source Advocate

.- Audiality -----------------------------------------------.
| Free/Open Source audio engine for games and multimedia. |
| MIDI, modular synthesis, real time effects, scripting,… |
`-----------------------------------> http://audiality.org -’
— http://olofson.net — http://www.reologica.se —On Thursday 17 March 2005 02.36, Brian Kropf wrote:

[Tom_Wilson]

[snip]

Well, I was primarilly thinking of some way to open up some kind of
text output channel; a Q3A style startup console, stdout or whatever
is most likely to minimize user confusion on the platform at hand.
Some API extension like this:

typedef void *SDL_ConsoleHandle;
SDL_ConsoleHandle SDL_OpenConsole(void);
SDL_CloseConsole(SDL_ConsoleHandle handle);
SDL_ConsolePrintF(SDL_ConsoleHandle handle, const char *format, …);
SDL_ConsoleVPrintF(SDL_ConsoleHandle handle,
const char *format, va_list ap);

(Maybe with some control codes defined for bold type, italics, colors

[snip]

Sorry, but isn’t this overkill? I always thought SDL was good beacause
it wasn’t bloatware. i.e it lets the devloper make a few choices
him/herself

Why not just have;
long SDL_GetLastError()
SDL_SetLastError(long)
const char *SDL_GetSysErrorString(long)

A similar thing has been mentioned before:

http://twomix.devolution.com/pipermail/sdl/1999-July/021385.html

Then it’s up to you how many consoles, error messages etc you pop up.

You could even make it an error stack and have SDL_PushError,
SDL_PeepError, SDL_PopError

• Tom

[Petri_Latvala]

typedef void *SDL_ConsoleHandle;
SDL_ConsoleHandle SDL_OpenConsole(void);
SDL_CloseConsole(SDL_ConsoleHandle handle);
SDL_ConsolePrintF(SDL_ConsoleHandle handle, const char *format, …);
SDL_ConsoleVPrintF(SDL_ConsoleHandle handle,
const char *format, va_list ap);

Sorry, but isn’t this overkill? I always thought SDL was good beacause
it wasn’t bloatware. i.e it lets the devloper make a few choices
him/herself

Why not just have;
long SDL_GetLastError()
SDL_SetLastError(long)
const char *SDL_GetSysErrorString(long)

How about because they do different things?

Functions David proposed handle telling the error etc to the
user. Your proposal deals with letting the developer query for
error information.

Then it’s up to you how many consoles, error messages etc you pop
up.

But how to pop up those error messages? That’s what this discussion is
about.On Thu, Mar 17, 2005 at 11:36:09AM +0000, Tom Wilson wrote:

–
Petri Latvala
-------------- next part --------------
A non-text attachment was scrubbed…
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20050317/72ea6099/attachment.pgp

[David_Olofson]

[…]

typedef void *SDL_ConsoleHandle;
SDL_ConsoleHandle SDL_OpenConsole(void);
SDL_CloseConsole(SDL_ConsoleHandle handle);
SDL_ConsolePrintF(SDL_ConsoleHandle handle, const char
*format, …);
SDL_ConsoleVPrintF(SDL_ConsoleHandle handle,
const char *format, va_list ap);

(Maybe with some control codes defined for bold type, italics,
colors

[snip]

Sorry, but isn’t this overkill? I always thought SDL was good
beacause it wasn’t bloatware. i.e it lets the devloper make a few
choices him/herself

Why not just have;
long SDL_GetLastError()
SDL_SetLastError(long)
const char *SDL_GetSysErrorString(long)

That’s the other side of things, and not what I was talking about.

The API I suggested above is for an add-on library that pops up a “Q3A
startup” style console, sends text to stdout/stderr (which is what
Q3A does on Linux, BTW) or whatever is expected on the platform at
hand. That is, passing messages from SDL - and other sources - to the
user, at times when the SDL display is closed or potentially
malfunctioning.

The right thing to do on Win32, Mac OS X, KDE, Gnome etc is obviously
NOT to send it to stdout/stderr, because that just results in users
seing no response whatsoever when an application fails to run.

Sending it to a text file is even worse, because when the slightly
more experienced user decides to see if the application says anything
when run from the console, there’s still no (visible) response!

Then what…? Where do you start looking? For what?

(Keep in mind that the average user, or “power user” for that matter,
is not a programmer and have probably never heard of SDL, and
certainly doesn’t know anything about it’s stdout/stderr
redirection.)

Then it’s up to you how many consoles, error messages etc you pop
up.

Yeah. The problem is that there’s no remotely portable way of “popping
up” anything at all - not even a simple "I give up, because …!"
message box.

So, I suggested creating a tiny add-on lib specifically for dealing
properly with this on platforms where stdout and stderr are normally
piped to /dev/nul, or some place where normal users will never see
it.

//David Olofson - Programmer, Composer, Open Source Advocate

.- Audiality -----------------------------------------------.
| Free/Open Source audio engine for games and multimedia. |
| MIDI, modular synthesis, real time effects, scripting,… |
`-----------------------------------> http://audiality.org -’
— http://olofson.net — http://www.reologica.se —On Thursday 17 March 2005 12.36, Tom Wilson wrote:

[David_Olofson]

Ok, doing some research, but I’m having some trouble finding anything
useful in all the noise on the 'net…

[…]

If at all possible, it would probably be best to redirect the actual
stdout and stderr to the “Q3A console”.

Is there any reasonably portable way of redirecting stdout and stderr
to some sort of memory streams? (Pipes, process local stdio stuff or
whatever; all we need is some way of getting at the data that would
normally be written to stdout and stderr.)

Another way would be to redirect the output to two files, and have the
console tail those. However, that requires a writable temporary file
system. Most platforms seem to have invented a bunch of places to put
this kind of stuff… But are there platforms without a directory for
temporary files?

//David Olofson - Programmer, Composer, Open Source Advocate

.- Audiality -----------------------------------------------.
| Free/Open Source audio engine for games and multimedia. |
| MIDI, modular synthesis, real time effects, scripting,… |
`-----------------------------------> http://audiality.org -’
— http://olofson.net — http://www.reologica.se —On Thursday 17 March 2005 09.21, David Olofson wrote:

[Tom_Wilson]

Petri Latvala wrote:

typedef void *SDL_ConsoleHandle;
SDL_ConsoleHandle SDL_OpenConsole(void);
SDL_CloseConsole(SDL_ConsoleHandle handle);
SDL_ConsolePrintF(SDL_ConsoleHandle handle, const char *format, …);
SDL_ConsoleVPrintF(SDL_ConsoleHandle handle,
const char *format, va_list ap);

Sorry, but isn’t this overkill? I always thought SDL was good beacause
it wasn’t bloatware. i.e it lets the devloper make a few choices
him/herself

Why not just have;
long SDL_GetLastError()
SDL_SetLastError(long)
const char *SDL_GetSysErrorString(long)

How about because they do different things?

No, I this is the same issue.

Functions David proposed handle telling the error etc to the
user.

Yes, David has now clarified, it should be in an external library.

Your proposal deals with letting the developer query for

error information.

Yes, it does exactly that. I think it would be a waste of effort to
make a library that gathers the stderr info and displays it. It would
be better to reform/patch the current way that error information is
obtained in SDL, and then create a library that displays the information.

Cheers,

• Tom> On Thu, Mar 17, 2005 at 11:36:09AM +0000, Tom Wilson wrote:

[David_Olofson]

[…]

How about because they do different things?

No, I this is the same issue.

No, but they’re closely related.

[…]

Your proposal deals with letting the developer query for

error information.

Yes, it does exactly that. I think it would be a waste of effort to
make a library that gathers the stderr info and displays it.

That’s an implementation detail, but yes; there are better ways, at
least in theory.

It
would
be better to reform/patch the current way that error information is
obtained in SDL, and then create a library that displays the
information.

Yes, but SDL is probably the least frequent user of stderr/stdout in
your average SDL application. Having SDL put error messages in some
place where an application or add-on library could easilly get at it
would be great, but what about libs and applications that already
does lots of printing to stdout/stderr?

If we can’t redirect stderr and stdout, we should at least provide a
"lagacy" interface that’s compatible enough that one could just
search’n’replace.

Not saying we should have only an stdio style interface. Might as
well provide some conrol codes for timestamps and such while we’re at
it, but I have a feeling that complicating it too much will just
result in everyone continuing to (ab)use printf(), for eternal end
user headscratching. (Frankly, I have a feeling they will anyway, but
we’ll never find out unless we hack this thing.

BTW, I’m thinking that this thing might actually be better off as a
"throw into project" C file, or static-only lib or something, and
entirely self-contained… Kinda’ silly to have it fail to say
"Cannot find data files!" just because it can’t find it’s own
files!

BTW(2), I have a simple printf() style logger lying around, that can
send plain text, ANSI colored text and HTML to stdout/stderr or to a
file. Might fit in somewhere, I dunno…

//David Olofson - Programmer, Composer, Open Source Advocate

.- Audiality -----------------------------------------------.
| Free/Open Source audio engine for games and multimedia. |
| MIDI, modular synthesis, real time effects, scripting,… |
`-----------------------------------> http://audiality.org -’
— http://olofson.net — http://www.reologica.se —On Thursday 17 March 2005 15.33, Tom Wilson wrote:

[Bob_Ippolito]

Ok, doing some research, but I’m having some trouble finding anything
useful in all the noise on the 'net…

[…]

If at all possible, it would probably be best to redirect the actual
stdout and stderr to the “Q3A console”.

Is there any reasonably portable way of redirecting stdout and stderr
to some sort of memory streams? (Pipes, process local stdio stuff or
whatever; all we need is some way of getting at the data that would
normally be written to stdout and stderr.)

No, not in ANSI C or POSIX, as far as I know. You could do something
really ugly with fork and some pipes, but that’s not going to work
everywhere and it’s dumb.

Another way would be to redirect the output to two files, and have the
console tail those. However, that requires a writable temporary file
system. Most platforms seem to have invented a bunch of places to put
this kind of stuff… But are there platforms without a directory for
temporary files?

The only portable way is to not use stdio directly. You really have no
business using printf(…) if you want the output to go somewhere other
than stdout. If you do want the output to go to stdout under some
scenario(s), it’s easy enough to make it go there using such an an
abstraction of stdio.

-bobOn Mar 17, 2005, at 8:26, David Olofson wrote:

On Thursday 17 March 2005 09.21, David Olofson wrote:

[David_Olofson]

[…]

Another way would be to redirect the output to two files, and have
the console tail those. However, that requires a writable
temporary file system. Most platforms seem to have invented a
bunch of places to put this kind of stuff… But are there
platforms without a directory for temporary files?

The only portable way is to not use stdio directly. You really have
no business using printf(…) if you want the output to go somewhere
other than stdout.

Good point.

The bad news is that this basically means there is no portable and
proper way of handling error messages at all. stdout/stderr is
essentially broken on the platforms that most people are using.

Well, no news, really. It’s been like this for quite a few years
now… It’s about time to wake up and deal with it, I suppose.

If you do want the output to go to stdout under
some scenario(s),

…like when actually running from a console [which you detect how,
exactly…?], and only then, on pretty much all platforms in use
these days.

it’s easy enough to make it go there using such an
an abstraction of stdio.

Yeah, that was what I was thinking when I suggested that kind of API.
(And of course, that it makes porting existing code easier.)

I’m thinking about implementing a startup console in SDL (windowed
mode, any bpp, any format, compiled-in bitmap font etc), and just use
that if it’s at all possible to open it, unless some option ‘-cli’ or
similar is passed when starting the application.

My original idea was to go directly at X11, GDI etc on the various
platforms, but then I realized this is essentially what SDL does
anyway, so what’s the point? SDL might actually be more reliable,
since all it needs is some sort of surface with at least two colors.
No fonts, no window manager, no nothing… A console based on that
will work even if the OS has screwed up all fonts or the desktop
theme makes all text unreadable.

This is assuming you actually have some video backends compiled into
your SDL lib. It would be nice if it could pop up a message box if it
can’t set up a display at all, but then again, doesn’t this usually
happen when you start from a text console and there’s no fbdev,
svgalib, X, aalib or anything, or when a developer or serious power
user has installed a custom SDL lib? In the former case, stderr is
the correct channel to use, and in the latter case, one would assume
that people know what they’re doing…

(Well, default std* redirection in SDL still has to die, or this
doesn’t hold true on some platforms. Consider trying a broken SDL DLL
on Win32…)

//David Olofson - Programmer, Composer, Open Source Advocate

.- Audiality -----------------------------------------------.
| Free/Open Source audio engine for games and multimedia. |
| MIDI, modular synthesis, real time effects, scripting,… |
`-----------------------------------> http://audiality.org -’
— http://olofson.net — http://www.reologica.se —On Thursday 17 March 2005 17.08, Bob Ippolito wrote:

[Bob_Ippolito]

[…]

Another way would be to redirect the output to two files, and have
the console tail those. However, that requires a writable
temporary file system. Most platforms seem to have invented a
bunch of places to put this kind of stuff… But are there
platforms without a directory for temporary files?

The only portable way is to not use stdio directly. You really have
no business using printf(…) if you want the output to go somewhere
other than stdout.

Good point.

The bad news is that this basically means there is no portable and
proper way of handling error messages at all. stdout/stderr is
essentially broken on the platforms that most people are using.

Well, no news, really. It’s been like this for quite a few years
now… It’s about time to wake up and deal with it, I suppose.

Well, stdout/stderr goes where it’s supposed to go most of the time.
On Mac OS X it goes into a console log, which you only really look at
if something goes wrong. A GUI application has no purpose for text
messages except to report a subset of unexpected conditions. Generally
either something went so horribly wrong that it doesn’t have the
opportunity to get in the user’s face, or not quite wrong enough to
bother them, but still wrong enough to make a note of it.

If you do want the output to go to stdout under
some scenario(s),

…like when actually running from a console [which you detect how,
exactly…?], and only then, on pretty much all platforms in use
these days.

Simple, pick one:
(a) make everything go to both the normal stderr or stdout plus the GUI
console by default
(b) make everything go to only GUI console by default, unless the user
explicitly asks for something else

(a) seems like the obvious choice, especially for Mac OS X and win32,
but probably everywhere.

-bobOn Mar 17, 2005, at 12:06, David Olofson wrote:

On Thursday 17 March 2005 17.08, Bob Ippolito wrote:

[Brian_Kropf]

Martin Storsj? wrote:

I believe the IO redirection is there on windows because when a
program writes to stdout or stderr it’ll open up a cmd / DOS window,
which can disturb the same users that an earlier poster was talking
about. Many (non-programmer) users on windows try to stay away from
the command line interface and are confused when their windows
application is suddenly opening other windows when they haven’t asked
for them.

There seems to be a lot of misconecptions about this. In fact, whether
a console window is showed or not hasn’t got anything to do with if
you write anything to stdout/stderr. The only thing that matters is if
you link your program as a console or gui application.

It isn’t a misconception. You are correct that normal programs linked as
gui applications don’t have the stdio active, or open a console window.
You can however allocate a console to a gui window and have the stdio
handles available, you can also have a console mode program that links
with the gui libraries that has windows and stdio handles, there are
many ways to have stdio + windows. But the problem that we were talking
about is with how SDL handles things on windows. If you build SDL with
the redirection on, then when your user program tries to do something
like reading from stdin, it can’t because of the redirection.

If you link your your program as a gui application, no console window
is showed, and whatever you write to stdout/err simply goes nowhere.
Which imo is the solution that would be the best default.

I always link my SDL applications with a version of SDLmain compiled
without stdio redirection.

That’s exactly what we have been talking about. The default behavior on
windows is redirection, and since the various applications using SDL out
there have varying usage of stdio (like error messages), the thought was
to do something that makes all platforms consistent.

• brian> On Wed, 16 Mar 2005, Brian Kropf wrote:

// Martin

---

SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

[David_Olofson]

[…]

Well, stdout/stderr goes where it’s supposed to go most of the time.
On Mac OS X it goes into a console log, which you only really look
at if something goes wrong. A GUI application has no purpose for
text messages except to report a subset of unexpected conditions.
Generally either something went so horribly wrong that it doesn’t
have the opportunity to get in the user’s face, or not quite wrong
enough to bother them, but still wrong enough to make a note of it.

Yeah, you’re right; it does still serve some purposes rather well,
actually. It’s just that it basically doesn’t work at all when you
actually want to tell the average user about something.

If you do want the output to go to stdout under
some scenario(s),

…like when actually running from a console [which you detect
how, exactly…?], and only then, on pretty much all platforms in
use these days.

Simple, pick one:
(a) make everything go to both the normal stderr or stdout plus the
GUI console by default

Of course! Why didn’t I think of that?

(b) make everything go to only GUI console by default, unless the
user explicitly asks for something else

(a) seems like the obvious choice, especially for Mac OS X and
win32, but probably everywhere.

Yeah, I’d go for doing it everywhere. If the GUI console annoys you,
just close it, and if you don’t want to see it again, disable it in
the application’s configuration or something.

//David Olofson - Programmer, Composer, Open Source Advocate

.- Audiality -----------------------------------------------.
| Free/Open Source audio engine for games and multimedia. |
| MIDI, modular synthesis, real time effects, scripting,… |
`-----------------------------------> http://audiality.org -’
— http://olofson.net — http://www.reologica.se —On Thursday 17 March 2005 19.18, Bob Ippolito wrote:

[Donny_Viszneki]

I’m going to attempt to prune down this thread to a list of relevant
points.

• We don’t want to bloat SDL
• We want to report critical error messages to users through the GUI

I think the first order here is to decide what are “critical” error
messages. Personally, I think if it doesn’t prevent SDL from doing its
job, then you, the programmer, can take it upon yourself to display the
error in your SDL window. What DOES break SDL, should probably be
reported through some sort of graphical dialog.

Another kind of error was mentioned that might hinder the process of
graphically reporting the error, however. And that was when a program
can’t find its resources (we’ve all been there at one time or another.)
These can be handled by SDL users, and there’s no need to add it to the
SDL library. I suggest to consider the following options:

1) Implement a fail-proof "missing resources" message
	A) Using a font that is linked to your application directly and can't 

ever go missing
B) Using a plain image to display the same information you’d have
displayed with 1A
C) Using a short “missing resources, rtfm” or similar message into
the titlebar of your SDL display
2) Consider your audience
A) The average Mac OS X user will be running a .app bundle – if you
tested it even once on Mac OS X, you can know definitively whether or
not the application can find its resources.
B) The average X (Linux, BSD, etc.) user will be smart enough to
check stdout / stderr themselves.
C) The average Windows user might like a message box. And the API
call for message boxes is really simple.

Some notes:
1A-C could be implemented to wait for a click or enter key or
something, then exit. Simple, effective. With 1B, you could easily make
this message as friendly looking as you wanted. You could combine 1A
and 1B to get both of their advantages. Be weary of linking too much
garbage into your application, it’s poor programming.

2A-C might be a little underwhelming to some of you. But seriously
folks, it is NOT hard to guarantee this sort of error from ever arising
in the first place. You can’t plan for every contingency. If the user
deletes all the libraries your game came with, or all your game data,
there’s very little you can do. What you can do is make sure your game
knows where to find this data, and that really isn’t that difficult.
Please don’t ask the maintainers of SDL to create a contingency system
for this situation.

2C is very simple, just try something like this (bare with me, I
haven’t programmed on or used windows in over 3 years now):
#ifdef WIN32_LEAN_AND_MEAN
SDL_SysWMinfo winfo;
SDL_GetWMInfo(&winfo);
MessageBox(winfo.hwnd, “Cannot find game resources, please refer to
README, or reinstall.”, “Game Title”, MB_OK);
#endif

IIRC, the first and last parameters could both be zero/null and the
function would still go off without a hitch.

If you really want a graphical message in the case of 2B, you can just
run xmessage from your application. It’s a very simple interface to
display a message that comes with X.

Last, 2A, it’s probably very easy to display a cocoa / carbon dialog. I
have no idea how. But it’s probably not that hard.

Last I would say that maybe a message box interface would be a nice SDL
mechanism, since it’s very lightweight, and “only for emergencies.” But
I personally think there’s no reason to go any further than that at
all.

If this doesn’t satisfy you, or you think I left something out, try
writing a concise email to the thread that doesn’t necessarily reply to
anyone (read: no need to quote other people if you aren’t replying
directly to what someone else said,) but for clarity, simply states
what else you think can be added. This of course is just my opinion,
but I’m saying it here because this thread 17 posts already, and just
to see what the state of the conversation was quite a task. C’est la
vie.

[Bob_Ippolito]

I’m going to attempt to prune down this thread to a list of relevant
points.

• We don’t want to bloat SDL
• We want to report critical error messages to users through the GUI

I think the first order here is to decide what are “critical” error
messages. Personally, I think if it doesn’t prevent SDL from doing its
job, then you, the programmer, can take it upon yourself to display
the error in your SDL window. What DOES break SDL, should probably be
reported through some sort of graphical dialog.

Another kind of error was mentioned that might hinder the process of
graphically reporting the error, however. And that was when a program
can’t find its resources (we’ve all been there at one time or
another.) These can be handled by SDL users, and there’s no need to
add it to the SDL library. I suggest to consider the following
options:

1. Implement a fail-proof “missing resources” message
   A) Using a font that is linked to your application directly and
   can’t ever go missing
   B) Using a plain image to display the same information you’d have
   displayed with 1A
   C) Using a short “missing resources, rtfm” or similar message into
   the titlebar of your SDL display
2. Consider your audience
   A) The average Mac OS X user will be running a .app bundle – if you
   tested it even once on Mac OS X, you can know definitively whether or
   not the application can find its resources.
   B) The average X (Linux, BSD, etc.) user will be smart enough to
   check stdout / stderr themselves.
   C) The average Windows user might like a message box. And the API
   call for message boxes is really simple.

Some notes:
1A-C could be implemented to wait for a click or enter key or
something, then exit. Simple, effective. With 1B, you could easily
make this message as friendly looking as you wanted. You could combine
1A and 1B to get both of their advantages. Be weary of linking too
much garbage into your application, it’s poor programming.

2A-C might be a little underwhelming to some of you. But seriously
folks, it is NOT hard to guarantee this sort of error from ever
arising in the first place. You can’t plan for every contingency. If
the user deletes all the libraries your game came with, or all your
game data, there’s very little you can do. What you can do is make
sure your game knows where to find this data, and that really isn’t
that difficult. Please don’t ask the maintainers of SDL to create a
contingency system for this situation.

2C is very simple, just try something like this (bare with me, I
haven’t programmed on or used windows in over 3 years now):
#ifdef WIN32_LEAN_AND_MEAN
SDL_SysWMinfo winfo;
SDL_GetWMInfo(&winfo);
MessageBox(winfo.hwnd, “Cannot find game resources, please refer to
README, or reinstall.”, “Game Title”, MB_OK);
#endif

And on Mac OS X, you want:
NSRunAlertPanel(@“Title For Your Error Box, Probably Not The Game
Title”, @“Can not find…”, nil, nil, nil);

Except… it’s an Objective-C function, not a C function, so you’re
going to need to compile that part of your game as a .m, etc. etc.
There is definitely a place in SDL to abstract “2C” for you!

I don’t think a SDL_RunAlertPanel (or whatever it’s called) is
acceptable bloat. Its implementation is trivial on nearly every
platform.

-bobOn Mar 18, 2005, at 0:00, Donny Viszneki wrote: