xproc: get process information from foreign processes

From: Samuel Venable (samuelvenable_at_[hidden])
Date: 2022-07-20 00:34:13

Hi all.

The main developer of the boost process library liked what he saw when I showed him my xproc API. He recommended me to send it to the boost mailing list and see what the other developers at boost think of it and whether it could be modified and adjusted into making it worthy of becoming an official part of the boost libraries. The Windows build currently only works with MSYS2/MinGW, see the open issue here for the full details on what works and what doesn't on the Windows platform and why: currently known Windows-related bugs · Issue #1 · time-killer-games/xproc (github.com)<https://github.com/time-killer-games/xproc/issues/1>

The build.sh to build and example.sh to test is all you need to test all features, the only thing that isn't verified by the scripts is whether any memory leaks exist, and afaik in my testing Windows might be the only platform whith memory leaks, but its very unclear to me how to debug the source of them, because the code looks very correct, as I'm freeing memory everywhere online Microsoft documentation tells me to. Also supports Mac, Linux, FreeBSD, DragonFly BSD, NetBSD, and OpenBSD. If I ever find hardware that will work with an Illumos-based Operating System, then that will be added to the mix, (I refuse to use a VM, my personal hang-up).

If the libprocps library the linux version depends on were ported to Android, that is another potential platform, but the "Enable Windowing Macro" will need to not be defined as that is more of a desktop-related thing. iOS can work with windowing disabled as well, but some sysctl() with KERN_PROCARGS2 may only work when running in developer/debug mode due to Apple's publishing restrictions. Linux and android are the only platforms with the third party library dependency. All other platforms only rely on dependencies already provided by the OS base and/or kernel.

Here's everything you need for the API to work on most platforms, source & header...

  *   xproc/process.cpp at main · time-killer-games/xproc (github.com)<https://github.com/time-killer-games/xproc/blob/main/apiprocess/process.cpp>

  *   xproc/process.h at main · time-killer-games/xproc (github.com)<https://github.com/time-killer-games/xproc/blob/main/apiprocess/process.h>

And only on Windows you will need these helper blobs generated by the build script...

  *   xproc/process32.h at main · time-killer-games/xproc (github.com)<https://github.com/time-killer-games/xproc/blob/main/apiprocess/process32.h>

  *   xproc/process64.h at main · time-killer-games/xproc (github.com)<https://github.com/time-killer-games/xproc/blob/main/apiprocess/process64.h>

Here's an example of how to use the library and repository source tree...

  *   xproc/main.cpp at main · time-killer-games/xproc (github.com)<https://github.com/time-killer-games/xproc/blob/main/main.cpp>

  *   time-killer-games/xproc (github.com)<https://github.com/time-killer-games/xproc>
  *

You guys have my permission to relicense this code under any version of the Boost license we can agree on if this work gets accepted at any point in time. All functions get process information in their current state at the time the functions are called expect on macOS KERN_PROCARGS2 gets the cmdline and environ of the process in its initial state when the process first launched, so if the cmdline or environ get modified after initialization or process lanch, you will have no way to get the updated values (OS-level limitation of macOS). Lastly, I have helper functions to optionally suspend and resume foreign processes to avoid race conditions where applicable.

Let me know what you think and if you have any critiques or questions regarding my code do not hesitate to address that with me in a reply to this email!

Thanks!
Samuel