Platform abstractions: shared logic and native backends

One interface, different implementations

A multi-platform malware repository can expose one operation name while selecting different implementations at build time. A function called platform_status might hide several backends. To explain that function, first distinguish its public contract from the implementation selected for the artifact you are studying.

This example models backend selection with harmless labels. It does not detect the host or call operating-system services. The selected target is an explicit string supplied by the example, making the selection easy to inspect and test.

A local backend model

backends = {
    "windows": lambda: "Windows demonstration backend",
    "linux": lambda: "Linux demonstration backend",
    "macos": lambda: "macOS demonstration backend",
}


def describe_backend(target):
    backend = backends.get(target)
    if backend is None:
        raise ValueError("unsupported target")
    return backend()


assert describe_backend("linux") == "Linux demonstration backend"
print(describe_backend("windows"))

The dictionary represents a selection boundary. It does not establish that the selected implementation fulfills an identical contract on every platform. In a real source study, inspect the backend body, its dependencies, and how errors are normalized before claiming equivalence.

Compare the right layers

On Linux, the system-call interface connects applications to kernel services. That is distinct from a project's wrapper function or its library dependencies. Windows exposes its own platform interfaces, while macOS also has platform-specific security and distribution concepts such as code signing.

These references identify different boundaries to investigate; they are not interchangeable mechanisms. A shared function name does not make a platform's handles, permissions, or return conventions portable. A library wrapper may also translate an error before project code sees it.

Build selection and runtime selection

Ask when a backend is selected. Conditional compilation may include only one implementation, whereas a local dispatch table can retain several. A repository can contain a backend that is not included in the inspected binary. Separately, a runtime branch can exist but never be reached in the observed execution.

This distinction prevents misleading statements such as “the program supports every platform listed in its directories.” Support is a claim about a built component and its behavior, not merely a count of source files. A stub backend returning a placeholder is especially easy to overinterpret.

Exercise

Add a call with the target other. Predict the result. Then imagine the macOS backend only returns an unsupported status: would the shared interface prove functional macOS support?

Check your understanding

The unknown target raises ValueError. A placeholder backend proves that a selection exists, not that the operation works. A complete study identifies the selected backend and checks its actual result and failure contract.