What Thirty Years of Preserved Interfaces Cost, and Why Nothing Precompiled Means Nothing to Preserve
Software compiled for Windows in 1997 often still runs. That is an extraordinary engineering achievement, it is the single largest reason the platform won the enterprise, and it is also a permanent obligation that grows every year and can never be discharged. Those are not two facts about Windows. They are one fact, seen from two directions.
Paper 1 described the fixed commitment as a convention: the industry compiles in advance because it always has. Paper 2 found a platform that meters it. Windows is the substrate where somebody kept the promise. When a binary is compiled against an interface, that binary encodes the interface's exact shape, and from that moment the interface cannot change without breaking software the platform vendor did not write, cannot locate, and in many cases could not rebuild if they wanted to. Microsoft's answer, sustained for three decades, has been to never break it. That decision is why enterprises standardized on Windows, and it is also why the operating system now carries the accumulated weight of every prediction anybody ever compiled into it.
This paper argues that backward compatibility is not a separate topic from the rest of this series. It is what a fixed commitment looks like when the promise is honored rather than defaulted on. Linux, in Paper 1, defaults regularly and pushes the cost onto whoever has to rebuild; Windows services the debt in perpetuity and absorbs the cost into the platform, as shims, as compatibility modes, as subsystems that exist only to keep decades-old assumptions valid, and as a security surface that cannot be reduced because something shipped is still calling into it. The paper then makes the claim that follows structurally rather than rhetorically: a system that precompiles nothing against an interface creates no obligation to preserve one. The debt is not paid down. It is never incurred. Essence's position on Windows is beside Win32 rather than in place of it, an internal build exists and has not been released, and the Linux binary runs today under the Windows Subsystem for Linux.
A great deal of software compiled for Windows in the 1990s still runs on Windows today. Not in emulation, not in a container, not with a vendor's blessing: it runs because the platform decided, deliberately and at enormous cost, that it would keep running. No other general-purpose platform has attempted compatibility at that duration and that scale, and the ones that tried briefly gave it up.
This deserves to be said plainly before anything else in the paper, because the argument that follows is easy to mistake for a complaint and it is not one. Microsoft's compatibility commitment is the reason a hospital, a factory or a bank could adopt a computing platform and not be forced to rewrite its operations every few years. It converted software from something perishable into something durable. Enterprises did not standardize on Windows because of the interface or the price. They standardized on it because it was the only platform that promised their existing software would still work, and then kept the promise for thirty years.
The rest of this paper is about what keeping that promise costs, and about the fact that the cost is structural rather than a consequence of anything Microsoft did wrong. Given the same premise, anyone would owe the same debt.
The mechanism is worth stating precisely, because it is the same mechanism as Paper 1's, observed at a longer timescale.
When source code is compiled against an interface, the resulting binary does not contain a description of what the program wanted. It contains the specific arrangement the compiler chose given the interface as it existed that day: the symbol it will call, the order and width of the arguments, the exact layout of the structures passed across the boundary, the values it expects back, the conditions it treats as errors. All of that is frozen into the artifact at the moment of compilation, and none of it can be renegotiated afterward, because the artifact cannot be asked what it meant. It can only be run.
The consequence is that the obligation is created by the compilation, not by the design. A platform vendor who publishes an interface has made a proposal. A platform vendor whose interface has been compiled into ten million binaries has made a commitment, whether or not they intended one, and the commitment is enforced by the simple fact that changing the interface breaks software they did not write and cannot find. A decision made once, on a build server, in 1997, by an engineer who has long since left an employer who may no longer exist, is still binding on Microsoft in 2026.
Honoring the commitment is not a passive act. It requires machinery, and the machinery is itself part of the operating system.
Windows carries a compatibility infrastructure whose only purpose is to keep old assumptions valid: a database of per-application fixes that intercept and adjust behavior for specific programs known to depend on details that have since changed, compatibility modes that present an older platform's behavior to an application that asks for it, and an entire subsystem devoted to running software built for a previous processor width alongside software built for the current one. None of this makes the platform better at anything a new application wants to do. All of it exists to service predictions made years or decades ago.
And the balance compounds rather than amortizing. Each new release must remain compatible with everything that came before, including the compatibility machinery itself, which is now also something that shipped software depends on. Every year the platform is asked to move faster while carrying more. The security consequence follows from the same arithmetic: an interface with known weaknesses cannot simply be withdrawn while a shipped binary somewhere is still calling it, so the attack surface is bounded below by history rather than by current design.
Everything above is architecture. Here is where it shows up on somebody's budget.
Large organizations hold the deepest inventories of binaries whose source is missing, whose original vendor has been acquired or dissolved, and whose behavior is understood by nobody currently employed. These are rarely glamorous systems. They are the application that schedules the plant, prices the policy, or closes the books, and they work. The organization is not sentimental about an old operating system. It is bound to a compiled artifact it cannot rebuild, and the operating system is simply the last environment in which that artifact is known to run.
This is what stalls migrations, and it is worth naming precisely because it is usually described imprecisely, as inertia or as resistance to change. It is neither. It is the rational response to holding an asset whose interface requirements were frozen by a compiler decades ago and can no longer be discovered except by running it. The reason a decades-old application cannot be moved is not that it is old. It is that what it needs was never written down anywhere except inside the binary.
Nothing in this paper argues that Win32 should be displaced, and a system that tried would be proposing to break precisely what made the platform valuable. Essence's position on Windows is beside Win32, not underneath it and not in place of it. Existing applications keep running exactly as they do now, against interfaces the platform will keep honoring. Work that is expressed as declared intent takes the Essence path, resolving against the components present at execution and generating instructions for them.
The structural consequence is the one the section title implies. Work that takes the second path creates no new compatibility obligation, because nothing was compiled against an interface whose shape then has to be preserved. It does not repay the existing debt, and this paper is not claiming it does. It stops the balance from growing on everything new.
Two things, and the substrate strip at the top of this paper states both. There is an internal Essence build for Windows which has not been released, and there is a path onto Windows hardware available right now that does not require a native port at all: the Windows Subsystem for Linux runs a real Linux kernel, and the Linux binary described in Paper 1 runs there.
That second path deserves its caveats stated in the same breath as the claim. WSL2 is a virtualized Linux environment rather than native Win32 execution. Device access, and hardware acceleration in particular, reaches the guest through a paravirtualized path with different characteristics from bare metal, and any performance figure obtained under it would have to be measured under it rather than inherited from Paper 1's Linux results. It is a genuine way to run Essence on a Windows machine today, and it is not the same thing as a Windows deliverable.
No released Windows deliverable. The Windows build is internal and has not shipped, and no date is offered. The WSL2 path is real but is a Linux binary running in a virtualized Linux environment, not a native Windows product.
No performance claim on Windows. The acceleration and energy figures cited elsewhere in this series were measured on other substrates under stated conditions. Nothing has been measured under WSL2, whose virtualized device access would have to be characterized separately before any figure could be quoted.
Not an argument that Microsoft chose wrongly. Sections 01 and 04 are meant sincerely. The compatibility commitment created enormous value, and a platform that had broken it would have imposed a different and probably larger cost on the same organizations. This paper describes the structure of the obligation, not a mistake.
Essence does not discharge existing compatibility debt. Applications already compiled against Win32 interfaces still require those interfaces, and a second path for new work does nothing for artifacts already in the inventory. The claim in Section 05 is bounded to work that has not been compiled yet.
Platform mechanisms are publicly documented and evolve. The compatibility database, compatibility modes and the subsystem for running previous-width binaries are described here at a structural level. Specifics should be checked against current Microsoft documentation.
Three of the four operating-system papers are now in place, and the fixed commitment has taken a different form on each. Linux treats it as a convention and defaults on it periodically, pushing the rebuild cost outward. Apple treats it as a rule and enforces a quota. Windows treats it as a promise and pays the interest forever. Same commitment, three different relationships to it, and none of the three is unreasonable given what each platform is trying to be.
Paper 4 turns to the platform that took a fourth position and simply stopped making the commitment at one specific layer. Android ships bytecode rather than machine code and compiles on the device, guided by how the application is actually being used, on billions of devices. It is this series' argument already implemented, by somebody else, at a scale nothing here can match, and the interesting question is what it generates instructions for.
Windows kept a promise almost nobody else attempted, and enterprises built their operations on the strength of it. The cost of keeping it is an operating system carrying every assumption ever compiled into it, serviced by machinery that exists for no other purpose, with a security surface bounded below by history and an inventory of binaries that are the only remaining record of their own requirements. Essence does not repay that debt and this paper does not pretend otherwise. It declines to open the account: work resolved against the machine at execution freezes no interface and obliges no one to preserve one. An internal build exists, it has not shipped, and the Linux binary runs under WSL2 today.
The Common Substrate → Request Platform Access