[Twisted-Python] spawnProcess under Win32

[Igor Kravtchenko]

Jean-Paul Calderone wrote:

> On Mon, 14 Aug 2006 17:02:07 +0200, Igor Kravtchenko 
> <igor at mekensleep.com> wrote:
>
>> glyph at divmod.com wrote:
>>
>>>
>>>
>>> On Mon, 14 Aug 2006 15:15:55 +0200, Igor Kravtchenko 
>>> <igor at mekensleep.com> wrote:
>>>
>>>> Hi!
>>>
>>>
>>>> I've looked at the way Twisted creates a process under Win32 and 
>>>> I've noticed
>>>> that it uses the CreateProcess() function.  The problem is it 
>>>> doesn't mention any
>>>> creation flags (i.e.: it just passes 0) whereas here, we would need 
>>>> to pass
>>>> DETACHED_PROCESS to avoid a new console to be created.
>>>
>>>
>>>> I would be interested to know what do you think about this?
>>>> Does it seem to you a good idea?
>>>
>>>
>>>
>>> Well, we do have a UNIX-specific argument to spawnProcess (usePTY), 
>>> so I don't see why we couldn't have a Win32-specific argument as 
>>> well.  However, "win32flags" seems like a pretty vague name, 
>>> especially since it could be CreateProcess's dwCreationFlags 
>>> argument or STARTUPINFO's dwFlags attribute.
>>>
>>> Also, depending on context, you might want CREATE_NO_WINDOW or 
>>> DETACHED_PROCESS or possibly both.
>>>
>>> I believe the right thing to do is to come up with some typical 
>>> features of the Windows process environment and support them 
>>> explicitly.  I don't believe all the flags you can pass to 
>>> CreateProcess are compatible with the way Twisted expects 
>>> subprocesses to behave, and I am definitely sure that not all the 
>>> things you can put in STARTUPINFO are.
>>>
>> Hi,
>>
>> yes I see your point of view.
>> I deliberately passed that Win32 flags since I didn't wanted to get 
>> in details
>> of what kind of Win32 features we need or not.
>> It can indeed potentially breaks Twisted behavior if incorrect flags 
>> are passed.
>>
>> However it's just easier even if less secure.  Otherwise, you have to 
>> enumerate
>> all kind of features users want and implement them explicitly while 
>> having the
>> correct code guard to prevent from crash or incorrect behavior.
>>
>> I don't know about other Win32 developpers.  From my side, I just wanted
>> a way to prevent a console to be opened, so might be something like an
>> explicit CREATE_NO_CONSOLE flag or such.
>
>
> It's easier on the Twisted side.  It's harder on application developers,
> since they have to know if they want to pass CREATE_NO_CONSOLE or
> CREATE_NO_WINDOW or DETACHED_PROCESS or some combination or some other 
> flag
> entirely.
>
> It also makes it completely non-portable to other platforms.  It's 
> difficult
> to do anything with subprocesses cross-platform, but the goal should 
> be to
> make it possible and then easy.  Requiring Win32 flags to be passed in is
> complete capitulation.
>
> I also wonder why I have never noticed this behavior.  For example, I 
> have
> run buildslaves on Win32 and never noticed them popping up console 
> windows.
> Does this behavior differ between different version of Windows?
>

I don't thing.
What I have is a Windows SubSystem .exe (WinMain() entry point) 
launching a bunch
of Consoles Subsystem .exe (main() entry point).
Since the applications are console based, it's not surprising to see them.

DETACHED_PROCESS does the trick and console applications have to
call AllocConsole() explicitly to open a console.

Igor.