[SDL] Re: Re: I/O problem solvable.... need Help though.
usenetNOSPAM at jimrandomh.org
Sat Jan 22 11:28:15 PST 2005
Benjamin Deutsch <ben at fictiongroup.de> wrote:
> I see two problems with this (we might as well discuss this now,
> instead of at patching time):
> 1) Most apps on Windows need this feature, since Windows has no
> easily accessible standard IO otherwise. Therefore, it makes sense
> to have redirection enabled by default.
This reasoning is wrong for many reasons.
- The linker settings one would intuitively use under MinGW give a
program that will spawn a console if needed, and *also* redirect
stdio. There exists no combination of linker settings such that it
spawns a console and doesn't redirect stdio.
- Win32 apps which are launched from a command prompt have accessible
stdio, even if they don't spawn their own console when executed
elsewhere. In other words, the accessibility of stdio is exactly the
same as on Linux, where SDL never redirects.
- stdio redirection is a portability problem; it affects only
Windows, and only on some compilers/compiler settings, so it's likely
to turn up as an unpleasant surprise.
- The stdout.txt and stderr.txt the program produces are added to the
current working directory, rather than the directory the executable
is in. In addition to filesystem clutter, this means that programs
with stdio redirection can't run setuid or setgid (yes, you can do
that under Windows) because that would allow you to create files in,
say, /Cygwin/etc/profile.d and leave trojans for other users.
- stdout.txt and stderr.txt may be created even if nothing is written
into them, needlessly cluttering the filesystem.
> 2) Backwards compatibility. An unchanged app from before the patch
> should behave the same.
> The best solution that I can see, given the two assumptions above,
> is to add a function SDL_RedirectStdIO(int flag), which can be
> used to turn the redirection on or off, and have it *on* by
> While we're at it, let's add another state (on, off, auto), where
> 'auto' behaves like originally (i.e. platform dependant), and 'on'
> and 'off' force redirection on or off regardless of platform. This
> way the call actually "adds value" ;-)
> (Optionally, a way to change the filenames, or specify only
> partial redirection. This may be easier on the command line or
> application shortcut.)
> Am I correct in assuming, though, that such a function would have
> to be called *before* SDL_Init ? That might make things a bit
No, it's much worse than that. The current behavior is to do the
redirect in WinMain (provided by -lSDLmain), before calling main(),
not in SDL_Init(). Meaning that even if there were a function to turn
it off, by the time you can call it it's already too late - closing
stdout is, as far as I can tell, irreversible. In other words,
allowing anyone to disable the stdio redirect from a source file and
preserving current behavior are mutually exclusive.
One possibility is to move the redirection into SDL_Init() and
provide a flag like SDL_INIT_NOSTDIOREDIRECT or
SDL_INIT_STDIOREDIRECT. However, this means that any output before
SDL_Init, or output indicating that SDL_Init has failed, will not be
redirected like before. Another possibility is to just provide a
function SDL_RedirectStdio() to do the redirection, and have it off
Another possibility is to provide two different SDLmain libs - one
with redirect, one without. If the one with redirect was SDLmain and
the one without was something else, then it would be very awkward for
Makefiles, since the library options would no longer be platform-
independent. (It might be possible to work around this with something
like pkg-config --define-STDIO_REDIRECT=0).
I've gone into some lengths above about why stdio redirect is a very
bad idea. Given that the redirect is done only on Windows, only with
some linker settings (which fail to match those settings for which
it's wanted), and that its current implementation is so horrendous, I
really don't think preserving backwards compatibility should be a
concern. Note that the stdio redirect is in the static portion of the
library, not the DLL, so nothing can change without a recompile.
I think providing an SDL_RedirectStdio(const char *stdout_filename,
const char *stderr_filename) function and disabling redirect
otherwise is the best solution, because it's the only one which can
make all platforms consistent. And really, consistency between
platforms *is* the whole point of SDL.
CalcRogue: TI-89, TI-92+, PalmOS, Windows and Linux.
More information about the SDL