It seems Windows has no "exec", so it needs to be decided if on that platform we 
need to spawn and wait for exit, possibly closing down on memory as much as 
possible.

As a workaround, "compare_with_cpython" now supports a mode 
"two_step_execution", which doesn't use the "--execute" feature, but does it 
manually. On Windows, this mode is becoming the default.

The MinGW bug was raises as http://sourceforge.net/tracker/?
func=detail&aid=3474316&group_id=2435&atid=102435

But it appears, it may not receive a solution soon, so this workaround will do 
for now.

Seems to be reproducible for "execl" with latest MinGW. Bug raised.

It is reproducible for "os.execl" to do this already. Should be an upstream bug 
then.

When executing programs under Windows (not wine), their exit codes get lost. It 
is only due to the recent additions of checking exit codes, that this becomes 
noticable.

Should be reproducable with 0.3.18.2 which has other issues corrected that 
prevent tests from progressing as far.

python.exe misc\check-release

at the end it is this test:

tests\syntax\RelativeNonPackageImport.py

which raises an exception as expected, but then exit code is "0", while there is 
a "return 1" in the code. I have verified that the "return 1" becomes executed 
and yet the code is still "0". Running the test on wine (--windows-target) works 
fine, exit code is correct there.