# libprocinfo



## Samuel Venable (Jul 5, 2020)

there appears to be not that many cross-platform process handling api's or libraries out there, so I happened to write one. A lot of things still need to be done before it will be ready for making an official FreeBSD port, and the equivalent packages for other major platforms.

Are there any FreeBSD developers here who would be interested in contributing or suggesting new features they would like to see?

You are free to contribute code for any platform you have experience with on GitHub, but this topic about the upcoming FreeBSD port.









						time-killer-games/enigma-dev
					

Download Extras for the ENIGMA Development Environment - time-killer-games/enigma-dev




					github.com
				




See the readme in the root directory for the list of included functions and data types, and brief documentation. I wanted some opinions here on whether this would be a desirable cross-platform library to have made officially available as a FreeBSD port. I was only planning to support FreeBSD and macOS out of the different BSD's, but if you want to expand the compatibility to use sysctl directly for all functionality to allow for other BSD's to be supported with the same code, the more platforms supported, the better. But again, focus on just FreeBSD and save discussions around other BSD's for GitHub.


----------



## unitrunker (Jul 7, 2020)

Suggest using typedef over #define:


```
#define window_t unsigned long long
#define process_t unsigned long
#define wid_t std::string
```

You have a namespace - that's good. But the main header file also has a using clause that injects stuff into the user's namespace - which defeats the purpose of namespaces at this level.


```
using enigma_user::string_replace_all;
```

Too much clever use of #define here:









						time-killer-games/enigma-dev
					

Download Extras for the ENIGMA Development Environment. - time-killer-games/enigma-dev




					github.com
				




Some people like this style. I do not.


----------



## Samuel Venable (Jul 21, 2020)

The #define's are for using it as a plugin for a particular game engine called "enigma", as that was the initial purpose it had, but I was intending to rebuild this as a static and shared library, in which case those definitions would be replaced with typedef's and such. That is only going to stay there in the short term. I am still ironing out what the complete list of functions will look like. i have a few I'm going to add but haven't yet, such as:

pids_from_name(name) - get all process id's that match a given executable name
pids_from_dir(dir) - get all processes id's that were launched from a given directory
pids_from_path(path) - get all process id's ran from a given absolute file path

...and of course I'd love to add more if anyone has a specific function or feature request.


----------



## frakswe (Jul 22, 2020)

needed /proc/pid/cwd for suckless simple terminal, and you just happened to come along..maybe time for me to get religious


----------



## Samuel Venable (Jul 22, 2020)

frakswe said:


> needed /proc/pid/cwd for suckless simple terminal, and you just happened to come along..maybe time for me to get religious


in my previous post where I shared those 3 functions planned, there was actually a fourth one I had problems remembering, and sure enough, cwd_from_pid() was it.

They'll be in there within the next day or two. I have to test something I just added today.


----------



## Samuel Venable (Jul 27, 2020)

frakswe it took longer than I thought to do it, mainly because of porting it to Windows was extra complicated:









						time-killer-games/libprocinfo
					

cross-platform library and c++ api for process-related functionality - time-killer-games/libprocinfo




					github.com
				




Anyway, I wrote the FreeBSD and Win32 versions of cwd_from_pid(pid), but there is a limitation with the Win32 version. Currently, you may only get the cwd of a pid on Windows when the current executable is the same archtecture as the target process. This probably won't change any time soon, assuming I ever figure out how to get around that.

Anyway, I have yet to do macOS and Linux. I digress. The FreeBSD port is done, so I assume that's all you needed:









						time-killer-games/libprocinfo
					

cross-platform library and c++ api for process-related functionality - time-killer-games/libprocinfo




					github.com


----------



## frakswe (Jul 28, 2020)

Excellent work, i suddenly got interested in Amiga and Amos coding but i'll report back when i've tried it out.


----------



## Samuel Venable (Aug 3, 2020)

I'm accepting more feature requests if anyone is interested. One of the possibilities I'm looking at is getting the stderr string of a process ran from process_execute() and process_execute_async(). Another idea would be to get the list of thread identifiers from a given process id. I don't want to add too many features to this, but I do want everything that would be most desirable for a cross-platform process library.


----------



## Samuel Venable (Sep 18, 2020)

Added a new function env_from_pid_ext(pid, name) which is basically the same as the posix getenv() but can get the value of environment variables based on the given name that belongs to a specific process id.

Also in the process of writing up proper documentation:








						docs.html
					

Shared with Dropbox




					www.dropbox.com
				




The documentation doesn't include any C++ code examples (yet) right now there are only GameMaker Language examples as this project was originally just meant to be an extension for GameMaker and ENIGMA. But the same basic logic in the GML code examples can be applied to write the C++ equivalent, which wouldn't be a lot of work to figure out.


----------

