Operating Systems
Reinventing Operating Systems: Lessons from OpenBSD and Beyond
Enterprise operating systems preserve compatibility contracts; OpenBSD and Apple accept deliberate breaks when old interfaces obstruct security, simplicity, or architectural change.
Operating-system vendors choose which old contracts to preserve and which to retire. Windows invests heavily in application compatibility; OpenBSD expects coordinated upgrades of its base system; Apple couples deprecation with controlled hardware and software transitions. Those policies determine how much legacy behavior remains exposed and who pays the migration cost.
The Enterprise Paradigm and Its Legacy
Organizations invest in applications, training, deployment, and support processes that outlive one operating-system release. Breaking a binary interface can turn a security upgrade into a business outage. Microsoft therefore maintains compatibility behavior, application manifests, and migration tooling so older Windows applications continue to run while newer applications can request current behavior.
An Application Binary Interface (ABI)[1] is a contract, not mere historical clutter. Preserving it protects deployed software and reduces immediate migration risk. The cost appears when old parsers, protocols, privileges, or undocumented behavior must remain reachable after the architecture that justified them has changed.
The Consequences of Backward Compatibility
Old APIs[2] and ABIs do not increase attack surface merely by existing. They increase it when the system must keep additional code reachable, preserve unsafe semantics, or maintain multiple implementations of the same operation. A compatibility shim with a narrow, tested boundary can be cheaper and safer than forcing every application to reimplement a migration.
Windows illustrates both sides. Microsoft documents application manifests that preserve version-specific behavior and states that it goes to great lengths to maintain compatibility. The mechanism protects deployed applications, but every retained behavior becomes another contract that security and platform changes must respect. The correct question is not whether compatibility is bad; it is whether each retained path still justifies its maintenance and exposure.
A Renewed Approach: The Philosophy of OpenBSD and Apple
OpenBSD and Apple accept different forms of planned incompatibility. OpenBSD develops the kernel, libraries, utilities, daemons, and documentation as one base system and upgrades them together. Apple controls the platform transition, publishes deprecations, and can require developers to adopt a replacement on a defined schedule.
OpenBSD: Simplicity and Security Above All
OpenBSD does not promise that binaries from one release will define the architecture of later releases. Its six-month releases move the base system as a coherent unit, while the supported stable branches receive security and reliability fixes without new APIs. That policy lets developers remove obsolete code and change internal interfaces, but it requires users and package maintainers to follow complete, ordered upgrades.
Apple: Managed Platform Transitions
Apple combines deprecation notices, developer tooling, and firm cutoffs. macOS Catalina stopped running 32-bit applications after Mojave served as the final transition release. Apple also moved supported classes of third-party drivers from kernel extensions to DriverKit and system extensions in user space. These changes remove compatibility and kernel attack surface at the cost of breaking software that has not migrated.
Impact on Innovation and the Future of Computing
Compatibility and modernization assign cost to different parties. Preserving an interface makes the platform maintain it; removing the interface makes application owners migrate. Security improves only when a transition removes a reachable weakness or enables a concrete defense, not whenever a vendor declares an API obsolete.
Virtual machines, containers, compatibility processes, and long-term support releases can isolate legacy applications while the host moves forward. They do not erase the legacy risk: the compatibility environment still needs patching, restricted inputs, and an explicit retirement plan.
Conclusions
Compatibility should be an explicit, bounded contract. Preserve an old interface when its users and migration cost justify the code; retire it when continued exposure blocks a documented security or architectural improvement. Windows, OpenBSD, and Apple choose different boundaries, and each choice transfers measurable maintenance work and risk.