En Mon, 27 Aug 2007 05:35:51 -0300, Lawrence D'Oliveiro <[EMAIL PROTECTED]> escribi�:
> In message <[EMAIL PROTECTED]>, > Gabriel > Genellina wrote: > >> On 22 ago, 11:08, Grant Edwards <[EMAIL PROTECTED]> wrote: >> >>> but I'm a Unix guy who occasionally tries >>> to ship a Windows version of a Python app: the concept of a >>> process defaulting to having a stderr or stdout that wasn't >>> writable was utterly foreign to me. >> >> Ah, that explains your previous post telling that things on Windows >> don't work as they "should". They work, but not necesarily as a >> "foreigner" would expect. > > So what's the good reason for Windows having unusable defaults for stderr > and stdout, then? You should ask the wxPython/wxWidgets guys why they choose to do things that way. Perhaps it's just an option that should be turned on. I'm not a wx guru. Tk programs don't have that problem, by example: you have a GUI *and* a console, if you want. A simple print statement with no console just goes into void space - no error, no crash, no GPF... You get what you ask for: if you pass /SUBSYSTEM:WINDOWS as an option to the linker (or put equivalent flags in the executable) you don't get a console by default. That's fine for most GUI programs that don't use stdout/stderr. If you want a console, create one using AllocConsole. Or do that on the parent process, and let the children inherit it (as when running the application from the command line, as opposed to double clicking an icon). Or link with /SUBSYSTEM:CONSOLE. Or use GetStdHandle/SetStdHandle inside the app to redirect STD_OUTPUT_HANDLE etc. -- Gabriel Genellina -- http://mail.python.org/mailman/listinfo/python-list
