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
| proton-wine-andrevto | proot-distro | |
|---|---|---|
| What it fakes | the Win32 API | chroot, mount --bind, binfmt_misc |
| How | reimplementation (Wine, patched by Valve) | ptrace syscall interception and path rewriting |
| What it needs from the OS | nothing privileged | nothing privileged |
| What it cannot do | anything Wine has not implemented | anything needing real root, kernel modules, or namespaces |
| Evidence of its limits | a one-line “use at your own risk” | a documented limitations section, item by item |
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.
Related
proot-distro · proton-wine-andrevto · foss-application · termux · self-hosting · synthesis