ProcessId==Process Handle?
zhouyi
HANDLE hProcess
Are they the same?
Uv
In a word: No.
Process ID is a system unique ID for a process.
Process handle is an index into the handle table for your process.
If you have found them to be the same, thats an amazing coincidence!
Le Chaud Lapin
No.
When MSDN says that there are objects created in the kernel for things
like processes, threads, files, mutexes, semaphores, events, etc...they
really mean it. So when you do a CreateProcess, there really is a
structure (written in C) that exists for the created process sitting in
the kernel. For every object created, there is only one corresponding
object structure in the kernel.
The process ID is a number that uniquely identifies that structure
throughout the entire system from within any process context.
Therefore, if you ask, which one, the ProcessID or the hProcess is the
"real" identifier, it is the ProcessID.
The hProcess is a handle that is essentially an index into a
per-process kernel-mode table. This hProcess has a value that is
meaningful only within the context of the process that is trying to use
it. When the hProcess is used, the kernel breaks the hProcess into
pieces and uses the pieces to incrementally index into several linked
tables, until ultimately it finds a structure corresponding to the
handle for that particular process. This structure is not the process
structure, but another structure that contains a pointer that points to
the actual process structure mentioned above. This
handle-structure-thing is also where the kernel enforces access control
against a object based on a handle to that object.
As you can imagine, the process structure will contain the ProcessID,
but it will not contain any hProcess handles. That would not make any
sense. Since many of the objects in Windows can have names, it is
possible for process A to get a handle installed in its handle table to
access and object O if it is able to name O, even though the object O
was created by process B. In fact, it is possible for 1000 processes
to all have handles in their respective handle tables allowing them
access to O.
The primary reasons for making a distinction between handles and ID's
(why use handles since ID's are unmistakable?) is for reference
counting and access control.
If 1000 processes have 1000 handles open against an object O, then the
kernel will note in O that there are 1000 references to it. When you
call CloseHandle() using a valid handle, the kernel decrements the
reference count. Once the reference count becomes zero, the kernel
destroys the object.
Also, process A could create O and have full writes to do whatever it
wants, while process B might get access to O also, with limited rights.
The handle-table-structure-things of A and B will have corresponding
access control limitations.
You can imagine why DuplicateHandle() works the way it does. It
creates handles in handle tables that make sense to foreign processes.
It also sets up the access control for the foreign process that is to
receive the handle. Finally, if it works, it increments the reference
count on the object.
You will find that this dual-identifier module is prevalent throughout
Windows and is generally accepted as a virtue of operating system
design.
-Le Chaud Lapin-