- Windows Processes and Threads
- Process Creation
- Process Handle Counts
- Process Identities
- Duplicating Handles
- Exiting and Terminating a Process
- Waiting for a Process to Terminate
- Environment Blocks and Strings
- Example: Parallel Pattern Searching
- Processes in a Multiprocessor Environment
- Process Execution Times
- Example: Process Execution Times
- Generating Console Control Events
- Example: Simple Job Management
- Job Objects
A process can obtain the identity and handle of a new child process from the PROCESS_INFORMATION structure. Closing the child handle does not, of course, destroy the child process; it destroys only the parent's access to the child. A pair of functions is used to obtain current process identification.
HANDLE GetCurrentProcess (VOID) DWORD GetCurrentProcessId (VOID)
GetCurrentProcess actually returns a pseudohandle and is not inheritable. This value can be used whenever a process needs its own handle. You create a real process handle from a process ID, including the one returned by GetCurrentProcessId, by using the OpenProcess function. As is the case with all sharable objects, the open call will fail if you do not have sufficient security rights.
HANDLE OpenProcess ( DWORD dwDesiredAccess, BOOL bInheritHandle, DWORD dwProcessId)
Return: A process handle, or NULL on failure.
dwDesiredAccess determines the handle's access to the process. Some of the values are as follows.
SYNCHRONIZE This flag enables processes to wait for the process to terminate using the wait functions described later in this chapter.
PROCESS_ALL_ACCESS All the access flags are set.
PROCESS_TERMINATE It is possible to terminate the process with the TerminateProcess function.
PROCESS_QUERY_INFORMATION The handle can be used by GetExitCodeProcess and GetPriorityClass to obtain process information.
bInheritHandle specifies whether the new handle is inheritable. dwProcessId is the identifier of the process requiring a handle.
Finally, a running process can determine the full pathname of the executable used to run it with GetModuleFileName or GetModuleFileNameEx, using a NULL value for the hModule parameter. A call from within a DLL will return the DLL's file name, not that of the .EXE file that uses the DLL.