Solved How to get in contact with C++ standard/STL developers?

[Samuel Venable]

This topic is regarding a heavily revised version of my former libprocinfo library.

I would like to propose the the C++ standard / STL developers that they add support for cross-platform getting of process information, (and in some cases setting, but only for the current process for security reasons). I am on my way to writing my own process library, and I intend to support a lot of platforms, (however I do not intend to support mobile, console, etc), only desktop and server are in my interest due to costs and time. I would like to contact these people with the intention to not only propose this be done, but also help them do it because it is an area of C++ programming I find very interesting and fun to work with.

Any idea how to get in touch with these guys? Anyone here have special ties or connections to these people? Where do they exist on the internet? They seem very mysterious and only the most worthy can get a hold of them, let alone know anything about them, thus I'd really appreciate this not to be another game of waiting a million years hoping for them to respond but they never do, like my experience with becoming a FreeBSD contributor, getting a hold of the development teams of such things for me has not been all that great. It's as if they don't want their projects to get healthier from a growing number of contributors by making it as hard as possible to make themselves accessible. The best experience I had with this is the developer of Kdialog who added a feature I requested but the rest of the KDE team was not so responsive to my desire to contribute to them as well.

Not to complain or anything, i just don't understand why these things are so complicated and it really seems it is made this way very intentionally, which is a bit odd. Here's my code currently:

xProcess/crossprocess.cpp at main · time-killer-games/xProcess

Cross-Platform Process Functionality. Contribute to time-killer-games/xProcess development by creating an account on GitHub.

github.com

I also included one function that is unrelated to process information, ProcIdKill(), which will kill a process based on its process id. I plan to expand this library to also allow for process execution, process group creation and management, getting the time stamp a process was spawned, causing the current process to wait for another process id or process group id to end, get the username a process id is running under, whether run as root/admin, and enumerating the tid's (thread id's associated with given process id, as well as getting all the tid's running on the current user session) and more stuff like that.

I'd also like to include functions which are windowing related, specifically enumerating window id's, normally useful for shell scripting, on platforms where a global window handle is used and not represented as an integer, but instead a pointer, it will be cased to an integer with the use of std::uintptr_t. macOS, unlike popular belief, has a global window id datatype as well, it is a CGWindowID, (unsigned long) but you can't do as much with it as you can a local window pointer (NSWindow *) which you may convert between the two for the current application in Objective-C++ with windowWithWindowNumber or windowNumber. Enumerating all Windows running on the current session, which pid created them, and on platforms that have no default windowing system like the *BSD's, Linux, and (I assume?) Solaris and Solaris-likes such as OpenIndiana, etc we would then use linkage with libffi or some similar method to call X11 and Wayland related code depending on availability though fails with an error code when no display is found, with an X11 fallback when WAYLAND_DISPLAY is empty or doesn't exist in the process environment block of the current application. Also, if I am looking for contributors, if any FreeBSD devs want to help, please do. We can discuss FreeBSD related code in this topic, however, keep the discussion of other platforms elsewhere and not on the FreeBSD forums as the rules go.

The nice thing about calling X11 and Wayland code with libffi is you won't need the X11 or Wayland dependencies installed to use this library, it will just fail safely.

I only mention in the OP other platforms to keep everyone in the loop of what my plan is and how this stuff will work.

Thanks!
Samuel

 

[msplsh]

This would belong in Boost, not STL

 

[kpedersen]

WG21 is the group:
https://isocpp.org/std/the-committee

They have a low volume mailing list that I am also signed up to. It is quite interesting to see what sorts of things go through.

You can submit a proposal here:
https://isocpp.org/std/submit-a-proposal

However just be aware that C++ doesn't have a GUI system for a reason. Also, there are a number of platforms (i.e embedded) that the concept of process information doesn't make sense.

You should probably discuss a little on their forums first to test the water. Go into it with a mindset not expecting to get a proposal in, but to learn something new about how they would already approach this issue.

I have discussed a few ideas with them about an official standardized "debug STL". It was very interesting and unlike stack overflow / reddit, you generally know that everyone there is very knowledgeable in their field.

 

[Samuel Venable]

WG21 is the group:
https://isocpp.org/std/the-committee

They have a low volume mailing list that I am also signed up to. It is quite interesting to see what sorts of things go through.

You can submit a proposal here:
https://isocpp.org/std/submit-a-proposal

However just be aware that C++ doesn't have a GUI system for a reason. Also, there are a number of platforms (i.e embedded) that the concept of process information doesn't make sense.

You should probably discuss a little on their forums first to test the water. Go into it with a mindset not expecting to get a proposal in, but to learn something new about how they would already approach this issue.

I have discussed a few ideas with them about an official standardized "debug STL". It was very interesting and unlike stack overflow / reddit, you generally know that everyone there is very knowledgeable in their field.

Interesting, so I would do this as a learning experience, but know off-hand they won't consider it for reasons you gave? lol Also note from what I mentioned I do have a backup plan for platforms that have no windowing installed or available, although for embedded systems and some consoles that have no real concept of process id's in the way that is the norm, perhaps that would be omitted from the standard for such platforms, which could be mentioned in the docs. Although that may lead to some level of confusion, that's to be expected from people who refuse to RTFM, and we've all been there at least once.

This would belong in Boost, not STL

I will look into that if they don't consider it, actually, but from what it sounds, that's probably what is going to happen.

 

[msplsh]

but know off-hand they won't consider it for reasons you gave

Unless you have some mind-altering revelation on the state of GUIs that unify all the paradigms, just a quick look at WG21's "study group" infographic shows that they aren't even thinking about incorporating graphical anything into STL.

SG14 probably only covers game-specific engine accelerations. The meeting minutes from last month focuses on... pointers.
SG13 is explicitly low level.

I would call this "reading the room." Your stuff is focused on third party libraries and software like X, Wayland, Windows, etc. STL is lower level than that.

 

[msplsh]

i just don't understand why these things are so complicated and it really seems it is made this way very intentionally, which is a bit odd

They're complicated by necessity of the subject matter. That's why there's only so many of them. They're different because nobody is going to spend all the effort to make the same "thing" and then not sufficiently differentiate themselves in a way they thing is better.

Looking at your xProcess thing, it looks like interesting functions, but perhaps not generally useful. Why would anybody want to do this on a regular basis?

 

[ralphbsz]

May I suggest something: Can you explain, in relatively brief form, what your new interfaces do, and how they address a need that is currently unmet? Think of it as an "elevator pitch". You need this for us to understand how to help finding the correct forum, and you'll need this (a thousand times) when you start working with standards bodies.

I would like to propose the the C++ standard / STL developers that they add support for cross-platform getting of process information, ...

This is not a C++ language question. The language doesn't concern itself with the concept of process. It handles things like "what is a pointer" and "how do you do inheritance". It is not even (or even less?) an STL question. The STL is about questions like "what does it mean to put something into a vector, or iterate over a map".

It is an operating system interface question. From that viewpoint, the correct community would be POSIX, or perhaps Boost. Beware of Posix: It's mission is (or rather was) to standardize divergent Unix-like server/desktop OSes, in a nutshell fix the split between SysV and BSD. It isn't heavily into accepting new interfaces.

I would like to contact these people with the intention to not only propose this be done,

The standards committees don't implement. The standardize the interfaces that implementors should adhere to. On the other hand, you pretty much have a fully functional sample implementation available for standards bodies to consider even looking at it. And you need to carefully think through the copyright situation of the sample implementation.

Anyone here have special ties or connections to these people?

Not to the C++ committee, and for POSIX only storage and file system people (some of which I know through SNIA and through T10).

They seem very mysterious and only the most worthy can get a hold of them, let alone know anything about them, ...

They don't hide; at least in the case of the ones I have interfaces with, they are all easy to reach via mail aliases and mailing lists. The membership of the committee can be pretty easily found on the web (perhaps not an official list, but for example in people's LinkedIn profile). The trick is to find one member of the committee and ask them for advice. For storage, I would have said "send an e-mail to George Penokie", but he's long retired.

Suggestion: At the next Usenix, walk the hallway, and ask who is on the POSIX committees.

I also included one function that is unrelated to process information, ProcIdKill(), which will kill a process based on its process id.

That already exists, kill(2), and is POSIX standardized.

I plan to expand this library to also allow for process execution, process group creation and management, getting the time stamp a process was spawned, causing the current process to wait for another process id or process group id to end, get the username a process id is running under, ...

All those exist, and I think most or all of them are POSIX standardized.

whether run as root/admin, a...

I don't remember whether POSIX has a coherent concept of root. In practice, that is actually meaningless question. What you really want is a capability-based mechanism, and ask the question "can I perform action X", not "am I root", because in some OSes the set of people who can perform certain operations that are traditionally associated with root can be smaller or larger.

and enumerating the tid's (thread id's associated with given process id, as well as getting all the tid's running on the current user session)

That exists, and is in POSIX.4.

I'd also like to include functions which are windowing related, ...

I know of no cross-OS standard that addresses GUIs.

 

[Samuel Venable]

Unless you have some mind-altering revelation on the state of GUIs that unify all the paradigms, just a quick look at WG21's "study group" infographic shows that they aren't even thinking about incorporating graphical anything into STL.

SG14 probably only covers game-specific engine accelerations. The meeting minutes from last month focuses on... pointers.
SG13 is explicitly low level.

I would call this "reading the room." Your stuff is focused on third party libraries and software like X, Wayland, Windows, etc. STL is lower level than that.

The part which has anything to do with windowing like I said can be omitted, this isn't all or nothing with that portion of my ideas. That's why I mentioned doing what libffi does underneath which call's the libraries with linking to them a build time and producing error codes if the library was not found, but if what you say is the case then it doesn't have to be included. The only windowing features I was thinking of were something around two small functions anyway, both somewhat related to processes, well, one more than the other.

I haven't 'read the room' because I couldn't find it on google, nor did I know such a thing existed. I actually saw the right website when I searched before making this topic but I failed to click the link out of the ones i did click. If it were a snake, it would've bitten me.

For one thing, I've seen a ton of people all across the web looking to do all kinds of things with such features, but most of those people are shell scripters and people working with some form of automation, not C++ developers. There are a ton of command line interfaces that do things like this stuff my library can do, and similar, but it's also nice to have a cross-platform solution for those people who like cross-platform stuff and especially when that cross-platform stuff runs faster than running a bunch of shell scripts and parsing output.

Now, oddly enough, my library appends to your executable a helper executable which extracts to a temp directory at runtime and the calling application reads output from that and parses it, that is largely due to the fact I am using private API's to do this on Windows which have no known functions which allow reading process information between a calling and target process of varying architectures (for example one is x86 and the other is x64) I don't want to get this locked so I'll try to stop myself there regarding Windows-talk. This is a limitation of the OS and thus I only have this problem on Windows.

 

[ralphbsz]

Another suggestion: To understand what OS interface standards do, go read a book about them. My favorite recommendation is Bill Gallmeister's POSIX.4 book. It's not only a really well written, and a great guide for learning how to do multi-threaded programming and locking (and async IO) in a standards-conforming way. Bill is also a really good guy, volunteers a lot, his kid was in band in high school, Bill ran the "band parents" organization. After reading that book, download the actual POSIX.4 standard, and read it (it is probably thousands of pages), at least to get a flavor for what standardization really means.

 

[Samuel Venable]

May I suggest something: Can you explain, in relatively brief form, what your new interfaces do, and how they address a need that is currently unmet? Think of it as an "elevator pitch". You need this for us to understand how to help finding the correct forum, and you'll need this (a thousand times) when you start working with standards bodies.


This is not a C++ language question. The language doesn't concern itself with the concept of process. It handles things like "what is a pointer" and "how do you do inheritance". It is not even (or even less?) an STL question. The STL is about questions like "what does it mean to put something into a vector, or iterate over a map".

It is an operating system interface question. From that viewpoint, the correct community would be POSIX, or perhaps Boost. Beware of Posix: It's mission is (or rather was) to standardize divergent Unix-like server/desktop OSes, in a nutshell fix the split between SysV and BSD. It isn't heavily into accepting new interfaces.


The standards committees don't implement. The standardize the interfaces that implementors should adhere to. On the other hand, you pretty much have a fully functional sample implementation available for standards bodies to consider even looking at it. And you need to carefully think through the copyright situation of the sample implementation.


Not to the C++ committee, and for POSIX only storage and file system people (some of which I know through SNIA and through T10).


They don't hide; at least in the case of the ones I have interfaces with, they are all easy to reach via mail aliases and mailing lists. The membership of the committee can be pretty easily found on the web (perhaps not an official list, but for example in people's LinkedIn profile). The trick is to find one member of the committee and ask them for advice. For storage, I would have said "send an e-mail to George Penokie", but he's long retired.

Suggestion: At the next Usenix, walk the hallway, and ask who is on the POSIX committees.


That already exists, kill(2), and is POSIX standardized.


All those exist, and I think most or all of them are POSIX standardized.


I don't remember whether POSIX has a coherent concept of root. In practice, that is actually meaningless question. What you really want is a capability-based mechanism, and ask the question "can I perform action X", not "am I root", because in some OSes the set of people who can perform certain operations that are traditionally associated with root can be smaller or larger.


That exists, and is in POSIX.4.


I know of no cross-OS standard that addresses GUIs.

As both you and the guy I previously replied to have said in common what seems to be a false statement, under the hood, according to C++17 std::filesystem docs. Platform specific API's. Yes. The docs say explicitly the C++17 std: filedystem is based Win32 and POSIX APi for the platforms that apply. I could remember wrong, but I do recall reading that several times now. (not lower-level than! How do you even get lower level than platform-specific and non-third-party, OS-level unless you really cared to waste time with assembly and invent functions which were already written?) The only functions I wrote which were not OS level were the Linux specific ones, but that doesn't mean one little platform can't be revised later.

 

[ralphbsz]

... not C++ developers.

You need to understand that while C (not C++) is the standardization language for OS interfaces, it is actually not a very important development language today. Much more code is written in JS, Java, Python, Go, Ruby, Rust, Swift, Objective-C and so on. If you are solely focused on C++ interfaces, your proposal will be mostly irrelevant.

... and especially when that cross-platform stuff runs faster than running a bunch of shell scripts and parsing output.

No serious programmer would run a shell script and parse output. They would read the source code for what the utilities in the script actually do (most of them eventually use system interfaces with C bindings), and then use those bindings. All you are proposing is to make those system interfaces universal across all OSes.

 

[ralphbsz]

As both you and the guy I previously replied to have said in common what seems to be a false statement, under the hood, according to C++17 std::filesystem docs. Platform specific API's.

You are correct, and I had completely forgotten that C++ had sucked the Boost interfaces for file systems into the C++ standard. Still, that's stuff which is about 30 years old (the underlying POSIX file system interfaces are from the early 90s), and which has been available in Boost for several years. So one way to get to the standards bodies would be, as msplsh already said, by getting Boost (or similar projects such as Abseil) to accept your proposals.

 

[Samuel Venable]

You need to understand that while C (not C++) is the standardization language for OS interfaces, it is actually not a very important development language today. Much more code is written in JS, Java, Python, Go, Ruby, Rust, Swift, Objective-C and so on. If you are solely focused on C++ interfaces, your proposal will be mostly irrelevant.


No serious programmer would run a shell script and parse output. They would read the source code for what the utilities in the script actually do (most of them eventually use system interfaces with C bindings), and then use those bindings. All you are proposing is to make those system interfaces universal across all OSes.

If they aren't parsing the output, then I have no idea why they are using shell scripts and not just looking at C++ function docs like I did if C++ is really what they were going for, looking at the source code of existing apps is less reliable than reading docs when proper docs are at least provided. which was my understanding to this point that they were reading output, but I could've misread that part of what was going on, I know I've seen a lot of shell scripting related posts online that have a lot to do with processes and the like.

However I will say why I started this topic to begin with is in another community I heard that a C++ standard library for process functionality was already being talked about, though you read a lot of crap on the internet, maybe I did that in this case lol

 

[Samuel Venable]

I took the advice of my first two comments on my to-list so there isn't much left to be talked about unless someone here wants to contribute to my project, although if you have anything to say besides that feel free to.

Edit: to be completely honest I misunderstood what the Standard Type Library even was to begin with, you learn something new every day I guess. I'm sure most people who develop in C++ would've learned that one in particular a lot sooner than I did, but ah well...

 

[ralphbsz]

The STL is the standard TEMPLATE library. It's all about containers. It's called the template library because in C++, to create container classes or functions that work with objects of arbitrary class, you take generic classes and functions, and specializes them for a class. The generic thing uses templates (the things in the <> brackets) for that.

The STL doesn't worry about things like OS interfaces. There is also a standard library (which most people know because of std::string), which has some OS interfaces. As you pointed out above, it even has file system interfaces today, courtesy of Boost.

Actually, in reality the STL is not the "standard template library". In reality, it is named ofter one of its inventors, Alex Stepanov. Alex has a GIGANTIC ego. Did you notice that I capitalized the GIGANTIC? Alex was working at HP labs, together with Meng Lee, on "generic programming", writing programs that could handle any data type. This was research, not practical stuff; their other day job was helping with the design of RAID controllers. Alex' department was called STL, or "Software Technology Laboratory". The generic software was pretty esoteric and irrelevant stuff ... until Andy Koenig (famous C++ guru) heard about it, and asked Alex and Meng to present it to the C++ committee. It turns out the C++ community was at the time searching for a way to have container classes (things like vectors, lists, arrays, maps), and make them type-safe, so they ended up welcoming Alex' proposal. Since the library couldn't very well be called "Alex' Library", but he had a giant ego, he backronymed "STL" to mean Standard Template Library, and at least got it named after his department.

I've never worked with Alex, and never exchanged any word with him. But I did work a few cubicles over from his old group (the STL at HP labs was in building 1 at 1501 Page Mill, as was I for a few years), and I've heard lots of stories about him.

 

[kpedersen]

"Oh but std::string isn't a template?"

Hehe... look closer. Keep looking deeper and deeper and one day you might reach the end. That is, unless the c++ standard can dig faster

template <class CharT, class Traits = std::char_traits<CharT> >
using basic_string = std::basic_string<CharT, Traits,
  std::polymorphic_allocator<CharT> >

 

[msplsh]

nice to have a cross-platform solution for those people who like cross-platform stuff and especially when that cross-platform stuff runs faster than running a bunch of shell scripts and parsing output.

Check QT, then. That's probably where this belongs.

 

[Samuel Venable]

Check QT, then. That's probably where this belongs.

Qt is a gui framework. Most of the features this would contain, if not all depending on the route I go, have nothing to do with that.

 

[msplsh]

I'd also like to include functions which are windowing related

Can't really figure out what you're talking about, then. Split it into Boost and QT?

 

[Samuel Venable]

Can't really figure out what you're talking about, then. Split it into Boost and QT?

The windowing stuff is also related to process info. For example: getting the owner pid of a window id. Or enumerating the window id's belonging to a process id. These features I was considering to omit due to the fact not many platforms outside of desktops even use the concept of actual windows.