To Kill A Process

Thread View: borland.public.cppbuilder.nativeapi

3 messages

[T] Back to Threads [V] Tree View [G] Group Articles

3 total messages Started by poojo hackma Thu, 01 Feb 2007 21:13

#2594

Author: poojo hackma
Date: Thu, 01 Feb 2007 21:13

29 lines
2312 bytes

I have 2 small programs that potentially could interfere with one another:

The first is CustomSetup.exe: It installs AutoRun.exe and MainApp.exe on 
removable media. If the media is not inserted, a message box pops up telling 
the user that the media must be inserted in order to install with a 
MB_RETRYCANCEL option.

The second is AutoRun.exe: It is placed on the removable media by 
CustomSetup.exe, and prompts to start MainApp.exe with CreateProcess 
whenever the media is inserted.

The Issue:
A Techs installs the program by running CustomSetup.exe. CustomSetup.exe 
(first detects that MainApp.exe is not already installed, then) detects that 
there is no removable media, and informs the Tech that the media needs to be 
inserted. The Tech inserts the media, which just happens to have AutoRun.exe 
and MainApp.exe already on it.

The Problem:
If AutoRun.exe can detect that CustomSetup.exe is running, it can close 
CustomSetup.exe ... or itself.

I'd like to use EnumWindows and GetWindowThreadProcessId within AutoRun.exe 
to find and close CustomSetup.exe (using WM_CLOSE), but I don't know how to 
locate it.. The closest functions I have found are GetWindowText and 
GetClassName, but it appears that neither is suitable since both are small 
"WinMain Only" programs (neither has a class or a window).

How can I find the CustomSetup.exe process? Any ideas?

Re: To Kill A Process

#2595

Author: Bob Gonder
Date: Thu, 01 Feb 2007 21:46

19 lines
1794 bytes

poojo hackma wrote:

>If AutoRun.exe can detect that CustomSetup.exe is running, it can close 
>CustomSetup.exe ... or itself.
>I'd like to use {} within AutoRun.exe to find and close CustomSetup.exe

I think a named pipe could do the job.
CustomSetup creates a pipe named "MyCompanyCustomSetup", and looks for
data on the pipe.
AutoRun tries to open the named pipe.
If fails, ok, Setup not running.
If succeeds, send short piece of data on the pipe that CustomSetup
will interpret as "go away".
CustomSetup would them close the pipe and self terminate.

Alternative, CustomSetup creates an event and waits for it.
AutoRun signals the event.
CustomSetup self terminates when the event is signaled.
CustomSetup can also use the event to signal itself to shut down.

Re: To Kill A Process

#2205

Author: Remy Lebeau (TeamB)
Date: Fri, 23 Mar 2007 03:48

28 lines
1955 bytes

"poojo hackma" <poojo.com/mail> wrote in message
news:45c257c5$1@newsgroups.borland.com...

> If AutoRun.exe can detect that CustomSetup.exe is
> running, it can close CustomSetup.exe ... or itself.

Have both CustomSetup.exe and AutoRun.exe (and optionally MainApp.exe
as well) create a mutex with the same name when run, and release it on
exit.  GetLastError() will return whether the mutex already existed or
not.  This way, CreateSetup.exe can detect whether AutoRun.exe is
already running, and vice versa.

> I'd like to use EnumWindows and GetWindowThreadProcessId
> within AutoRun.exe to find and close CustomSetup.exe
> (using WM_CLOSE)
>
> How can I find the CustomSetup.exe process?

You don't need to.  Just have AutoRun.exe (and MainApp.exe) exit if it
detects that CustomSetup.exe is already running.  Maybe
CustomSetup.exe is installing a new version of AutoRun.exe and
MainApp.exe (or recovering a previous install), so they shouldn't be
running in that situation so that CustomSetup.exe can overwrite the
files.


Gamit

Thread Navigation

This is a paginated view of messages in the thread with full content displayed inline.

Messages are displayed in chronological order, with the original post highlighted in green.

Use pagination controls to navigate through all messages in large threads.

Back to All Threads