in reply to Re^3: Killing a process on Windows (Win32::Process question)
in thread Killing a process on Windows (Win32::Process question)

But just starting a process doesn't automatically associate it with the parent.

From the documentation that was available, that certainly used to be the case, indeed the MSDN used to shy away from using terms like "parent" and "child". Since Win2000 I wouldn't be so sure, although it does depend on what you mean by associate.

The history of Win32 APIs to iterate through processes is checkered, there used to be at least two rival systems, or even browsing HKEY_PERFORMANCE_DATA. However from W2k there was this (code extract from an XS module):
static int getppid(void) { HANDLE hToolSnapshot; PROCESSENTRY32 Pe32 = {0}; BOOL bResult; DWORD PID; DWORD PPID = 0; PID = GetCurrentProcessId (); hToolSnapshot = CreateToolhelp32Snapshot(TH32CS_SNAPPROCESS, 0); if (hToolSnapshot == INVALID_HANDLE_VALUE) { return 0; } Pe32.dwSize = sizeof(PROCESSENTRY32); bResult = Process32First(hToolSnapshot, &Pe32); if (!bResult) return 0; while ( Process32Next(hToolSnapshot, &Pe32) ) { if (Pe32.th32ProcessID == PID) { PPID = Pe32.th32ParentProcessID; break; } } /* Expected */ if (GetLastError() == ERROR_NO_MORE_FILES) { SetLastError(ERROR_SUCCESS); } return PPID; }
Apologies for displaying a foreign language on this site.

Replies are listed 'Best First'.
Re^5: Killing a process on Windows (Win32::Process question)
by John M. Dlugosz (Monsignor) on May 15, 2009 at 17:48 UTC
    I also noticed in the perl source code for PP_system that it was doing its own associating, so it knew who to propagate the BREAK signal into. So, add to that processes that explicitly keep track of their (immediate) children.