I want to execute one exe from another exe. but the other exe can not run if first exe is running.
So i want to run the exe and exit from the application before the second exe gets executed.
Any help on this.
Consider a third application, which you launch from your first app. The third one checks to be sure the first one has terminated, then launches the second app and terminates itself. I have had to do this in the past; it works fine.
I am not sure exactly how it is done in Windows, but I think that the general guidelines are the same between linux and windows:
You need to fork a child process, in Linux this is done using fork() function, in Windows I think you can use CreateProcess().
In this child process, you need to call one of the exec functions which changes the code of this child process to the code of any executable that you can specify as a parameter to the exec function.
The code, thus, should be something like this pseudo-code:
c= CreateProcess()
if (c == child)
{
exec("My other executable.exe")
}
This is the general procedure, but you need to figure out the syntax
You are going to need a process to sit in the middle if you are not allowed to have the two main processes executing simultaneously. Which means that you need three processes in total. The two main processes, A and C, and the broker in the middle, B. Here's how it goes down:
Process A executes.
Process A starts process B passing in its process
handle.
Process A terminates.
Process B waits on process handle for process A. That becomes signaled when process A has terminated.
Process B starts process C.
Process B terminates.
I'm assuming that you already know how to create processes, pass arguments to process, duplicate handles, wait on handles and so on.
Related
After starting a process with QProcess::startDetached, how can I stop it later?
Say the main program runs, then starts the detached process, which runs independently. The user closes the main program, then later opens it up again and wants to stop the process. How would I find the process and then stop it?
Is there a way I could prevent the application from the same process twice?
No, it will be decoupled from your application. You could get the the PID of it and then send a SIGSTOP on Linux, but this is platform specific and will not work without POSIX support, like with msvc. You would need to hand-craft your version therein.
Is there a way I could prevent the application from the same process twice?
Yes, by using lock file in the detached process. If that detached process happens to be written in at least partially Qt, you could use the QLockFile class.
If you happen to detach some platform specific process, then you have the same recurring issue again, for sure.
Here's the answer I figured out:
I first start the detached process that generates a unique id. That process write to a file whenever it runs (was a 1 minute timer). When it runs, it writes its id to a file. Then, if there happens to be another one that ran, if it sees a previous one ran, it just writes its id to the file and doesn't run, then, when the next one runs, it sees if its id is already in the file and if it is, it shuts itself off and clears the file, then the next run ends up running freely, being the only one running. This may end up skipping some time.
You can add a timestamp, too, as that might indicate it wasn't run recently and help with deciding whether or not to shut it down. The issue was if I just write the id to a file, when I turn the phone off, the file will say it's still running. The same applies to if it crashes.
My situation :
Process A will call process B, that means process B is the child process of process A.
How we can capture what process will be called by process A?
Example
Process A : bcc55.exe hello.c
Will automatically call process B : ilink32.exe
Now give you the process A, how to find the process B.
See my answer here to see how to enumerate child processes for a given windows process ID. You can first get the process ID by EXE name using the code here
You can hook the various CreateProcess* functions, run your own code (perhaps to record what's been called) and then call the original function with the same parameters. It can get fiddly though :)
Is there some portable way to check the number of parallel instances of my app?
I have a c++ app (win32) where I need to know how often it was started. The problem is
that several user can start it parallel (terminal server), so i cannot search the "running process" list because I'm not able to access the the list of other users.
I tried it with Semaphore (boost & win32 CreateSemaphore)
It worked, but now I have the problem if the app crashes (Assertion or just kill the process) the counter is not changed. (rebooting helps)
Also manually removing/resetting the semaphore counter in my code is not possible because I don't know if somebody else is running my application.
Edited to add:
Suppose you have a license that lets you run 20 full-functionality copies of your program. Then you could have 20 mutexes, named MyProgMutex1 through MyProgMutex20. At startup, your program can loop through the mutexes. If it finds a spare mutex that it can take, it stops looping and enters full-functionality mode. If it loops through all the mutexes without being able to take any of them, then it enters reduced-functionality mode.
Original answer:
I assume you want to make sure that only one copy of your process runs at once. (Or, for Terminal Server, one copy of your process per login session).
Your named semaphore solution is close. The right way to do this is a named mutex. Use CreateMutex to make the mutex, then call WaitForSingleObject with a timeout of zero. If WaitForSingleObject returns WAIT_TIMEOUT, another copy of the process is running. If it returns WAIT_OBJECT_0 or WAIT_ABANDONED, then you are the only copy of the process. You need to keep the mutex handle open while your program runs - either call CloseHandle when your process is about to exit, or just deliberately leak the handle and rely on Window's built-in cleanup to release the handle for you when your process exits. Windows will automatically increment the mutex's counter when your process exits.
The only thing I can think of that mitigates the problem of crashed processes is a kind of “dead man’s switch”: each process needs to update its status in regular intervals. If a process fails to do this, it’s automatically discarded from the list of active processes.
This technique requires that one of the processes acts as a server which keeps tab of whether other processes have updated recently. If the server dies, then another process can take over. This, in turn, requires that each process tests whether there still is a server alive.
Alternatively, each process can be its own server and keep track locally. This may be easier to implement than server-switching.
You can broadcast message and other instances of your application should send some response. You count responses - you get number of instances.
I have a little application, let's call it "launch.exe". It is a c++ appl.
What I do in it is I call system() 3 times to launch 3 other applications. let's call these A, B, and C.
problem #1
A, B, and C are GUI apps and "launch.exe" is not able to progress until A exits. Then it is stuck again until B exits. Then stuck again until C exits. I would like lauch.exe to be able to progress while the applications I have opened remain open.
Problem #2
Assuming that I am able to figure out a solution to problem #1, after A, B, and C are launched, I don't want "launch.exe" to stay open. I want launch.exe to close and I want A, B, and C to remain running.
Here is a scenario for you. Lets us say "launch.exe" only starts one application (let us call it A). Then, after A is started, if i close "launch.exe", A remains open.
OK...this is what I want but what just happened? Is A an orphan now? And if so, is this a problem?
And what if I closed A before I exited launch.exe? On the surface it seems OK, but what does it return to? If I launched an exe in cmd shell, it would return to that, but since I did it from a system() call in a c++ appl, does it return to my lauch.exe or does it become a zombie?
NOTES:
Why am I useing system()?
--Cause I need something that is Windows/Linux compatible.
--Cause I need to elevate privileges to admin level for some of the applications being launched.
--I should add that it is vital that A, B, and C be totally independent (for security reasons they should not share the same memory space or anything else).
--Last, some of the apps, B, and C are multi-threaded (I state this because I have read that some functions do not spawn multi-threaded applications properly. I'm not clear on reasons why.).
Use spawn instead, this won't block the launcher until the child exits.
Or, since you're already using Qt, use QProcess.
There is no portable way to spawn a subprocess as a different user, but the Windows-specific way is CreateProcessWithLogonW.
Why don't you start your A B C processes with ampersand "&" appended to command parameters
std::system ("ProcessA&");
std::system ("ProcessB&");
std::system ("ProcessC&");
This way your launcher will not wait for these processes to exit.
Then exit your launcher with QApplication::exit or QApplication::quit
Read this SO question to see the difference between fork/execvp and system().
I am creating an application in C++ gtk and if I press a button a threading process will start and I need to run the application if the window is closed also is it possible?
Under a Unix system (and since Windows 10), you create another process using the fork() function. To run a program you then use the execve() or similar.
However, that means you need to communicate with that other process using a pipe (see pipe() or pipe2()) or via the network.
Using a thread instead of a process allows you to run in the same memory & process and you can very easily shared everything between multiple threads.
As far as I know, the gtk loop just returns once the user selects the "Close Window" or similar exit function. It would be up for your main() function to make sure that it waits for all the threads to be done before exiting. For threads, this is usually done with a "join()". It will depend on the library you use to run your background process.
Note that in most cases people expect processes to exit whenever they ask the process to exit. Showing a window saying that your process is still running in the background (is busy) is a good idea for a process which runs a GUI. Especially, if you run your process from the console, it would not exit immediately after you closed the window, so letting the user know what's happening is important otherwise they are likely to hit Ctrl-C and kill the whole thing.
If you'd like the main to return but be able to keep the background threads running, it's a tad bit more complicated, but it uses both of the solutions I just mentioned:
create a pipe()
fork() (but no execve())
from within the forked app. (child) open Gtk window, background thread, etc.
when last Gtk window is closed, send message over pipe
parent process receives message and quits immediately
child process still attempts a "join()" to wait for the background thread
This way, the background process with threads created in (3) can continue to run (your function still needs to wait for all the threads to end with the "join()" call), however, the use has a sense of "the app. is done" since it returns to the next line on the prompt in your console even though a background process is still running.
The pipe() and wait on a message on the pipe() is not required if you don't mind having your application always running in the background.
Note: that usage of fork() is most often seen when creating processes that want to run in the background (i.e. services, often called servers under Unix). That's how they get their PPID set to 1.
On Windows, you need to create a Windows/Linux/Mac Service or run the process in background. On Linux you need to create a daemon service or run the process in the background. Services allow to automatically start the process on boot.