Query regarding stopping an executable programatically

[madhu]

Query regarding stopping an executable programatically :

I have an exe running in the background.How can I stop this instance
of exe programatically using C++?

Thanks.

[Michael]

"madhu" <madhu@covisible.com> wrote:
>
>Query regarding stopping an executable programatically :
>
> I have an exe running in the background.How can I stop this instance
>of exe programatically using C++?
>
> Thanks.
>
>
>


Hi!

The only way I know is Sleep(milliseconds to stop) or
Sleep(INFINITE) for infinite delay.

[Sunil Dandekar]

"madhu" <madhu@covisible.com> wrote:
>
>Query regarding stopping an executable programatically :
>
> I have an exe running in the background.How can I stop this instance
>of exe programatically using C++?
>
> Thanks.
>
>
>

[Sunil Dandekar]

"madhu" <madhu@covisible.com> wrote:
>
>Query regarding stopping an executable programatically :
>
> I have an exe running in the background.How can I stop this instance
>of exe programatically using C++?
>
> Thanks.
>

Have you tried calling exit() function ? This is part of stdlib.h

[Ted]

Danny is correct with regards to Visaul C++. The header <psapi.h> should
give you all you need to obtain handles to running processes and to shut
them down or just monitor them. I have used this with non COM objects as
a ping mechanism.


Danny Kalev <dannykk@inter.net.il> wrote:
>exit stops the process in which it was called. In this case I believe
>the OP wishes to terminate a running process from another running
>process, something similar to kill() in Unix. I bet Windows API has a
>similar function. My lucky guess would be KillProcess()?
>
>Danny
>
>Sunil Dandekar wrote:
>>
>> "madhu" <madhu@covisible.com> wrote:
>> >
>> >Query regarding stopping an executable programatically :
>> >
>> > I have an exe running in the background.How can I stop this instance
>> >of exe programatically using C++?
>> >
>> > Thanks.
>> >
>>
>> Have you tried calling exit() function ? This is part of stdlib.h

[Danny Kalev]

exit stops the process in which it was called. In this case I believe
the OP wishes to terminate a running process from another running
process, something similar to kill() in Unix. I bet Windows API has a
similar function. My lucky guess would be KillProcess()?

Danny

Sunil Dandekar wrote:
>
> "madhu" <madhu@covisible.com> wrote:
> >
> >Query regarding stopping an executable programatically :
> >
> > I have an exe running in the background.How can I stop this instance
> >of exe programatically using C++?
> >
> > Thanks.
> >
>
> Have you tried calling exit() function ? This is part of stdlib.h

[BT]

The right API is TerminateProcess(...).
Note that TerminateProcess should be used only in extreme circumstances -
the DllMain methods of the DLLs will not be called, synchronization objects
will stay in an unstable state, etc.



"Ted" <TTarney@hotmail.com> wrote:
>
>Danny is correct with regards to Visaul C++. The header <psapi.h> should
>give you all you need to obtain handles to running processes and to shut
>them down or just monitor them. I have used this with non COM objects as
>a ping mechanism.
>
>
>Danny Kalev <dannykk@inter.net.il> wrote:
>>exit stops the process in which it was called. In this case I believe
>>the OP wishes to terminate a running process from another running
>>process, something similar to kill() in Unix. I bet Windows API has a
>>similar function. My lucky guess would be KillProcess()?
>>
>>Danny
>>
>>Sunil Dandekar wrote:
>>>
>>> "madhu" <madhu@covisible.com> wrote:
>>> >
>>> >Query regarding stopping an executable programatically :
>>> >
>>> > I have an exe running in the background.How can I stop this instance
>>> >of exe programatically using C++?
>>> >
>>> > Thanks.
>>> >
>>>
>>> Have you tried calling exit() function ? This is part of stdlib.h
>

[ralph]

"BT" <boaz@iname.com> wrote:
>
>The right API is TerminateProcess(...).
>Note that TerminateProcess should be used only in extreme circumstances
-
>the DllMain methods of the DLLs will not be called, synchronization objects
>will stay in an unstable state, etc.
>

Whoa!

Just in case some poor unsuspecting soul is lurking about...

Always use ExitProcess()!

Before using TerminateProcess() call your local Crisis Hotline, take a vigorous
walk (except in Seattle), go someplace with lots of loud music and BRIGHT
lights, re-paper your bathroom, clean-out your garage...

If things are so bad that ExitProcess() won't work then you are going down
ugly anyway - Don't compound the devastation! Take the above advice, then
come back back and re-engineer your code. TerminateProcess() is provided
only for the O/S to use.

TerminateProcess is similar to creating longJumps with random addresses.
Well, actually the latter is safer, because you can always get lucky with
a random address. Seldom is this so with TerminateProcess.

Besides TerminateProcess and ExitProcess are not for other processes to use
to close another process down. (They are not Unix "Kills".) They are internal
forms of self-destruction. Investigate assigning your utility to a Task Group,
WM_CLOSE, signalling, etc., any form of IPC notification.

-ralph

[Danny Kalev]

ralph wrote:
>
> "BT" <boaz@iname.com> wrote:
> >
> >The right API is TerminateProcess(...).
> >Note that TerminateProcess should be used only in extreme circumstances
> -
> >the DllMain methods of the DLLs will not be called, synchronization objects
> >will stay in an unstable state, etc.
> >
>
> Whoa!
>
> Just in case some poor unsuspecting soul is lurking about...
>
> Always use ExitProcess()!
>
> Before using TerminateProcess() call your local Crisis Hotline, take a vigorous
> walk (except in Seattle), go someplace with lots of loud music and BRIGHT
> lights, re-paper your bathroom, clean-out your garage...
>
> If things are so bad that ExitProcess() won't work then you are going down
> ugly anyway - Don't compound the devastation! Take the above advice, then
> come back back and re-engineer your code. TerminateProcess() is provided
> only for the O/S to use.
>
> TerminateProcess is similar to creating longJumps with random addresses.
> Well, actually the latter is safer, because you can always get lucky with
> a random address. Seldom is this so with TerminateProcess.
>
> Besides TerminateProcess and ExitProcess are not for other processes to use
> to close another process down. (They are not Unix "Kills".) They are internal
> forms of self-destruction. Investigate assigning your utility to a Task Group,
> WM_CLOSE, signalling, etc., any form of IPC notification.

....which still leaves us with question: what would be the equivalent of
Unix kill() call under Windows? In other words, how would one process
ask another process to shutdown gracefully?

Danny

[ralph]

Danny Kalev <dannykk@inter.net.il> wrote:
>
>....which still leaves us with question: what would be the equivalent of
>Unix kill() call under Windows? In other words, how would one process
>ask another process to shutdown gracefully?
>
>Danny

The short answer, unfortunately, is there is no simple way. That is, other
than each process needs to design its own "clean" way of shutting down and
"listen" for WM_CLOSE or some other message or notification device.

You can give a process a gentle tap on the shoulder with hopes it will acknowledge
it, or slam it with a large mallet. There is no in between.

This has always been a problem with Windows because Windows doesn't maintain
a parent/child relationship between process (as in Unix). It is pretty much
'launch and forget', in a sense they are all orphans. You need to provide
your own babysitting service. Another difficultly is the fact that processes
themselves are not the primary "execution" unit - threads are - and processes
can have a ton of threads. There is no 'kill' procedure as there is in Unix.

Windows "kill" utilities are equally limited, Task Manager for example, resorts
to TerminateProcess when all else fails to get the app's attention. Things
are improving some. Win2k provides some job control, and there is a "kill"
utility included with the Win2k resource kit. (Although it is basically only
a findID-sendMsg-waitfortimeout-KILL-while keeping your fingers crossed-process.)

Part of problem is very analogous to C++ efforts to implement exception handling.
It ain't as easy as it looks. Not without adding extra record-keeping, to
keep Windows lean, this was left out.

Another analogy can be found between C++ classes and the need for a ~dstor.
You need to provide one if you are dynamically managing resources. In C++
you get punished rather quickly for forgetting to not do so. With a Windows
app you can get away with not providing for one, most of the time, and unfortunately
most developers skip that step.

-ralph