> But what is so special about the win32_ExitProcess() function, the 
> changes apply only for the actual ExitProcess() call (not the duration 
> of the rest of the forked job.

Two things: a) it's not really likely that it uncovers an application
bug that people would run into, and b) there is no other way to suppress
the problem.

> That looks like a forced fix to a specific problem, not a generic 
> buildbot-friendly feature.

In case such a bug comes up again, it is important that no popup
will trigger again

> SetErrorMode(), btw, is inherited by child processes:

Correct. With -n restored to test.bat, that can be taken out.

> For _CrtSetReportMode, don't we want to channel the output to stderr, 
> rather than the debugger output?

That would work as well (and perhaps better)

> Also, let's not forget, that parameter validation will throw up 
> dialogue boxes in a release mode too() (in DEBUG an assert is thrown in 
> to the mix as well, which is what you are silencing)

Yes - because I know you want these error boxes, we only added it
in debug mode (because that's what the buildbots use)

> If we are doing this for the benefit of buildbot, then why don't we do 
> it in python.exe?  We could add an --unattended flag or something 
> similar which would silence or redirect any interactive notifications 
> we can think of.

There is the -n flag for regrtest already. Unfortunately, there is
no easy way to pass it to the subprocess. I'm opposed to a new command
line flag, because there are already so many of them.

I would hope that multiprocessing could pass the CRT flags to
subprocesses (see the subject of this report). Somebody would
have to implement it, though.