What's a good robust way to query processes for their help or framework origin, especially in Windows?
I've got an automated testing module that queries binaries that fit a special name pattern with
--help to see what test framework, if any, was used to compile that test binary, so it can give it special command treatment depending on the test mode's objective.
The problem is that since it won't be only used by me, I anticipate that binaries that require manual interaction before they quit will be triggered for Murphy's law and subsequently fail to exit on their own.
I'd prefer my module to be robust enough to handle this scenario, so I thought about launching that process within another process, getting its PID, and setting up some kind of observer pattern to meaningfully monitor it over time or events triggered, whichever first.
I anticipate no problems with that, which worries me :) I feel like I'm missing an important currently nebulous corner-case. I also wonder if there's a better way to check binaries for their framework origins used than doing
--help queries to search for framework help message output patterns.
I'd really like to skip the whole, running binaries blindly to figure out what kind of test binary they are, step, but I don't know if I can do this reliably, dynamically, in a generic approach.
- Can a binary's origin, if created within a framework, be somehow detected in a non-framework-specific way besides a help query? That includes common approaches that aren't necessarily universally embraced, or common approaches doled out by each framework in an easy way; meaning, I could make a handful of small modules for supported frameworks that are known. (answered in comments)
- If I use a dedicated process to check the status of a process that I've launched, can I safely handle all spawned process responses? Crashes, unresponsiveness, etc, stuff like that. For example, if a missing DLL triggering an error-pop-up even when launched from command-line.