GetExitCodeProcess

[mattintelnetfort]

We are trying to check if another process is still running. We have the process ID so we're calling OpenProcess(), this seems to work OK but we noticed that we sometimes get a non zero process handle for processes that have recently been closed - this in itself seems strange. Since OpenProcess() seemed unreliable for determining if process was still running, we are trying to call GetExitCodeProcess() to see if the process is STILL_ACTIVE. We coded in visual C++ (VS2005) and all seems to work OK and reliably identifies if process is STILL_ACTIVE. Our immediate problem is we cannot get GetExitProcess() to do anything but abort in Fortran. This is likely a Fortran coding mistake on our part; can someone provide some guidance or fortran code snippet? We are currently doing the following:

INTEGER*4IRETURN, IHANDLE, ISTATUS, IPID

IPID=226 !A running process

IHANDLE=OpenProcess(PROCESS_ALL_ACCESS, FALSE, IPID)

IRETURN=GetExitCodeProcess(IHANDLE, ISTATUS) !THIS ABORTS

Thanks

[Steven_L_Intel1]

Use loc(istatus) when you call GetExitCodeProcess.

[mattintelnetfort]

Your suggestion seems to work, thanks.

1) Why is this required, when for other output parameters it is not required to pass in the internal address?

2) Also, the help page for LOC says that you cannot pass LOC result as an actual argument. Based on your suggestion, I'm passing LOC(X) to GetExitCodeProcess. What's the concern here, or am I mis-interpreting?

[Jugoslav_Dujic]

MattIntelNETFort:

1) Why is this required, when for other output parameters it is not required to pass in the internal address?

In the original Windows C code, that argument is declared as LPDWORD, which evaluates to an int*. However, in Fortran INTERFACE in Kernel32.f90, it is translated as INTEGER(LPDWORD) (i.e. address-by-value), not as INTEGER(DWORD), REFERENCE. I think that's an error (i.e. inconsistence) introduced by Compaq/Intel (semi-automatic) translation code from C headers to Fortran, but it was made long time ago, and is kept like that for backward compatibility (I suppose).

At least, It's consistent throughout -- whenever there's an pointer-to-integer argument in Windows headers (LPDWORD, LPHANDLE, LPINT, ...), you need a LOC() in the calling sequence.

MattIntelNETFort:

2) Also, the help page for LOC says that you cannot pass LOC result as an actual argument. Based on your suggestion, I'm passing LOC(X) to GetExitCodeProcess. What's the concern here, or am I mis-interpreting?

No, you're misinterpreting. Basically, the limitation applies to passing the LOC function itself, not the expresion containing LOC (like (LOC(x)) ). [Not that I could imagine why would anyone pass LOC around, so why is that statement given so prominent place in the documentation is beyond me. Much like: "Bananas are tasty tropical fruits which you shouldn't push in your ears." ]

[Steven_L_Intel1]

LOC is one of a small number of intrinsic functions that cannot be passed as arguments, so the warning is appropriate.

When we got the interfaces from Microsoft originally, they all had these LPxxxx arguments declared as integers, intending that you use LOC. Over the years, we changed many of them to allow you to pass the actual variable and added the IGNORE_LOC attribute to allow for code that uses LOC to still work. Evidently we missed this one (and I'm sure some others.)

I've noted this for when we next do a cleanup of the Win32 API declarations.