> > >> Redmond crowd should be able to figure out that
> recycling process
> > >> IDs instantly would be a stupid idea...)
> > > Can you explain more of this? IMHO, if we rely on feature
> like this,
> > > the difference is unstable-every-day vs. unstable-every-year.
> > The mere existence of the kill() primitive should bring to mind
> > reasons why it's a bad idea.
>
> CreateProcess - "The process is assigned a process
> identifier. The identifier is valid until the process
> terminates. It can be used to identify the process, or
> specified in the OpenProcess function to open a handle to the
> process. The initial thread in the process is also assigned a
> thread identifier. ..."
>
> TerminateProcess - "Terminates the specified process and all
> of its threads."
>
> TerminateProcess takes a HANDLE, not a process identifier.
Yes. You get the handle by doing OpenProcess() with PROCESS_TERMINATE
access.
The functions used to enumerate processes all return the process id, not
a HANDLE.(See Process32First/Process32Next). You use the HANDLE only
when you need to *modify* something (for example, killing it).
> Yes, they provide the "kill" primitive, but only as a
> compatibility measure.
They do? Where is it? Certainly not in the documented SDK that I can
see.
> A "good" Windows process, should
> maintain a HANDLE to the process, and kill the process using
> the HANDLE. This way, there is no race. The HANDLE is also
> how you wait for the process to terminate normally.
A "good" Windows process would be using threads ;-)
That's what the Windows API was written for, and that's why anything
that deals with multiple processes working together is a lot harder than
on Unix.
//Magnus