Skip to content

Compatibility and DWM architectures

Jump to bottom
ALTaleX edited this page Aug 24, 2026 · 4 revisions

Compatibility and DWM architectures

Supported versions

  • Windows 10 build 17763 (1809) through build 19045 (22H2)
  • Windows 11 builds below 28000 with the Legacy DWM architecture
  • Windows 11 builds 28000 and later with the experimental MILComp DWM architecture
  • Windows Server 2022

Only Windows builds from the General Availability channel are supported. Canary, Dev, Beta, Release Preview, and Windows Server versions other than 2022 are unsupported. Running OpenGlass on an unsupported build can crash DWM.

Installer and DWM architectures

One source tree builds two architecture-specific OpenGlass.dll files:

Build target Target builds Integration path Status
OpenGlass.Legacy.vcxproj 17763 through 27999 Legacy MIL compositor draw-stream hooks Stable
OpenGlass.MILComp.vcxproj 28000 and later Windows.UI.Composition visual hooks Experimental

Current releases use one unified OpenGlassSetup.exe on every supported system. Older OpenGlass releases required users to choose a build-specific installer; that manual selection is no longer needed. The unified installer reads the exact Windows build and writes only the matching OpenGlass.dll: Legacy on builds 17763 through 27999, or MILComp on build 28000 and later.

Both DLLs are carried inside the installer, but only one is written to the installation directory. If Windows is upgraded across the build 28000 boundary, run the installer again so the installed DLL matches the new compositor architecture. The Legacy DLL cannot support build 28000+ because the compositor path it hooks was removed; see issue #260.

Compatibility decisions

OpenGlass makes four separate compatibility decisions:

  1. Installer architecture selection. The OS build chooses the Legacy or MILComp DLL at the build 28000 boundary.
  2. Module range. Each uDWM.dll and dwmcore.dll schema declares its architecture range. ModuleRegistry::Freeze rejects versions outside that range before symbol collection or hook preparation.
  3. Recognized build warning. Each schema's known_builds list controls only the new-Windows-version warning. The warning is suppressed only when both module registries recognize their current build. Recognition is not a runtime support claim.
  4. Exact runtime readiness. Both modules must resolve and validate every active Required projection before either publishes slots or variables. Semantic binary evidence and real-OS testing remain separate support requirements.

The installer therefore uses the OS build only to select the DWM architecture. Runtime support still depends on the exact build and revision, projected private layouts and symbols, verified hook calling contracts, and capabilities observed in the corresponding DWM binaries. An architecture match, an open-ended module range, or an entry in known_builds cannot establish support by itself.

Use the exact build and revision reported by winver when checking compatibility or filing an issue. Release names are not precise enough to identify a supported binary.

Clone this wiki locally