Backends
'Backend' in the context of this spec refers to language/runtime support.
For some programming languages, it might be necessary to manually bootstrap a runtime.
Platforms
The following platform names are standardised.
Backend | Description | MVP | MVP Note |
---|---|---|---|
win |
Windows (.dll ) |
✅ | Support MSVC or Static Linked |
linux |
Linux (.so ) |
✅ | Support glibc or Static Linked |
macos |
macOS (.dylib ) |
❌ | Lacking necessary hardware. |
switch |
Horizon (.nro ) |
❌ | Lacking in expertise. But there's interest. |
dotnet |
.NET (.dll ) |
✅ | CoreCLR. Including support for platforms targeting R2R. |
It is preferred to use universally recognisable names over internal ones.
For example, prefer:
switch
overhorizon
dotnet
overcoreclr
Architectures
The following architectures are standardised.
Arch | Note |
---|---|
x86-any |
Assuming i686 as the baseline. |
x64-any |
Also known as x86-64-v1 |
arm64 |
Microarchitecture Levels
Microarchitecture levels for purposes of micro-optimisation are also supported.
This is present for high performance dependencies, where every nanosecond counts.
Generally, it is not expected that mod authors will manually leverage this functionality however,
that said; it is hoped we can make it easy to use during the publish process
if possible.
Type | Name | Description |
---|---|---|
string | x64-v2 | Path to DLL targeting x86-64-v2 |
string | x64-v3 | Path to DLL targeting x86-64-v3 |
string | x64-v4 | Path to DLL targeting x86-64-v4 |
string | x86-v2 | Path to DLL targeting x86-64-v2 (32-bit mode) |
string | x86-v3 | Path to DLL targeting x86-64-v3 (32-bit mode) |
string | x86-v4 | Path to DLL targeting x86-64-v4 (32-bit mode) |
Compilers based on LLVM (Clang, Rust etc.) can directly target these.
For example, if the backend specified is x64-v3
, it is assumed the CPU supports AVX2.
For more information, including how the x86
targets are derived, see Research: Microarchitecture Levels.
TOML Representation
Backends have arbitrary information, thus in all serialized data in configs are represented as dictionaries
Take for example Package Metadata, where the Targets
field
is a nested dictionary.
[Targets.win]
x64-any = "mod.dll"
The dictionary name is Targets
, with the first level
Platform key being win
, and the second level Architecture key
being x64-any
.
Runtime Library Assumptions
Assume each backend links to the common C runtime for the platform.
In other words:
win
really meanswin
+msvc
.linux
really meanslinux
+glibc
.dotnet
really meansdotnet-coreclr
.
Loader Behaviour
When the loader is about to load a mod, it looks up a dictionary specified in the Package Metadata, and starts the mod using the appropriate backend.
If the backend is not one supported by the loader, the loader will try to find an already loaded mod which may have registered the backend.
It's possible to ship a mod for multiple platforms by including multiple backends in a mod config and shipping separate binaries for multiple platforms.
Custom Backends
In some cases, some custom bootstrapping might be required.
For example:
- For a .NET game, it might be desirable to execute mods inside the game's own runtime.
- For a
Unity
game handler, you may want to swap betweenmono
anddotnet-latest
based on runtime version &Il2Cpp
status. - Backwards compatibility for legacy mods written for a previous mod loader.
Example Backend | Description |
---|---|
unity.unity-custom |
Runs mods in dotnet-latest for Il2Cpp; mono otherwise. |
sewer56.reloadedii-custom |
Runs in dotnet-latest , provides backwards compatibility for R2 mods. |
taleworlds.bannerlord-custom |
Loads using .NET Framework (older versions) or .NET Core (newer versions). |
To allow for maximum modularity; custom backends are implemented via regular mods; allowing them to be updated independently from the loader.
Information for Project Template Authors
For project templates it is recommended to target LLVM-based toolchains (Clang, Rust, etc.)
For the following reasons:
- They can directly target the microarchitecture levels mentioned above.
- More portable, for example, you can
cross compile
(e.g. build for Windows from Linux). - They can generate better code.