* Gertjan Klein:
Alf P. Steinbach wrote:
* Gertjan Klein:
What I've been thinking about is to write a single [Windows] executable that
gets associated with .py and .pyw (instead of python.exe itself).
Well, you need two: one for console subsystem, and one for GUI subsystem.
Why? I'd have imagined writing something for the GUI subsystem (without
actually creating a GUI, just to prevent a DOS box popping up), creating
the proper commandline, with either python.exe or pythonw.exe, and
launching that as a separate process. (I have no idea whether this would
actually work though -- I'm just thinking out loud at this stage.)
Thinking about it some more, perhaps that way I can't get at return
codes a python script might provide. I haven't used those, but they may
be useful at some point.
Return codes work OK no matter what.
But it's a hassle for the user to connect up standard input, standard output and
standard error for a GUI subsystem process.
That's mainly why the distinction between [.py] and [.pyw] is there in Windows:
the former is associated with console subsystem interpreter ensuring that the
standard streams are connected up automatically, the latter is associated with
GUI subsystem interpreter ensuring no automatic console window.
If it's OK with C++, I just sat down and wrote this.
Thanks for that. I won't be using it though; I don't know C++ at all,
and the source looks like complete gobbledygook to me. I wouldn't know
where to begin to change anything in it. ;-)
Ah, well.
Perhaps do this in JScript or VBScript (languages bundled with Windows)? There
may be less startup overhead than with Python. But I haven't checked.
Cheers,
- Alf
--
http://mail.python.org/mailman/listinfo/python-list
