> > >> 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 ---------------------------(end of broadcast)--------------------------- TIP 6: explain analyze is your friend
