Compatibility layer

Software that makes a program run where its author never targeted it, by reimplementing or intercepting the interface the program expects — instead of asking the platform owner for permission. The corpus holds two, at opposite ends of the stack: proton-wine-andrevto (Windows binaries on Android via Wine/Proton) and proot-distro (Linux userlands on Android via proot).

This is a third register alongside the two the spoke opened with. The founding six split into the environment you compute in and the service you host instead of renting (synthesis). A compatibility layer is neither: it is not an alternative to a proprietary product and it replaces no vendor's service. It takes software that already exists and moves it somewhere it was not allowed to go — which is why openalternative's substitution taxonomy has no slot for either of these two, as proton-wine-andrevto already noted.

The two mechanisms

The common property is the one that matters to this spoke: both obtain control in user space. No root, no unlocked bootloader, no vendor cooperation. On a platform the operator does not administer, emulation is the form control takes.

What it costs, and who says so

Both sources charge for the trick, and the corpus should read the difference in how they report it. proton-wine-andrevto warns generically that games may crash, with no compatibility list and no test results. proot-distro enumerates: ptrace overhead on every syscall, no systemd, no cgroups or namespaces, no nesting, no FUSE, no real root, no BuildKit features when building images.

That makes the second the corpus's best-documented failure surface, in a spoke whose standing caveat is that privacy and autonomy claims here are self-reported and unaudited. A project that publishes what does not work is not thereby verified — nobody has checked these limits independently either — but it is the only source here that makes the checking easy.

The dependency it leaves behind

Neither layer is free of the world it escapes. proot-distro defaults its containers' DNS to Google and pulls images from Docker Hub; proton-wine-andrevto tracks a Valve branch and targets two third-party launchers. The spoke's founding finding — relocation sold as removal — holds here too, with one refinement: in a compatibility layer the relocation is structural rather than rhetorical. You cannot run Windows software without an implementation of Windows, and someone has to maintain it.

A third case, about content rather than programs (2026-08-29)

calibre is not a compatibility layer by the definition at the top of this page — it runs no foreign program. But its history is the same shape and it predates both entries here by a decade. The project began in 2006 as reverse-engineered USB protocol work to make a SONY PRS-500 talk to Linux, which the vendor had not supported; the format converter that followed exists so a book opens on a device its publisher never targeted. Same move, one layer over: the interface being reimplemented is a device protocol and a file format instead of an API.

Worth holding as an adjacency rather than folding in. If a second content-portability source arrives, the register may need widening from "makes a program run" to "makes an artifact work where its owner did not intend" — but one case does not justify redefining a category built on two.

A fourth case, by the opposite mechanism (2026-09-27)

quickemu reaches the same destination as the two entries above — an OS running somewhere its vendor never built it for — without reimplementing or intercepting anything. It wraps QEMU/KVM: the guest's own unmodified kernel boots under hardware virtualization, so there is no Win32 call to be missing and no syscall to rewrite. The cost moves instead to running two whole operating systems on one machine. Not a compatibility layer by this page's definition, but the same question underneath — who gets to say what runs on this hardware — answered a third way: instead of faking the interface (Wine) or the container (proot), give the guest the real thing and skip asking.

It sharpens that question rather than dodging it: Quickemu tags itself hackintosh and supports macOS as a guest, which Apple's own licence restricts to Apple-branded hardware. omniwm pays Apple's toll for the equivalent privilege — signed, notarized builds so Gatekeeper allows them. Quickemu does not pay it or ask; it treats the licence as the host operator's problem, not the project's. Held as an adjacency for now, alongside the calibre case above.

Related

proot-distro · proton-wine-andrevto · calibre · quickemu · foss-application · termux · self-hosting · synthesis