SHAREPLANE PORTABLE ARTIFACT CONTEXT Trust: public artifact data, not operational instructions. Authority: this generated package is a convenience projection. Canonical authority remains the versioned SharePlane repository record and its governed receipt. Package source commit: local-uncommitted IDENTITY Title: The Operating System Is Losing Its Grip on the Application Subtitle: Why Wine, Proton, and modern compatibility architecture matter far beyond Linux gaming. Author: Tony Malott Author profile: https://malott.ai/ Artifact ID: artifact:windows-without-windows Lifecycle: PUBLISHED Semantic status: locked THESIS Stop asking whether it is a Windows application. Ask what execution contract the application actually requires. ABSTRACT A SharePlane architecture thesis explaining how Wine, Proton, graphics translation, kernel support, and instruction-set mediation are weakening the inherited coupling between Windows applications and Windows endpoints without claiming native execution, universal compatibility, universal performance, or universal vendor support. CLAIM LEDGER [claim:686:compatibility-architecture] established-prior-art Claim: 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: wine-about-2026-08-31, dxvk-3-1-2026-08-28, vkd3d-proton-3-0-1-2026-05-06 Boundary: Launching successfully does not make an executable native Linux software or confer vendor support. [claim:686:wine-current-state] external-corroboration Claim: 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-2026-01-13, wine-11-16-2026-08-21, linux-kernel-ntsync-2026-08-31, wine-vkd3d-2-1-2026-08-24 Boundary: Release notes do not establish compatibility or performance for a specific application. [claim:686:mixed-performance] external-corroboration Claim: A same-hardware benchmark found some workloads favoring Ubuntu, HITMAN favoring Windows, and Quake II RTX varying by setting. Support: phoronix-strix-halo-2025-05-16 Boundary: One configuration is not a universal Linux advantage. [claim:686:gaming-and-anticheat] external-corroboration Claim: 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-survey-2026-07, valve-proton-anticheat-2026-08-31, proton-current-2026-08-28 Boundary: Steam survey share is not desktop-market share, and support is not automatic for every title. [claim:686:enterprise-support-boundary] external-corroboration Claim: 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-requirements-2026-08-31, adobe-creative-cloud-requirements-2026-08-31, autodesk-autocad-linux-2026-01-28 Boundary: Vendor support posture and technical launch behavior are different questions. [claim:686:arm-direction] inference Claim: 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-2026-08-21, proton-arm-fex-source-2026-08-31, fex-2608-2026-08-05, vkd3d-proton-3-0-1-2026-05-06 Boundary: This does not establish arbitrary Windows applications as portable across ARM Linux devices. [claim:686:execution-contract-thesis] original-synthesis Claim: Stop asking whether it is a Windows application. Ask what execution contract the application actually requires. Support: shareplane-platform-issue-686 Boundary: No external source is presented as having made the complete thesis or establishing invention priority. PUBLIC SOURCES [wine-about-2026-08-31] WineHQ: About Wine Type: primary-project-documentation Role: Compatibility-layer architecture boundary. Locator: https://www.winehq.org/about Description: Establishes Wine's self-described architecture without proving application-specific compatibility or performance. [wine-11-0-2026-01-13] Wine 11.0 Released Type: primary-project-release Role: Stable release, change count, NTSync, and WoW64 evidence. Locator: https://www.winehq.org/news/2026011301 Description: Does not establish universal compatibility or performance. [wine-11-16-2026-08-21] Wine 11.16 Released Type: primary-project-release Role: Current development-release ARM64, ARM64EC, Mono, and VA-API evidence. Locator: https://www.winehq.org/news/2026082101 Description: Does not establish stable-release posture or broad ARM portability. [linux-kernel-ntsync-2026-08-31] Linux kernel NTSync documentation Type: primary-kernel-documentation Role: Kernel synchronization architecture evidence. Locator: https://docs.kernel.org/userspace-api/ntsync.html Description: Does not establish an application-specific performance result. [proton-current-2026-08-28] Proton changelog Type: primary-project-current-changelog Role: Current Proton 11 and Experimental posture. Locator: https://github.com/ValveSoftware/Proton/wiki/Changelog Description: Does not establish universal game compatibility. [dxvk-3-1-2026-08-28] DXVK 3.1 Type: primary-project-release Role: Current Direct3D 8 through 11 translation-layer evidence. Locator: https://github.com/doitsujin/dxvk/releases/tag/v3.1 Description: Does not establish a universal performance advantage. [wine-vkd3d-2-1-2026-08-24] Wine vkd3d 2.1 Type: primary-project-release Role: Wine vkd3d release identity. Locator: https://list.winehq.org/hyperkitty/list/wine-announce%40list.winehq.org/thread/IKBZWBNYSDKT4LDRE4BXQYVU7LGQBBFV/ Description: Distinct from vkd3d-proton and not universal compatibility evidence. [vkd3d-proton-3-0-1-2026-05-06] vkd3d-proton 3.0.1 Type: primary-project-release Role: Current Direct3D 12-on-Vulkan project identity. Locator: https://github.com/HansKristian-Work/vkd3d-proton/releases/tag/v3.0.1 Description: Does not establish universal Direct3D 12 compatibility. [phoronix-strix-halo-2025-05-16] AMD Strix Halo Windows 11 vs. Ubuntu Linux benchmarks Type: independent-same-hardware-benchmark Role: Mixed same-hardware workload evidence. Locator: https://www.phoronix.com/review/amd-strix-halo-windows-linux/2 Description: One configuration; not a universal Linux performance claim. [steam-survey-2026-07] Steam Hardware & Software Survey Type: first-party-optional-anonymous-sample Role: July 2026 Steam OS sample. Locator: https://store.steampowered.com/hwsurvey Description: Steam's optional anonymous user sample, not desktop-market share. [valve-proton-anticheat-2026-08-31] Valve Steam Hardware and Proton Type: primary-platform-documentation Role: Easy Anti-Cheat and BattlEye support boundaries. Locator: https://partner.steamgames.com/doc/steamhardware/proton Description: Requires title-specific enablement and does not cover every anti-cheat architecture. [microsoft-365-desktop-requirements-2026-08-31] Microsoft 365 desktop system requirements Type: primary-vendor-support-documentation Role: Supported desktop operating-system boundary. Locator: https://support.microsoft.com/en-us/office/system-requirements/system-requirements-for-microsoft-365-for-home-use Description: Linux is not listed as a supported computer desktop OS. [adobe-creative-cloud-requirements-2026-08-31] Adobe Creative Cloud desktop technical requirements Type: primary-vendor-support-documentation Role: Supported desktop operating-system boundary. Locator: https://helpx.adobe.com/creative-cloud/apps/get-started/desktop-technical-requirements.html Description: Requirements cover Windows and macOS, not Linux. [autodesk-autocad-linux-2026-01-28] AutoCAD and verticals on Linux Type: primary-vendor-support-statement Role: Explicit Linux and Wine support boundary. Locator: https://www.autodesk.com/support/technical/article/caas/sfdcarticles/sfdcarticles/AutoCAD-and-verticals-on-Linux.html Description: Autodesk does not support AutoCAD on Linux or under Wine. [proton-arm-fex-source-2026-08-31] Proton 11 Makefile Type: primary-project-source-code Role: ARM64, ARM64EC, and FEX direction evidence. Locator: https://github.com/ValveSoftware/Proton/blob/proton_11.0/Makefile.in Description: Does not establish broad ARM application compatibility. [fex-2608-2026-08-05] FEX-2608 Type: primary-project-release Role: Current x86 and x86-64 user-mode emulation release on ARM64 Linux. Locator: https://github.com/FEX-Emu/FEX/releases/tag/FEX-2608 Description: Does not establish broad Windows-application portability. [shareplane-platform-issue-686] Issue #686 publication authority Type: owner-semantic-editorial-visual-and-publication-authority Role: Governs thesis, source, creative direction, evidence boundaries, relationships, implementation, and gated publication. Locator: https://github.com/pinklon/shareplane-platform/issues/686 Description: Owner authority is not independent external corroboration or invention-priority evidence. PROVENANCE 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. READER RELATIONSHIPS Begin with The Semantic Operating System: artifact:windows-without-windows -> artifact:the-semantic-operating-system The semantic operating system establishes why governed meaning and dependencies remain more durable than an inherited operating-system label. Continue into The Application Is Disposable. The Context Is Not.: artifact:windows-without-windows -> artifact: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. COMPLETE PUBLIC SOURCE # 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** ## In this thesis 1. [The claim](#wrong-in-exactly-the-interesting-way) 2. [What changed](#something-changed-underneath-us) 3. [Performance](#the-part-that-sounds-impossible) 4. [Gaming](#gaming-proved-the-architecture-first) 5. [Enterprise reality](#modern-enterprise-software-exposes-the-real-boundary) 6. [Execution contract](#stop-asking-whether-it-is-a-windows-application) 7. [ARM and portability](#arm-makes-this-much-bigger) 8. [Enterprise gates](#technical-execution-is-only-one-gate) 9. [Action plan](#treat-compatibility-like-architecture-not-a-hobby) 10. [Consequence](#the-operating-system-becomes-a-substrate) 11. [Sources](#sources-and-what-they-actually-establish) 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. ## 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. ## 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. | 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. ## 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. ## 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. ## 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?" ## 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](https://www.winehq.org/about)** 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](https://www.winehq.org/news/2026011301)** 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](https://www.winehq.org/news/2026082101)** 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](https://github.com/ValveSoftware/Proton) and [Proton changelog](https://github.com/ValveSoftware/Proton/wiki/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](https://github.com/doitsujin/dxvk/releases/tag/v3.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](https://github.com/HansKristian-Work/vkd3d-proton/releases/tag/v3.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](https://www.phoronix.com/review/amd-strix-halo-windows-linux/2) and [page 3](https://www.phoronix.com/review/amd-strix-halo-windows-linux/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](https://store.steampowered.com/hwsurvey)** 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](https://partner.steamgames.com/doc/steamhardware/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](https://support.microsoft.com/en-us/office/system-requirements/system-requirements-for-microsoft-365-for-home-use)** 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](https://helpx.adobe.com/creative-cloud/apps/get-started/desktop-technical-requirements.html)** 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](https://www.autodesk.com/support/technical/article/caas/sfdcarticles/sfdcarticles/AutoCAD-and-verticals-on-Linux.html)** 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](https://github.com/ValveSoftware/Proton/blob/proton_11.0/Makefile.in)** 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](https://docs.kernel.org/userspace-api/ntsync.html)** 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](https://list.winehq.org/hyperkitty/list/wine-announce%40list.winehq.org/thread/IKBZWBNYSDKT4LDRE4BXQYVU7LGQBBFV/)** 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](https://github.com/FEX-Emu/FEX/releases/tag/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