I/O problem solvable.... need Help though

I researched on Google, and it turns out that the redirection problem can be
fixed in either of two ways…

"You can also copy the src/main/win32/SDL_main.c file into your project and
then you will no longer need to link with SDLmain.lib, and you can change
the way the I/O redirection works.

I didn’t know it crashed SDL though, that should be fixed.

Thanks!
-Sam Lantinga"

or, method two would be recompiling SDL giving it the compile-time “–disable-
stdio-redirect”.

Because of my “newbness”, I personally don’t understand how to go by doing the
first methodbwhich apparently seems more immediate, and certainly don’t know
how to compile a graphics library such as SDL is. I use mingw which came with
DEV C++ so all compiling I do is through the Dev C++ application. As such, I
can’t follow the compile tutorials found throughout the web which require the
use of console compilation commands.

Could someone please help me out???

Thanks,

Daniel

Daniel <zombie_1985 at hotmail.com> wrote:

I researched on Google, and it turns out that the redirection
problem can be fixed in either of two ways…

"You can also copy the src/main/win32/SDL_main.c file into your
project and then you will no longer need to link with SDLmain.lib,
and you can change the way the I/O redirection works.

I didn’t know it crashed SDL though, that should be fixed.

Thanks!
-Sam Lantinga"

or, method two would be recompiling SDL giving it the compile-time
"–disable- stdio-redirect".

Because of my “newbness”, I personally don’t understand how to go
by doing the first methodbwhich apparently seems more immediate,
and certainly don’t know how to compile a graphics library such as
SDL is. I use mingw which came with DEV C++ so all compiling I do
is through the Dev C++ application. As such, I can’t follow the
compile tutorials found throughout the web which require the use
of console compilation commands.

Could someone please help me out???

This is the third time this problem (no clean way to get rid of stdio
redirect) has been brought up in about a week. At present, recompiling
the SDL library or adding WinMain() your program are the only
workarounds. IMO, both are awful solutions; it’s really just waiting
for someone to step up and write a patch to SDL.–
CalcRogue: TI-89, TI-92+, PalmOS, Windows and Linux.
http://calcrogue.jimrandomh.org/

This is the third time this problem (no clean way to get rid of stdio
redirect) has been brought up in about a week. At present, recompiling
the SDL library or adding WinMain() your program are the only
workarounds. IMO, both are awful solutions; it’s really just waiting
for someone to step up and write a patch to SDL.

I hope said patch completely removes the feature. Any app that
needs this feature can simply add:

freopen(“stdin.txt”, “r”, stdin);
freopen(“stdout.txt”, “a”, stdout);
freopen(“stderr.txt”, “a”, stderr);On Fri, 2005-01-21 at 15:11, jimrandomh wrote:

This is the third time this problem (no clean way to get rid of stdio
redirect) has been brought up […] it’s really just waiting
for someone to step up and write a patch to SDL.

I hope said patch completely removes the feature. Any app that
needs this feature can simply add:

freopen(“stdin.txt”, “r”, stdin);
freopen(“stdout.txt”, “a”, stdout);
freopen(“stderr.txt”, “a”, stderr);

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.

  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 default.

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” :wink:

(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 awkward.

Bye,
Benjamin Deutsch

Benjamin Deutsch 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.
  1. 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
default.

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” :wink:

(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
awkward.

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
otherwise.

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.
http://calcrogue.jimrandomh.org/

  • The stdout.txt and stderr.txt the program produces are added to the
    current working directory, rather than the directory the executable

When starting things from the Windows start menu, the desktop is the
current working directory, so stdout.txt and stderr.txt ends up there.
This fact alone is an endless source of worry and confusion for people
who maybe don’t know that much about computers, but just want to play a
game. Some may file bug reports about it, others may think they’ve got
a virus or spyware on their hands and uninstall the game immediately.
Both of these have actually happened several times with a game where I’m
part of the dev team. Stdio redirect will be disabled in the next
version, obviously.

  • Gerry