0

I'm writing a "glue logic" library (.dll) that connects an external, proprietary application to our program (.exe). When the application requests (calling the right library function) our program should be started, and then the library continues operation, receiving data from the program over sockets, transforming produced data to the format digestible by the application, and returning it when the application performs calls to 'data getter' functions of the library. enter image description here

I can start the program.exe relatively easily: fork a new process in the dll and call system() or exec() from the new process. On unload/end/stop call, I can send a 'quit' command to the program over sockets, and it will end just fine.

The problem is if the proprietary app, or the library crashes, is killed, or ends in an unexpected manner. I want program.exe to end, or be killed as well. While leaving it running wouldn't be that much of a problem, if the application is restarted, I'd need to search for old instances of the program, and kill them 'manually' before starting it anew (potentially with new startup parameters.)

I'd much prefer the program to die the moment the app or the library dies/crashes/is killed. I heard there is a special way of starting applications so they behave that way, but the person, who told me this can't recall how exactly it was done. Could you tell me?

Harry Johnston
  • 35,639
  • 6
  • 68
  • 158
SF.
  • 13,549
  • 14
  • 71
  • 107
  • 1
    Using [job objects](https://msdn.microsoft.com/en-us/library/windows/desktop/ms684161.aspx) might be applicable. – IInspectable Jul 19 '16 at 10:27
  • 1
    What is the Windows equivalent for pipes? Just send your commands via a pipe, and when your exe sees that the pipe has been closed, it terminates itself. No explicit quit command needed, and the exe will stop no matter how the main application died. – Sam Varshavchik Jul 19 '16 at 10:54
  • 2
    @IInspectable: Specifically, adding the process to a job, with limit flag `JOB_OBJECT_LIMIT_KILL_ON_JOB_CLOSE`. That way, when the parent (including the job object created within) dies for any reason, the child process is killed by the OS. – SF. Jul 19 '16 at 15:00
  • @HarryJohnston: The DLL is *loaded* and its functions are *called* in the same process as the application. But the DLL can spawn its own subprocesses, and they can crash without pulling the parent down. Plus to nitpick semantics, even if both are going down, there's always one to pin the blame on. Did the DLL crash, pulling the app down, or did the app crash and the OS unloaded the library once the loading app died? – SF. Jul 20 '16 at 01:06
  • Well, the subprocesses don't really belong to the DLL in particular from the operating system's viewpoint. But it sounds like you have a basically sound grasp of things, my mistake. (Comments deleted.) It was mainly your original title that made me think you might be confused; if the process dies for whatever reason, the library isn't unloaded (or at least not in the usual sense of the word) so it left me a bit confused as to what you actually wanted. – Harry Johnston Jul 20 '16 at 01:12
  • Although I do still wonder about this bit: "fork a new process in the dll and call system() or exec() from the new process", why would you have an intermediate process? Why not just launch `program.exe` directly from the DLL? (Did you mean "thread" rather than "process"?) – Harry Johnston Jul 20 '16 at 01:18
  • @HarryJohnston: Actually, I meant 'task'. Because 'program.exe' works continuously, producing the data, until told to quit. The library call would never return control to the parent app, 'system()' stopping until the program ends. (the 'program' is a device simulator, the 'app' is a visualisation/control/analysis thing for observing the device. The DLL can either connect to a remote physical device, or spawn the simulator.) Possibly there's a smoother way to launch an external .exe as a separate task, but I'm new to Windows API. – SF. Jul 20 '16 at 01:33
  • (and so, no need to apologize, I'm really blundering pretty blindly here; years of experience in Linux, but only started with Windows.) – SF. Jul 20 '16 at 01:38
  • "task" is an excessively overloaded word in Windows, so I'm not certain what you mean. :-) Regardless, the best way to solve your original problem is to put the child process into a job, and the best way to do that is to use the Win32 API CreateProcess() to create the child rather than the C runtime, so it's probably moot. (For future reference, the runtime does offer _spawn and the _P_NOWAIT option.) – Harry Johnston Jul 20 '16 at 01:50
  • Perhaps this is a duplicate of http://stackoverflow.com/q/53208/886887 ? The accepted answer includes some code that should meet your needs. – Harry Johnston Jul 20 '16 at 01:52
  • @HarryJohnston:Possibly; it appears the fact parent is a dll is irrelevant to the answer. – SF. Jul 20 '16 at 02:01
  • Excluding the case where the DLL is explicitly unloaded, yes, it makes no difference. Let me know if you can confirm that the code in the other question solves your problem and I'll close this one as a duplicate. – Harry Johnston Jul 20 '16 at 02:04

0 Answers0