I have an application A that I would like to be able to invoke arbitrary other processes as specified by a user in a configuration file.
Batch script B is one such process a user would like to be invoked by A. B sets up some environment variables, shows some messages and invokes a compiler C to do some work.
Does Windows provide a standard way for arbitrary processes to be terminated cleanly? Suppose A is run in a console and receives a CTRL+C. Can it pass this on to B and C? Suppose A runs in a window and the user tries to close the window, can it cancel B and C?
TerminateProcess is an option, but not a very good one. If A uses TerminateProcess on B, C keeps running. This could cause nasty problems if C is long-running, since we might start another instance of C to operate on the same files while the first instance of C is still secretly at work. In addition, TerminateProcess doesn't result in a clean exit.
GenerateConsoleCtrlEvent sounds nice, and might work when everything's running in a console, but the documentation says that you can only send CTRL+C to your own console, and so wouldn't help if A were running in a window.
Is there any equivalent to SIGINT on Windows? I would love to find an article like this one: http://www.cons.org/cracauer/sigint.html for Windows.
I guess I'm a bit late on this question but I'll write something anyway for anyone having the same problem.
My problem is similar in that I'd like my application to be a GUI application but the processes executed should be run in the background without any interactive console window attached.
I managed to solve this using GenerateConsoleCtrlEvent(). The tricky part is just that the documentation is not really clear on exactly how it can be used and the pitfalls with it.
My solution is based on what is described here. But that didn't really explain all the details either, so here is the details on how to get it working.
Create a new helper application "Helper.exe". This application will sit between your application (parent) and the child process you want to be able to close. It will also create the actual child process. You must have this "middle man" process or GenerateConsoleCtrlEvent() will fail.
Use some kind of IPC mechanism to communicate from the parent to the helper process that the helper should close the child process. When the helper get this event it calls "GenerateConsoleCtrlEvent(CTRL_BREAK, 0)" which closes down itself and the child process. I used an event object for this myself which the parent completes when it wants to cancel the child process.
To create your Helper.exe create it with CREATE_NO_WINDOW and CREATE_NEW_PROCESS_GROUP. And when creating the child process create it with no flags (0) meaning it will derive the console from its parent. Failing to do this will cause it to ignore the event.
It is very important that each step is done like this. I've been trying all different kinds of combinations but this combination is the only one that works. You can't send a CTRL_C event. It will return success but will be ignored by the process. CTRL_BREAK is the only one that works. Doesn't really matter since they will both call ExitProcess() in the end.
You also can't call GenerateConsoleCtrlEvent() with a process groupd id of the child process id directly allowing the helper process to continue living. This will fail as well.
I spent a whole day trying to get this working. This solution works for me but if anyone has anything else to add please do. I went all other the net finding lots of people with similar problems but no definite solution to the problem. How GenerateConsoleCtrlEvent() works is also a bit weird so if anyone knows more details on it please share.