Implements getppid in the os module on Windows systems. The getppid 
function was only available on Unix like systems, this diff patch brings 
this functionality to Windows systems.  This function will return the 
parent process Id, upon error it will return -1.  This differs from the 
Unix implementation that never fails.  Due to the way Windows returns the 
parent process Id, a never fail guarantee can not be made.  It should only 
fail in low memory conditions.  This patch is on the latest svn trunk (	
http://svn.python.org/projects/python/trunk).  This implementation should 
port to any python version (older or newer).  I have personally tested it 
against Python 2.5.4, 2.6.2, 3.1, and the aforementioned svn trunk.

I'm not qualified to comment on Windows-specific code, but two things:
- you should raise an appropriate exception on failure, not return -1
- the file is intended with tabs, not spaces

I didn't raise an exception because the Unix version never fails (or raises) so I thought to maintain compatibility I would always return a value.  Do you advise that I should change it?

As for the tabs...  This entire process is new to me and I am learning, it was just a mistake.

Implements getppid in the os module on Windows systems. The getppid 
function was only available on Unix like systems, this diff patch brings 
this functionality to Windows systems.  This function will return the 
parent process Id, upon error it raises a WindowsError. This differs 
from the Unix implementation that never fails.  Due to the way Windows 
returns the parent process Id, a never fail guarantee can not be made.  
This is a revision of a previous post.  The file Issue6394-1.diff 
contains the updated patches.

First, I checked that the API does exist on Window 2000. And python does
not have any "never fail guarantee", specially in low memory conditions.

Then, some remarks:

- If Process32First or Process32Next fail for any reason, "return
win32_error(...)" is called, but the GetLastError function won't find
the cause because CloseHandle will clear it.

- It would be nice to add a comment like "if the loop ends and our pid
was not found, GetLastError() will return ERROR_NO_MORE_FILES.  This is
an error anyway, so let's raise this."

- A unit test is necessary: it could use a subprocess and compare
getpid() with the child's getppid().

- The documentation should state what happens when the parent process
exits.  Is the ppid reset to zero?  Is it possible to have another new
process with the same ppid?

I have addressed the issues brought up by Amaury Forgeot d'Arc except 
for the unit test.  I will get a unit test in tommorrow.  Thank you for 
the feedback.  I have uploaded a new diff file Issue6394-2.diff.

- Should I remove the old diff files?

I ran some test with a parent process that had exited.  The code still 
returned the correct parent process id, even though the process does 
not exist.  I am not sure if process ids get recycled, but I am looking 
in to it.

Just some information, on Windows:
- process ids are re-used.
- parent process id is set at process creation time and never updated.
(Windows Internal 4th Ed. by Russinovich and Solomon).

Thus, I would say that a long running process can not rely on the value 
of its parent process id.  The parent may not be running, or the process 
id may have been re-used and the process with that id may not be in fact 
the actual parent.  Having said that, I don't know the algorithm that 
Windows uses for process ids, so collisions may be rare (or not).

-Do these same issues exist on Unix systems?

> Do these same issues exist on Unix systems?
No. When the parent exits, the child process is attached to the 'init'
process and getppid() returns 1.

And collisions are not rare at all. Actually it seems that you get the
same pid if you close and restart a program quickly.
That's why Windows apps prefer dealing with "process handles" instead of
"process ids"