> It is said that execv() is deprecated, but it is not said that it is
> alias of _execv(). It is only said that _execv() is C++ compliant.
> http://msdn.microsoft.com/en-us/library/ms235416(v=vs.90).aspx

Microsoft seems to have decided that all functions in the C runtime which don't begin with an underscore, and are not included in the ANSI C standard should be deprecated.  This includes all the fd functions like read(), write(), open(), close(), ...  There is no difference in behaviour between these and the underscore versions.

...

> Don't we have such function already? I don't see the problem in
> quoting the string.

No one seems to know how to write such a quoting function.

...

> Does it start child process in foreground or in background? Did you
> compile examples on
> http://msdn.microsoft.com/en-us/library/431x4c1w.aspx page with new
> VC++ to check? I don't possess the VC++ 10, so I can't do this myself.
> And I believe that compiling with GCC may lead to different results.

There is no such thing as a background task in Windows.  A process is either attached to a console, or it isn't.  When you use execv() to start a process, it inherits the parent's console.

On Unix try replacing os.execv(...) by

    os.spawnv(os.P_NOWAIT, ...)
    os._exit(0)

and you will probably get the same behaviour where the shell and the child process both behave as conflicting foreground tasks.

..

> I don't mind if it runs child process with different pid, but why it
> runs new process in background. Unix version doesn't do this.

The point is that the shell waits for its child process to finish by using waitpid() (or something similar) on the child's pid.  If the child uses execv() then the child is replaced by a grandchild process with the same pid.  From the point of view of the shell, the child and the grandchild are the same process, and waitpid() will not stop until the grandchild terminates.

This issue should be closed: just use subprocess instead.