The source processor is a set of Python scripts. These scripts are executed when a plugin is build. The source processor checks the given code and creates utility code automatically. See Source Processor.
The behaviour of the source processor can also be defined in a project's projectdefinition.txt file. See Project Tool.
The stability and performance of the Standard Template Library varies with the specific implementation. Using the same code base on all platforms allows to guarantee stability and performance. Additionally the STL does rely on exceptions which are not supported by the MAXON API. Also, using custom classes instead of STL classes allows to deeply integrate these classes into the rest of the MAXON API (e.g. support I/O operations).
The error system of the MAXON API allows for more safe and more efficient error handling than exceptions. It has low overhead and makes it easy to handle errors at the location they occur. Also the error system is deeply integrated into the API's multi threading tools which allows for save handling of errors in a multi-threaded context.
For an overview over the error system see Error System.
Plugins of the "classic" API are based on specific plugin classes. E.g. object plugins are created by implementing a new class based on ObjectData. Such a new class must be registered with a specific function like RegisterObjectPlugin().
See General Plugin Information Manual.
Each element of the classic API must have a unique, Int32 based ID. This ID allows the unique identification of each plugin type. To avoid ID collisions one must get a new plugin ID from https://plugincafe.maxon.net.
Only ObjectData, ToolData and CommandData based plugins are listed in the "Plugins" menu. Other plugin types may be listed in special menus. E.g. VideoPostData plugins are listed in the render settings.
Plugins of the MAXON API are based on interfaces. A new plugin is created by implementing a specific implementation for a given interface. This implementation is then shared using a registry or a published object.
Implementations are identified using string based IDs. These IDs use reverse-domain notation and can be defined by the plugin developer.
Interfaces are virtual classes. They define the public contract of a component. An interface can be implemented one or many times. See MAXON API Interfaces.
A registry is used to store multiple implementations of a given interface. It can be used to access these implementations. See Registries.
A published object is a shared element. It can be implemented once and then accessed and re-used globally. See Published Objects.