The Operating System Is Losing Its Grip on the Application Tony Malott · Published 2026-09-01 https://shareplane.malott.ai/artifacts/windows-without-windows/ SharePlane Thesis · Systems Architecture The Operating System Is Losing Its Grip on the Application Why Wine, Proton, and modern compatibility architecture matter far beyond Linux gaming. By Tony Malott · August 30, 2026 · Evidence reviewed August 31, 2026 The Windows application is becoming separable from the Windows operating system. Application binary Execution contract Compatibility or runtime layer Host operating system and hardware In this thesis Page map · normal document flow · never floats over the figures 01 · The claim 02 · What changed 03 · Performance 04 · Gaming 05 · Enterprise reality 06 · Execution contract 07 · ARM and portability 08 · Enterprise gates 09 · Action plan 10 · Consequence Sources Preview copy. This is Semantic Candidate v02, not the final SharePlane semantic lock. Why Wine, Proton, and modern compatibility architecture matter far beyond Linux gaming. I started with a claim I expected to knock down: Linux now runs Windows applications so well that it can sometimes run them better than Windows. The first half of the viral version is hype. The second half is no longer ridiculous. The clickbait version says Windows applications now run "natively" on Linux. They do not. Wine's own description is more precise: it is a compatibility layer that translates Windows API calls into POSIX calls rather than booting or emulating a Windows operating system. Valve says the same thing more practically about Proton: it uses Wine to let Windows-exclusive games run on Linux. That correction does not make the story smaller. It makes it more interesting. The compatibility layer has matured to the point where the presence of translation is no longer enough to predict the performance result. Sometimes Windows wins. Sometimes the difference is small. On some hardware and workloads, Linux wins while running the Windows version of the software. The old architectural assumption was simple: Windows executable means Windows endpoint. That assumption is becoming false often enough to matter. Wrong in exactly the interesting way 01 · The claim There are three ideas that should not be collapsed. What is not happening Linux is not secretly booting Windows underneath the application. Wine is not a traditional full-system virtual machine. A Windows executable does not become a native Linux binary because it launches successfully. Compatibility does not imply vendor support. What is happening Much of the application's x86-64 code executes directly on the processor. Windows API behavior is implemented or translated by Wine and related components. Direct3D calls can be translated to Vulkan through DXVK or vkd3d-proton. The Linux kernel, Linux drivers and host services provide the actual platform underneath. That distinction matters because "translation" sounds expensive only if we imagine every instruction being interpreted one at a time. That is not the architecture. Wine sits primarily at the operating-system and API boundary. DXVK and vkd3d-proton sit at graphics boundaries. The application's ordinary machine code still does ordinary machine-code things. Something changed underneath us 02 · What changed This did not happen in one release. It is the cumulative result of years of work across Wine, Valve, the Linux kernel, Vulkan, Mesa, GPU vendors and the projects translating Microsoft's graphics APIs. 11.0 — Current stable Wine release, shipped 13 January 2026. ~6,300 — Individual changes WineHQ reports in Wine 11.0, plus more than 600 bug fixes. 11.16 — Current Wine development release as of this evidence review, shipped 21 August 2026. Wine 11.0 calls out two changes in particular: support for the Linux NTSync mechanism and completion of the newer WoW64 architecture. NTSync matters because Windows software relies heavily on NT-style synchronization behavior. Moving closer to those semantics in the Linux kernel reduces some of the cost of approximating them elsewhere. The new WoW64 work matters because 32-bit and even 16-bit Windows compatibility can now live inside the modern 64-bit architecture with fewer historical contortions. The development train has continued. Wine 11.16 added Mono 11.3 with ARM64 support, VA-API hardware video decoding and more ARM64EC exception-handling work. Wine's vkd3d 2.1 followed on 24 August. Proton Experimental was updated again on 28 August and already included all Proton 11.0-2 changes plus newer component work. This is the first important conclusion: the old mental model of Wine as a fragile Win32 impersonator from another era is badly stale. That does not make every application compatible. It means the baseline technology deserves to be measured again. 01 · Architectural consequence · Source-locked figure The application is becoming separable from the operating system. The old model collapsed the application, operating-system contract, and endpoint into one choice. The emerging model makes the contract inspectable. 01 Application binary Packaging and historical origin. 02 Execution contract APIs, runtimes, identity, licensing, services, drivers, and support. 03 Runtime mediation Wine, Proton, DXVK, vkd3d-proton, FEX, or another bounded layer. 04 Host substrate Operating system, drivers, kernel, instruction set, and hardware. Source-locked replacement for accepted visual-source PNG 01. No native-execution or universal-compatibility claim. Open full canvas The part that sounds impossible 03 · Performance The idea that a compatibility layer can outperform the original platform feels wrong because we instinctively add the translation cost to the Windows result. That arithmetic is incomplete. We are comparing two different execution paths, not Windows plus a tax. On Windows, a game may move through Direct3D, the Windows graphics stack and a vendor driver. On Linux under Proton, the same Windows game may move through Wine, DXVK or vkd3d-proton, Vulkan, Mesa or another Linux driver stack, and the Linux kernel. Translation has a cost. So do drivers, scheduling, synchronization, shader compilation, memory management and operating-system services. If the alternate path saves more than the translation layer costs, the alternate path wins. There is no law of computer science requiring the original API path to be the fastest implementation of the workload. There is real evidence, but it is workload-specific Phoronix tested the same AMD Ryzen AI Max+ PRO 395 laptop under Windows 11 and Ubuntu 25.04. Batman: Arkham Knight was faster on Ubuntu even though the Linux run used Steam Play / Proton for the Windows game. Counter-Strike 2 was also faster on Ubuntu. The same test series immediately provides the counterexample: HITMAN 3 favored Windows, while Quake II RTX was mixed across settings, with Windows often ahead and Ubuntu winning some configurations. That is exactly the result I trust. A universal win would smell like marketing. A mixed result tells us the compatibility layer has become efficient enough that the rest of the stack can decide the outcome. The significant change is not that Linux is always faster. It is that the compatibility layer is no longer automatically the bottleneck. 02 · Translation and performance · Source-locked figure Translation cost is one term in two different execution paths. The relevant comparison is not Windows plus a fixed tax. Drivers, scheduling, synchronization, shader compilation, memory management, and host services can change the result. Windows path Direct3D → Windows graphics stack → vendor driver → hardware Often the supported and fastest path. Not automatically the winner for every workload. Linux compatibility path Wine or Proton → DXVK or vkd3d-proton → Vulkan → Linux driver → hardware Translation has a cost. The surrounding stack can save more than that cost on some workloads. Observed boundary: Batman: Arkham Knight and Counter-Strike 2 favored Ubuntu in one Strix Halo test; HITMAN favored Windows; Quake II RTX varied by setting. One configuration is not a universal result. The unsupported generated FPS table from visual-source PNG 02 is deliberately omitted. Open full canvas Gaming proved the architecture first 04 · Gaming as the proving ground Gaming is where this shift became difficult to ignore because Valve had both the economic incentive and the distribution surface to attack compatibility at scale. Proton is not a Linux porting campaign. It lets a large body of Windows software run without waiting for every publisher to build and support a native Linux version. Steam's July 2026 hardware survey puts Linux at 4.01 percent of surveyed systems. Windows remains dominant at 93.67 percent. Nobody serious should read four percent as a desktop overthrow. The more useful signal is that Linux gaming is now large enough for the compatibility ecosystem to have users, regressions, hardware pressure and sustained investment at production scale. Anti-cheat is also more nuanced than the old claim that it simply cannot work. Valve's Steamworks documentation states that Proton supports Easy Anti-Cheat and BattlEye, but support requires title-specific enablement or configuration. That turns at least part of the barrier from a fundamental compatibility problem into an integration and publisher-support decision. Boundary: gaming success is evidence that the architecture can work at scale. It is not evidence that enterprise productivity, engineering, security or device-management applications are equally portable. Modern enterprise software exposes the real boundary 05 · Enterprise reality This is where the Linux victory lap stops. Microsoft's current Microsoft 365 desktop requirements list Windows and macOS for computers, not desktop Linux. Adobe's Creative Cloud desktop requirements cover Windows and macOS. Autodesk is even more explicit: AutoCAD is not supported on Linux or under Wine and other Windows compatibility layers. The interesting pattern is not the vendor names. It is the dependency depth. Modern enterprise software exposes the real boundary Application class Typical dependency depth Linux + compatibility posture Architectural interpretation Legacy Win32 utilities Win32 APIs, files, registry, simple UI Often excellent Small execution contract. Good pilot territory. Standalone .NET / business apps .NET, Win32, WebView, COM, local services Application-specific Version and integration details decide the result. Games / GPU applications D3D, input, audio, anti-cheat, DRM Mature but variable Graphics translation is now a first-class architecture. Microsoft 365 desktop Identity, licensing, WebView, cloud integration, update stack Poor strategic target Launching an EXE is not the hard part anymore. Adobe / AutoCAD class Complex services, licensing, GPU features, vendor support Unsupported / risky Vendor support and deep platform integration dominate. EDR, VPN, kernel drivers, device middleware Kernel mode, filters, low-level hooks, proprietary hardware Assume Windows-bound unless native support exists The OS contract is the product. Modern desktop applications increasingly behave like distributed systems wearing desktop icons. Authentication brokers, web runtimes, licensing services, kernel hooks, shell integration, cloud services and update mechanisms can matter more than the main executable. Humanity has managed to make "double-click the program" depend on a small federation of identity systems, because apparently we were bored. 03 · Windows dependency spectrum · Source-locked figure Compatibility follows dependency depth, not the filename extension. A launchable executable, a supportable configuration, and a validated enterprise deployment are separate states. Lower dependency Legacy Win32 utilities Files, registry, simple UI, ordinary processes. Good pilot territory when versions and support permit. Application-specific Business apps and games .NET, COM, WebView, graphics, DRM, anti-cheat, and local services decide the outcome. Deep platform coupling Identity, licensing, kernel, and device systems Microsoft 365 desktop, Adobe, AutoCAD, EDR, VPNs, drivers, and middleware remain poor assumption-free targets. The unbounded ProtonDB percentage from visual-source PNG 03 is deliberately omitted. Open full canvas Stop asking whether it is a Windows application 06 · The thesis That question has become too coarse to be useful. A Windows executable is a packaging and historical fact. It does not tell us how much Windows the application actually requires. The better question is: What execution contract does this application require? That contract can be decomposed. Some parts are easy to satisfy elsewhere. Others are still hard walls. API surface — Win32, User32, GDI, filesystem, registry, processes, threads, IPC. Component model — COM, DCOM, OLE, local and remote objects, marshaling. Runtime — .NET Framework, .NET, CLR behavior, C/C++ runtimes, Java or bundled frameworks. Graphics — Direct3D 8 through 12, DXGI, shaders, video acceleration, GPU vendor assumptions. Web / UI — WebView2, HTML/JS rendering, embedded browsers and UI frameworks. Identity — Entra ID, Kerberos, NTLM, MFA, SSO brokers and device identity. Licensing — Activation services, DRM, cryptographic providers and vendor entitlement systems. System services — RPC, task scheduling, WMI, background agents, shell and notification integration. Kernel / device — Kernel drivers, minifilters, VPNs, EDR, USB middleware, printers and specialized hardware. Once those dependencies are explicit, "Windows-requiredness" becomes measurable rather than assumed. A compatibility layer can satisfy some of the contract. A native Linux component can replace another part. A cloud or VDI service may isolate the few remaining hard dependencies. Some applications will still require Windows. The point is that we have stopped giving the answer before doing the decomposition. 05 · Execution-contract decision model · Source-locked figure Ask what the application requires. Windows-requiredness becomes measurable when the contract is decomposed instead of inherited. Application behavior API and component model Win32, User32, GDI, filesystem, registry, COM, DCOM, OLE, processes, threads, and IPC. Runtime behavior Framework and interface .NET, CLR behavior, C and C++ runtimes, WebView2, embedded browsers, UI frameworks, and update mechanisms. Graphics behavior Direct3D and media D3D 8 through 12, DXGI, shaders, video acceleration, GPU features, and driver assumptions. Institutional behavior Identity and licensing Entra ID, Kerberos, NTLM, MFA, brokers, activation, DRM, cryptography, and entitlement. System behavior Services and devices RPC, WMI, schedulers, background agents, shell hooks, VPNs, EDR, filters, USB, printers, and specialized hardware. Decision Choose the cheapest valid execution substrate. Compatibility runtime, native host, Windows endpoint, VDI, cloud service, ARM system, or a mixed model follows the verified contract and support boundary. Source-locked replacement for visual-source PNG 05. Open full canvas ARM makes this much bigger 07 · Beyond the OS If this story stopped at "old Windows applications can run on x86 Linux," it would still be useful. It does not stop there. Wine's 2026 development work includes ARM64 and ARM64EC improvements. Proton's current build system contains explicit ARM64 work and FEX integration for relevant ARM paths. vkd3d-proton is built around translating Direct3D 12 to Vulkan, while DXVK does the same broad job for older Direct3D generations. I would not turn that into the claim that arbitrary Windows applications are now portable across every ARM Linux device. That would be another round of clickbait, just with more acronyms. The architectural direction is what matters: the operating-system ABI and, increasingly, the instruction-set assumption can both become mediated layers. Old coupling Windows app → Windows APIs → Windows OS → x86 hardware Emerging abstraction Application → execution contract → runtime / translation → host OS → available ISA That opens a design space around ARM laptops, handhelds, edge devices, specialized appliances, cloud workspaces and application-preservation environments. Not because one compatibility layer solves all of them, but because software can be classified by the contracts it needs instead of the machine it happened to be born on. 04 · Beyond x86 · Source-locked figure Both the operating-system ABI and instruction set can become mediated layers. Wine's ARM64 and ARM64EC work, Proton's ARM and FEX paths, and Vulkan translation establish direction, not broad current portability. Old coupling Application identity implied platform identity. Windows app → Windows APIs → Windows OS → x86 hardware Emerging abstraction Verified dependencies select the runtime and host. Application → execution contract → runtime or translation → host OS → available ISA Boundary: this opens architecture options around ARM laptops, handhelds, edge systems, cloud workspaces, and preservation environments. It does not make arbitrary Windows applications portable across ARM Linux devices. Source-locked replacement for visual-source PNG 04. Open full canvas Technical execution is only one gate 08 · Enterprise architecture This distinction matters even more in regulated and tightly controlled environments. An application that launches successfully is not automatically supportable. An application that is supportable is not automatically qualified. A qualified configuration is not automatically validated for a regulated use. Those states should remain separate because the operational consequences are different. Technical question Does it install? Does it authenticate? Does it render and perform correctly? Do updates preserve behavior? Enterprise question Is the configuration vendor-supported? Can security and support teams own it? Can the runtime be version-pinned and regression-tested? Can the organization defend the validated state? This is why I would not propose "replace Windows with Linux and Wine" as an enterprise strategy. I would propose something more disciplined: classify the portfolio by execution-contract density, test the low-dependency candidates, and keep the Windows-required set explicit rather than inherited. Treat compatibility like architecture, not a hobby 09 · What to do now A useful enterprise evaluation does not begin by installing a favorite Linux distribution. It begins with the application portfolio. Inventory the portfolio — Identify applications, versions, user populations, criticality and support requirements. Decompose execution contracts — Map APIs, runtimes, identity, licensing, services, drivers and hardware dependencies. Score dependency density — Separate easy compatibility candidates from applications whose product value depends on Windows integration. Pin the runtime — Treat Wine, Proton, CrossOver or another compatibility environment as a versioned application dependency, not a magical global setting. Test same hardware, same workload — Measure startup, CPU, memory, graphics, authentication, I/O, peripherals, sleep/resume, updates and failure recovery. Keep supportability separate — Record vendor support, security-tool coverage, patch ownership, validation burden and operational risk. Choose the cheapest valid execution substrate — Linux, Windows, VDI, cloud, ARM, compatibility runtime or a mixed model should follow the contract. Reassess periodically — The compatibility boundary is moving. A portfolio decision from five years ago is evidence of what was true five years ago. The operating system becomes a substrate 10 · The architectural consequence For decades, enterprise application portfolios helped determine which operating systems enterprises had to run. That relationship made sense because application behavior and operating-system behavior were tightly coupled. Compatibility architecture is weakening that coupling. Not everywhere, and not evenly. But enough that operating-system choice can increasingly be made after we understand the execution contract rather than before. For decades, application portfolios dictated which operating systems enterprises had to run. That relationship is beginning to invert. The operating system is becoming an execution substrate, while compatibility layers absorb more of the historical assumptions embedded inside the application. The next architectural question is not "What operating system does this application require?" It is "What execution contract must be satisfied, and where is the best place to satisfy it?" The operating system is becoming an execution substrate. Compatibility layers are absorbing more of the historical assumptions embedded inside applications. Stop asking whether it is a Windows application. Ask what execution contract the application actually requires. Exact source authority Accepted offline source, preserved with receipts. The 9,584,680-byte ZIP is byte-identical to the owner-accepted source carrier. Its five generated PNGs remain native visual-source provenance, not Production evidence. The figures above are source-locked responsive replacements. SHA-256: c28ac9a8db9c49b8db7045f3d9d93b618440f02224693aab9402433b73752a5f Download exact source ZIP Inspect evidence authority Sources and what they actually establish Evidence class for this Work is being treated as E4 because it contains current product and platform claims. Current claims were rechecked on 30 August 2026. The SharePlane thesis itself is original synthesis; no source below is presented as having made the full architectural argument. WineHQ: About Wine Establishes Wine's self-described architecture as a compatibility layer translating Windows API calls rather than a full Windows VM/emulator. Does not establish compatibility or performance for any specific application. Primary project source · reviewed 30 Aug 2026 WineHQ: Wine 11.0 Released Establishes Wine 11.0 stable release, approximately 6,300 changes, 600+ bug fixes, NTSync support and completed new WoW64 architecture. Primary project source · 13 Jan 2026 · reviewed 30 Aug 2026 WineHQ: Wine 11.16 Released Establishes current development-release features cited here: Mono 11.3 with ARM64 support, VA-API hardware video decoding and ARM64EC exception-handling improvements. Primary project source · 21 Aug 2026 · reviewed 30 Aug 2026 ValveSoftware/Proton and Proton changelog Establish Proton's use of Wine for Windows-exclusive games on Linux and current Proton 11 / Experimental development state. Does not establish universal game compatibility. Primary project source · current changelog edited 28 Aug 2026 · reviewed 30 Aug 2026 DXVK 3.1 Establishes the current 3.1 release and DXVK's Vulkan-based translation of Direct3D 8/9/10/11. It does not establish universal application compatibility or a performance advantage. Primary project source · reviewed 30 Aug 2026 vkd3d-proton 3.0.1 Establishes the current 3.0.1 release and the project's Direct3D 12-on-Vulkan role for Proton. It does not establish universal Direct3D 12 compatibility. Primary project source · reviewed 30 Aug 2026 Phoronix: AMD Strix Halo Windows vs. Linux, page 2 and page 3 Independent same-hardware benchmark evidence that some tested games and graphics workloads favored Ubuntu while others favored Windows. This is one hardware/software test configuration, not proof of a universal Linux advantage. Independent benchmark source · 16 May 2025 · reviewed 30 Aug 2026 Steam Hardware & Software Survey Establishes July 2026 surveyed OS share: Windows 93.67%, macOS 2.32%, Linux 4.01%. Survey participation is optional and anonymous, so this is Steam's user sample rather than desktop-market share. First-party platform telemetry · July 2026 · reviewed 30 Aug 2026 Valve Steamworks: Steam Hardware and Proton Establishes Proton support paths for Easy Anti-Cheat and BattlEye and the title-specific enablement/configuration requirements. Primary platform documentation · reviewed 30 Aug 2026 Microsoft 365 system requirements Establishes Microsoft's supported desktop OS requirements for Microsoft 365 home use. Linux is not listed as a supported computer desktop OS. Primary vendor documentation · reviewed 30 Aug 2026 Adobe: Creative Cloud desktop technical requirements Establishes supported Creative Cloud desktop requirements for Windows and macOS; Linux is not listed. Primary vendor documentation · reviewed 30 Aug 2026 Autodesk: AutoCAD and verticals on Linux Explicitly establishes that AutoCAD is not supported on Linux or under Wine/other Windows compatibility layers. Primary vendor support statement · 28 Jan 2026 · reviewed 30 Aug 2026 Proton 11 build system Provides direct source evidence for ARM64/FEX-related build paths. It supports the direction-of-travel argument, not a claim of broad ARM application compatibility. Primary source code · Proton 11 branch · reviewed 30 Aug 2026 Linux kernel NTSync documentation Establishes the kernel driver's support for NT synchronization primitives used by user-space NT emulators. It does not establish an application-specific performance result. Primary kernel documentation · reviewed 30 Aug 2026 Wine vkd3d 2.1 release Establishes the 24 August 2026 release of Wine's vkd3d 2.1 library. Wine vkd3d and vkd3d-proton are related but independently versioned projects. Primary project announcement · 24 Aug 2026 · reviewed 30 Aug 2026 FEX-2608 Establishes the current FEX release for x86/x86-64 user-mode emulation on ARM64 Linux. It does not establish broad Windows-application portability on ARM. Primary project source · 5 Aug 2026 · reviewed 30 Aug 2026 Evidence behind the thesis Check the work, not just the conclusion. Public research, authority, lineage, and author testimony are labeled separately. Sources can corroborate, challenge, or bound the argument; they do not replace Tony Malott's judgment. Portable public record Take the complete artifact with you. The deterministic package contains a self-contained offline article, the exact public-route snapshot, canonical public metadata, receipt, source text when available, plain-text context, claim ledger, source records, and a member-hash manifest. Download full artifact package Read plain-text context Inspect package manifest 17 public sources Sources, authority, and lineage Each record states the role it plays. Research support and governance provenance are not treated as interchangeable. Primary Project Documentation WineHQ: About Wine Compatibility-layer architecture boundary. Establishes Wine's self-described architecture without proving application-specific compatibility or performance. Open source Primary Project Release Wine 11.0 Released Stable release, change count, NTSync, and WoW64 evidence. Does not establish universal compatibility or performance. Open source Primary Project Release Wine 11.16 Released Current development-release ARM64, ARM64EC, Mono, and VA-API evidence. Does not establish stable-release posture or broad ARM portability. Open source Primary Kernel Documentation Linux kernel NTSync documentation Kernel synchronization architecture evidence. Does not establish an application-specific performance result. Open source Primary Project Current Changelog Proton changelog Current Proton 11 and Experimental posture. Does not establish universal game compatibility. Open source Primary Project Release DXVK 3.1 Current Direct3D 8 through 11 translation-layer evidence. Does not establish a universal performance advantage. Open source Primary Project Release Wine vkd3d 2.1 Wine vkd3d release identity. Distinct from vkd3d-proton and not universal compatibility evidence. Open source Primary Project Release vkd3d-proton 3.0.1 Current Direct3D 12-on-Vulkan project identity. Does not establish universal Direct3D 12 compatibility. Open source Independent Same Hardware Benchmark AMD Strix Halo Windows 11 vs. Ubuntu Linux benchmarks Mixed same-hardware workload evidence. One configuration; not a universal Linux performance claim. Open source First Party Optional Anonymous Sample Steam Hardware & Software Survey July 2026 Steam OS sample. Steam's optional anonymous user sample, not desktop-market share. Open source Primary Platform Documentation Valve Steam Hardware and Proton Easy Anti-Cheat and BattlEye support boundaries. Requires title-specific enablement and does not cover every anti-cheat architecture. Open source Primary Vendor Support Documentation Microsoft 365 desktop system requirements Supported desktop operating-system boundary. Linux is not listed as a supported computer desktop OS. Open source Primary Vendor Support Documentation Adobe Creative Cloud desktop technical requirements Supported desktop operating-system boundary. Requirements cover Windows and macOS, not Linux. Open source Primary Vendor Support Statement AutoCAD and verticals on Linux Explicit Linux and Wine support boundary. Autodesk does not support AutoCAD on Linux or under Wine. Open source Primary Project Source Code Proton 11 Makefile ARM64, ARM64EC, and FEX direction evidence. Does not establish broad ARM application compatibility. Open source Primary Project Release FEX-2608 Current x86 and x86-64 user-mode emulation release on ARM64 Linux. Does not establish broad Windows-application portability. Open source Owner Semantic Editorial Visual And Publication Authority Issue #686 publication authority Governs thesis, source, creative direction, evidence boundaries, relationships, implementation, and gated publication. Owner authority is not independent external corroboration or invention-priority evidence. Open source Claim discipline What is asserted—and how it is bounded Research, author analysis, and personal testimony remain distinct. Supporting links and caveats stay attached to each claim. Established Prior Art claim:686:compatibility-architecture Wine implements or translates Windows API behavior without booting a complete Windows operating system, while DXVK and vkd3d-proton translate Direct3D generations to Vulkan. Support WineHQ: About Wine DXVK 3.1 vkd3d-proton 3.0.1 Boundary Launching successfully does not make an executable native Linux software or confer vendor support. External Corroboration claim:686:wine-current-state Wine 11.0 and 11.16 establish the bounded current NTSync, WoW64, ARM64, ARM64EC, Mono, and video-decoding changes described in the Work. Support Wine 11.0 Released Wine 11.16 Released Linux kernel NTSync documentation Wine vkd3d 2.1 Boundary Release notes do not establish compatibility or performance for a specific application. External Corroboration claim:686:mixed-performance A same-hardware benchmark found some workloads favoring Ubuntu, HITMAN favoring Windows, and Quake II RTX varying by setting. Support AMD Strix Halo Windows 11 vs. Ubuntu Linux benchmarks Boundary One configuration is not a universal Linux advantage. External Corroboration claim:686:gaming-and-anticheat Linux reached 4.01 percent of Steam's July 2026 optional anonymous sample, and Proton's anti-cheat paths remain title-specific integration decisions. Support Steam Hardware & Software Survey Valve Steam Hardware and Proton Proton changelog Boundary Steam survey share is not desktop-market share, and support is not automatic for every title. External Corroboration claim:686:enterprise-support-boundary Current Microsoft 365 and Adobe desktop requirements do not list Linux, and Autodesk explicitly does not support AutoCAD on Linux or under Wine. Support Microsoft 365 desktop system requirements Adobe Creative Cloud desktop technical requirements AutoCAD and verticals on Linux Boundary Vendor support posture and technical launch behavior are different questions. Inference claim:686:arm-direction ARM64, ARM64EC, FEX, and graphics-translation work show that operating-system ABI and instruction-set assumptions can both become mediated layers. Support Wine 11.16 Released Proton 11 Makefile FEX-2608 vkd3d-proton 3.0.1 Boundary This does not establish arbitrary Windows applications as portable across ARM Linux devices. Original Synthesis claim:686:execution-contract-thesis Stop asking whether it is a Windows application. Ask what execution contract the application actually requires. Support Issue #686 publication authority Boundary No external source is presented as having made the complete thesis or establishing invention priority. Public boundary. Public-safe systems architecture analysis. The Work does not claim native Linux execution, universal compatibility, universal Linux performance, Wine as an enterprise Windows replacement, broad ARM portability, vendor support where none exists, or invention priority. 17 sources 7 governed claims 1 portable package Connected work Continue the thinking Each connection explains why the next work belongs here. The graph records the edge; this layer makes it useful to a reader. Foundations Begin with The Semantic Operating System The Semantic Operating System The semantic operating system establishes why governed meaning and dependencies remain more durable than an inherited operating-system label. A system becomes a semantic operating system when it preserves the governed conditions under which meaning remains identifiable, authoritative, explainable, movable, and actionable. Authored Systems Work By Tony Malott 2026-07-29 14 min · Deep thesis Applications Continue into The Application Is Disposable. The Context Is Not. The Application Is Disposable. The Context Is Not. The execution-contract thesis continues into a broader architecture where governed context remains durable while bounded implementations can change. When software can be regenerated cheaply from governed context, the application is no longer the durable asset. The context is. Systems Essay By Tony Malott 2026-08-04 18 min · Long-form article with Projection Factory teaching surfaces Explore the complete graph SOURCE REFERENCES WineHQ: About Wine https://www.winehq.org/about Wine 11.0 Released https://www.winehq.org/news/2026011301 Wine 11.16 Released https://www.winehq.org/news/2026082101 Linux kernel NTSync documentation https://docs.kernel.org/userspace-api/ntsync.html Proton changelog https://github.com/ValveSoftware/Proton/wiki/Changelog DXVK 3.1 https://github.com/doitsujin/dxvk/releases/tag/v3.1 Wine vkd3d 2.1 https://list.winehq.org/hyperkitty/list/wine-announce%40list.winehq.org/thread/IKBZWBNYSDKT4LDRE4BXQYVU7LGQBBFV/ vkd3d-proton 3.0.1 https://github.com/HansKristian-Work/vkd3d-proton/releases/tag/v3.0.1 AMD Strix Halo Windows 11 vs. Ubuntu Linux benchmarks https://www.phoronix.com/review/amd-strix-halo-windows-linux/2 Steam Hardware & Software Survey https://store.steampowered.com/hwsurvey Valve Steam Hardware and Proton https://partner.steamgames.com/doc/steamhardware/proton Microsoft 365 desktop system requirements https://support.microsoft.com/en-us/office/system-requirements/system-requirements-for-microsoft-365-for-home-use Adobe Creative Cloud desktop technical requirements https://helpx.adobe.com/creative-cloud/apps/get-started/desktop-technical-requirements.html AutoCAD and verticals on Linux https://www.autodesk.com/support/technical/article/caas/sfdcarticles/sfdcarticles/AutoCAD-and-verticals-on-Linux.html Proton 11 Makefile https://github.com/ValveSoftware/Proton/blob/proton_11.0/Makefile.in FEX-2608 https://github.com/FEX-Emu/FEX/releases/tag/FEX-2608 Issue #686 publication authority https://github.com/pinklon/shareplane-platform/issues/686