How plugins work

Plugins are optional native add-ons that extend Tuning Editor. They are discovered and loaded automatically at startup from the plugin folders; each one is checked against the application’s plugin ABI version and is only loaded if it is compatible. The app talks to each plugin through a safe wrapper, never the raw library, so a misbehaving add-on cannot destabilise the rest of the program.

Figure 1

Kinds of plugin

• Checksum / detection plugins — compute and repair the integrity checksums of a file and help recognise the ECU it belongs to. The bundled Generic Checksum plugin is one of these.
• UI / extension plugins — add extra views, overlays or commands to the interface, layering new functionality on top of the editors.

Seeing what is installed

Open Help › Installed Plugins for a read-only list of everything that loaded, grouped by kind. Each entry shows its Id, Name, Version, Vendor, ABI and Capabilities, with a Configure… button for plugins that have settings and a Rescan button to re-scan the folders after you add one. A Load failures section lists any plugin that could not load and the reason — the first place to look if an add-on does not appear.

Note — if a plugin is missing from the list, it usually means a version mismatch (built against a different ABI) or a missing dependency. The Load failures section names the reason.

Settings and where plugins live

Plugin libraries live in Tuning Editor’s plugin folder (a .dll on Windows). Each plugin keeps its own configuration in a per-user plugin-settings folder, so its options survive updates and can be backed up or moved between machines independently of the program itself.

Building your own

Tuning Editor exposes a small, stable C ABI, so you can write your own add-on in any language that can produce a native library. The two walkthroughs cover the documented plugin kinds end to end:

• Build a checksum plugin
• Build a UI plugin

See also

• Checksums & detection
• The Generic Checksum plugin
• Preferences