An executable is a file which can be executed by the operating system. The file can contain machine code or be a script which is automatically executed by a script host.

The Executable concept is used to refer to an executable. It is a filename which can include a path (either absolute or relative). If the filename doesn't include a path the executable is expected to be in the current working directory (relative to the Context which is another concept explained below).

There is no class in Boost.Process to implement the Executable concept. As the executable is a filename only it is simply stored in a std::string. It might be possible to generalize the library further to make it possible for library users to use other string classes. Currently it is the safest bet to use a std::string though.

Arguments are the parameters passed to an executable when invoked. In C++ they can be accessed via a char*[] parameter of main which is often called argv.

This concept is not represented by a class either. The library user is expected to use a collection whose items are strings, eg. std::vector<std::string>. While the library user is free to choose any collection from the STL the items' type must be std::string. The library is not as much generalized yet as if it is likely to work with other string types.

A context defines additional data next to the executable and arguments a child process should be spawned with. This includes for example the work directory and environment variables. There are also platform-specific features supported. On POSIX systems security credentials can be set for example.

A generic context is implemented as context. There are two platform-specific context classes posix_context and win32_context to provide access to platform-specific features.

A process is the execution context of a program, represented internally by the operating system through multiple objects in its internal tables. Any reference to a process always mentions a running application in the system; it has to be clear that it cannot refer to an on-disk program that has not yet started execution.

Processes are internally organized by the operating system as a tree. Each process (except for the one at the tree's root) has a parent and can have multiple children. A parent process owns its children and therefore has full control over their execution.

There are two possible states for a child process:

While there is a process class library users typically deal with objects of type child (a class derived from process). If platform-specific features should be used child objects of type posix_child and win32_child can be created.

The class self (which is also derived from process) can be used to access the current process.

Upon termination, a process reports information to its parent describing why it finalized. This information is known as the exit status and includes the reason behind termination (regular exit, crash, external signal, etc.) together with details describing it.

Exit status can only be gathered from zombie processes; that is, child processes that stopped execution and are waiting for its parent to collect it. When the information is collected, the zombie process ceases to exist from the system tables, invalidating the Process object that represented it.

The Status concept is used to represent a process' exit status.

This concept is implemented by the status class. On POSIX systems additional features are available via the posix_status class.

A handle is an operating system entity that identifies one of its objects, such as a file or a process. Handles are used by user space programs to tell the operating system the object they are referring to.

Given the low-level interactions of Boost.Process with the operating system, the library lets the user access these handles, should he need them to call operating system services directly.

It is important to note that handles are object-specific. An operating system may use different data types to identify each of its objects. For example, POSIX systems refer to files through an int value while processes are referred to by pid_t values. Contrarywise, Windows uses a single HANDLE type to describe any object. Therefore, Boost.Process abstracts these handles in each class where it makes sense using types named handle_type.