Modkit

The framework for building, installing, and running mods that coexist rather than contend for the same patches. It sits on the Lyra runtime primitives and turns them into a declarative format an author can target without touching kernel memory directly.

The model

A mod declares what it needs and what it provides. An on-device runtime reads each mod's manifest at boot and applies its capabilities, resolving dependencies and activating shared subsystems only when something asks for them. Capabilities split into declarative ones, safe to express in a manifest, and privileged ones that run code. This section documents that model and the "platform or mod?" boundary that decides where a given feature belongs.

Authoring

The techniques a mod uses to extend the device, each validated on-device:

• Registering new XUI classes and injecting scenes into screens the mod does not author.
• Adding menu entries, status icons, and context menus built from the device's own UI engine.
• Sharing navigation and components so several mods compose into one interface.
• Delivering cross-process state events into the shell's message loop.
• Synthetic input, runtime element injection, and the kill-and-relaunch iteration cycle.

Shipped mods

The mods that ship with the platform, documented as concrete examples: the iPod-impersonation USB mode, Chromecast audio casting, the YouTube client, and the smaller shell mods. Each page covers what the mod does and the device mechanism it relies on, linking back to the relevant Zune reference.