Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Testing for a process

42 views
Skip to first unread message

James Moe

unread,
Sep 16, 2012, 12:01:01 AM9/16/12
to
Hello,
How do I test, from a program, if some other process is running given
its process ID (PID)?
The external process is started with DosStartSession() and returns the
process ID since SSF_RELATED_CHILD is indicated. Unfortunately,
DosWaitChild() always returns ERROR_WAIT_NO_CHILDREN regardless of the
existence of the external process. I can see no obvious (to me) kernel
function that gives information about other processes.

--
James Moe
jmm-list at sohnen-moe dot com

Steven Levine

unread,
Sep 16, 2012, 3:51:35 AM9/16/12
to
On Sun, 16 Sep 2012 04:01:01 UTC, James Moe
<jimoe...@sohnen-moe.com> wrote:

Hi James,

> How do I test, from a program, if some other process is running given
> its process ID (PID)?

It depends on how you started the program.

> The external process is started with DosStartSession() and returns the
> process ID since SSF_RELATED_CHILD is indicated. Unfortunately,
> DosWaitChild() always returns ERROR_WAIT_NO_CHILDREN regardless of the
> existence of the external process.

TTBOMK, you are mis-using DosWaitChild. Note that the remarks say
that DosWaitChild is used to detect completion of programs started by
DosExecPgm.

To monitor session completion, use a termination queue. You can also
use DosQuerySysState, but this is a bit of a hack.

Steven

--
---------------------------------------------------------------------
Steven Levine <ste...@earthlink.bogus.net>
eCS/Warp/DIY etc. www.scoug.com www.ecomstation.com
---------------------------------------------------------------------

Dave Saville

unread,
Sep 16, 2012, 6:37:10 AM9/16/12
to
On Sun, 16 Sep 2012 04:01:01 UTC, James Moe
<jimoe...@sohnen-moe.com> wrote:

BIt of a hack but you could do a popen() of PSTAT and parse the
output.

--
Regards
Dave Saville

James Moe

unread,
Sep 16, 2012, 6:42:32 PM9/16/12
to
On 09/16/2012 12:51 AM, Steven Levine wrote:
>
>> The external process is started with DosStartSession() and returns the
>> process ID since SSF_RELATED_CHILD is indicated. Unfortunately,
>> DosWaitChild() always returns ERROR_WAIT_NO_CHILDREN regardless of the
>> existence of the external process.
>
> TTBOMK, you are mis-using DosWaitChild. Note that the remarks say
> that DosWaitChild is used to detect completion of programs started by
> DosExecPgm.
>
Oops. Missed that part.

> To monitor session completion, use a termination queue. You can also
> use DosQuerySysState, but this is a bit of a hack.
>

Global.Hq is the handle for a termination queue.

REQUESTDATA request = {0};
PVOID pdata;
ULONG datalen,
queue_posn;
BYTE priority;
APIRET rc;

queue_posn = 0; // Start at beginning of queue; receives position.
priority = 0; // Minimal priority
if (NULLHANDLE != Global.Hq)
rc = DosPeekQueue(Global.Hq, &request, &datalen, &pdata,
&queue_posn, DCWW_NOWAIT, &priority, NULLHANDLE);

The return code, rc, is always ERROR_INVALID_PARAMETER (87). But I do
not see which parameter is invalid.

Paul Ratcliffe

unread,
Sep 16, 2012, 8:15:36 PM9/16/12
to
On Sun, 16 Sep 2012 10:37:10 +0000 (UTC), Dave Saville
<da...@invalid.invalid> wrote:

>> How do I test, from a program, if some other process is running given
>> its process ID (PID)?
>
> BIt of a hack but you could do a popen() of PSTAT and parse the
> output.

Oh for God's sake, NOOOOOOOOOO.

Alex Taylor

unread,
Sep 16, 2012, 10:20:01 PM9/16/12
to
On Sun, 16 Sep 2012 10:37:10 UTC, "Dave Saville" <da...@invalid.invalid> wrote:

> > How do I test, from a program, if some other process is running given
> > its process ID (PID)?
> > The external process is started with DosStartSession() and returns the
> > process ID since SSF_RELATED_CHILD is indicated. Unfortunately,
> > DosWaitChild() always returns ERROR_WAIT_NO_CHILDREN regardless of the
> > existence of the external process. I can see no obvious (to me) kernel
> > function that gives information about other processes.
>
> BIt of a hack but you could do a popen() of PSTAT and parse the
> output.

More than a bit... if that's the approach you want to take, it'd be far
more efficient to get a process list directly using DosQuerySysState().


--
Alex Taylor
Fukushima, Japan
http://www.altsan.org

Please take off hat when replying.

Paul Ratcliffe

unread,
Sep 17, 2012, 12:20:32 PM9/17/12
to
On Sun, 16 Sep 2012 15:42:32 -0700, James Moe <jimoe...@sohnen-moe.com>
wrote:

>> To monitor session completion, use a termination queue. You can also
>> use DosQuerySysState, but this is a bit of a hack.
>
> Global.Hq is the handle for a termination queue.
>
> REQUESTDATA request = {0};
> PVOID pdata;
> ULONG datalen,
> queue_posn;
> BYTE priority;
> APIRET rc;
>
> queue_posn = 0; // Start at beginning of queue; receives position.
> priority = 0; // Minimal priority
> if (NULLHANDLE != Global.Hq)
> rc = DosPeekQueue(Global.Hq, &request, &datalen, &pdata,
> &queue_posn, DCWW_NOWAIT, &priority, NULLHANDLE);
>
> The return code, rc, is always ERROR_INVALID_PARAMETER (87). But I do
> not see which parameter is invalid.

You have to supply a semaphore handle with DCWW_NOWAIT according to CPREF.
Read the Remarks page for DosPeekQueue.

James Moe

unread,
Sep 18, 2012, 1:43:27 AM9/18/12
to
On 09/17/2012 09:20 AM, Paul Ratcliffe wrote:
>>
>> The return code, rc, is always ERROR_INVALID_PARAMETER (87). But I do
>> not see which parameter is invalid.
>
> You have to supply a semaphore handle with DCWW_NOWAIT according to CPREF.
> Read the Remarks page for DosPeekQueue.
>
Thank you.
I did read the Remarks for DosPeekQueue(). The part about nowait and a
semaphore made it seem that the semaphore was optional.
I modified the code to use DCWW_WAIT instead, without a semaphore. The
function never returned even after the external process ended. The
process did end badly; I ended it by sending an interrupt via a process
killer.
Would a process ending that way fail to place anything in the
termination queue? I rather had the impression that the OS handled that
part of it, not the ending process.

Steven Levine

unread,
Sep 18, 2012, 3:20:00 AM9/18/12
to
On Mon, 17 Sep 2012 16:20:32 UTC, Paul Ratcliffe
<ab...@orac12.clara34.co56.uk78> wrote:

Hi,

> > if (NULLHANDLE != Global.Hq)
> > rc = DosPeekQueue(Global.Hq, &request, &datalen, &pdata,
> > &queue_posn, DCWW_NOWAIT, &priority, NULLHANDLE);
> >
> > The return code, rc, is always ERROR_INVALID_PARAMETER (87). But I do
> > not see which parameter is invalid.
>
> You have to supply a semaphore handle with DCWW_NOWAIT according to CPREF.
> Read the Remarks page for DosPeekQueue.

This is true. See

http://svn.netlabs.org/repos/fm2/trunk/dll/systemf.c

or

http://svn.netlabs.org/fm2/browser/trunk/dll/systemf.c

for an implementation. It's probably a bit more complicated than
James needs because it handles a large number of application types.

Rich Walsh

unread,
Sep 18, 2012, 2:31:27 PM9/18/12
to
On Sun, 16 Sep 2012 04:01:01 UTC, James Moe wrote:

> How do I test, from a program, if some other process is running given
> its process ID (PID)?
> The external process is started with DosStartSession() and returns the
> process ID since SSF_RELATED_CHILD is indicated. Unfortunately,
> DosWaitChild() always returns ERROR_WAIT_NO_CHILDREN regardless of the
> existence of the external process. I can see no obvious (to me) kernel
> function that gives information about other processes.

As always, no one has asked the fundamental question: "why are you using
DosStartSession() in the first place"? It may be the correct solution for
the issue at hand - or its use could be totally boneheaded. I don't see
how helping someone do the wrong thing is genuinely helpful.

So... what app is calling DosStartSession()? (PMMail, I'd guess.)
What program is it starting? Are you positive that it needs a new session?
Does your app (or some functionality therein) have to block until this
mystery process terminates? Etc, etc.

Also, have you considered using WinStartApp()?



--
== == almost usable email address: Rich AT E-vertise DOT Com == ==

James Moe

unread,
Sep 18, 2012, 2:31:26 PM9/18/12
to
On 09/17/2012 10:43 PM, James Moe wrote:
> I did read the Remarks for DosPeekQueue(). The part about nowait and a
> semaphore made it seem that the semaphore was optional.
>
I was incorrect. The Remarks clearly state that a semaphore is required.

James Moe

unread,
Sep 19, 2012, 1:28:53 PM9/19/12
to
On 09/18/2012 11:31 AM, Rich Walsh wrote:
>
> So... what app is calling DosStartSession()? (PMMail, I'd guess.)
> What program is it starting? Are you positive that it needs a new session?
> Does your app (or some functionality therein) have to block until this
> mystery process terminates? Etc, etc.
>
Yes, PMMail.
It is starting stunnel, a security proxy. Stunnel provides encrypted
data transfer for PMMail.
It originally used DosExecPgm() to start stunnel. DosStartSession()
can start a program without inheriting the current environment and file
handles. It was more of a debugging effort to eliminate a possibility
than any actual advantage of DosStartSession(). I then wanted to know if
the program was actually running, or be notified when it quit. Hence the
posting.

(The problem I am having is with files being closed but randomly
unavailable, sometimes for many seconds. For instance, a file is
created, written, closed, all with standard C functions. That file may
then be copied to another file, or renamed. In either case, sometimes
the copy/rename returns error 13, Permission Denied.
The last time I had a similar problem was when an external program was
started that inherited file handles, and closed those inherited handles
when it quit. The parent process was not pleased.)

> Also, have you considered using WinStartApp()?
>
No, I had not.

Paul Ratcliffe

unread,
Sep 19, 2012, 2:11:33 PM9/19/12
to
On Wed, 19 Sep 2012 10:28:53 -0700, James Moe <jimoe...@sohnen-moe.com>
wrote:

> The last time I had a similar problem was when an external program was
> started that inherited file handles, and closed those inherited handles
> when it quit. The parent process was not pleased.)

All programs close all file handles when they exit. The child closing
its handles has no effect on those of the parent.
Your analysis is flawed somewhere.
0 new messages