Microsoft 365 on Linux via umu + GE-Proton (Nix flake)

Microsoft 365 (click-to-run Office) famously does not work on stock Wine. This flake is a best-effort attempt to run it through umu-launcher with GE-Proton (the Wine build that Valve/GloriousEggroll ship for games) instead, with the Bottles project's ProtoSoda Wine core available as a second runner. It packages nothing from Microsoft: the Office Deployment Tool and Office itself are downloaded at install time by the ms365 script. You need a Microsoft 365 licence to sign in.

Where the recipe comes from

• A February 2026 report in the Bottles tracker of Office 365 x64 running on Wine 10.20 with corefonts msxml6 riched20 gdiplus, the Office Deployment Tool and a couple of DLL copies.
• The classic ruados / eylenburg Office-on-Wine notes (Direct2D registry tweak, copying the AppvIsvSubsystems* and C2R* DLLs next to the Office binaries).
• The September 2026 Bottles announcement that Microsoft 365 installs, signs in (with 2FA) and runs Word on their Soda 11 Wine core in a Windows 10 prefix. GE-Proton 11 is the same Wine 11 bleeding-edge lineage, and ProtoSoda is that Soda core in Proton layout, so both are offered.

Usage

nix run .#ms365 -- install        # create prefix, winetricks, fetch ODT, download + install Office
nix run .#word                    # or: nix run .#ms365 -- run word ~/doc.docx
nix run .#ms365 -- status
nix run .#ms365 -- help

Or install it: nix profile install .#ms365 gives you ms365, ms365-word, ms365-excel, ... plus .desktop entries.

The install downloads several GB into ~/.local/share/ms365/odt/Office and then runs the click-to-run installer inside the prefix. Leave the installer window alone; it looks frozen for long stretches.

Knobs

All optional, all environment variables:

Example, try the Soda core with a minimal install:

MS365_RUNNER=protosoda MS365_EXCLUDE="Teams OneDrive Lync Bing Groove Outlook OneNote Access Publisher" \
  nix run .#ms365 -- install

Debugging

• Logs: ~/.local/share/ms365/logs/ (umu/wine stderr) and ~/.local/share/ms365/odt/logs/ (ODT).
• ms365 exec regedit, ms365 exec winecfg, ms365 exec cmd, ms365 winetricks <verbs>.
• ms365 install download / ms365 install configure rerun a single phase.
• ms365 reset --yes deletes the prefix but keeps the downloaded Office payload.
• If a run wedges, ms365 kill.

What it took (and where it stands)

Status as of 2026-09-16 with GE-Proton11-7 and Microsoft 365 Apps build 16.0.20326.20144:

• The Office Deployment Tool downloads and installs the full suite inside the prefix.
• Word starts (with /q, no splash screen), draws its start screen and ribbon, and shows the Sign in button. On first start it also raises a "Microsoft Office cannot verify the license" dialog because the licensing shim below reports no licences. Sign-in / activation has not been verified yet.
• Excel, PowerPoint, Outlook and the rest are installed but untested.

Fixes the flake applies automatically, each one found by reading the Wine and Click-to-Run logs:

Debug aids: MS365_DEBUG=1 writes Proton's Wine log with +seh; MS365_DEBUG=1 PROTON_LOG="+module" lists every unresolved import ("No implementation for ..."), which is how the kernel32 gaps were found. Office's own logs land in drive_c/users/steamuser/AppData/Local/Temp (PUTER-*.log for Click-to-Run, Diagnostics/<APP>/ for the apps).

Licensing and sign-in (where it stands)

Office licenses itself through the Windows Software Protection Platform (SPP), which Wine does not have. The sppc/ shim is a minimal stand-in: it stores the licence files the installer hands it, serves the SKU policies from them, and lets the out-of-box 5-day Grace licence run with a persisted timer. Nothing is reported as activated and no product keys are installed. Office's full SPP validation still fails under Wine (0xC004E003), and on the legacy licensing path Word then refuses to run ("Word has run into an error ... repair now?").

The flake therefore puts the product into Microsoft's token-based licensing mode ("vNext", HKCU\...\Common\Licensing\LicensingNext\<product> = 2, what Microsoft 365 Apps use since version 1910). In that mode Office skips the SPP validation, starts as "Unlicensed Product", and licenses itself from the signed-in account through the Office Licensing Service. Shared Computer Activation (MS365_SCA=1) is the alternative token mode for business subscriptions; a personal subscription is refused there with "cannot be used to activate Office in shared computer scenarios" (0x80004005).

Sign-in works with a personal Microsoft account: OneAuth is kept, both Web Account Manager paths are switched off (Common\Identity and the Policies hives), the OneAuth broker is disabled and its login page is rendered by the Edge WebView2 runtime (feature gates under ExperimentConfigs\ExternalFeatureOverrides). The WebView2 runtime is not in the flake recipe yet: ms365 winetricks webview2 (680 MB) installs it into the prefix. Two request paths needed help from the ole32 shim: Wine's winhttp and wininet reject option codes they have not implemented with error 12009, which Office reports as sign-in error 53u4r / code 12009, so the shim accepts those tuning options.

What has been verified: sign-in completes, Word shows the account's OneDrive documents, and Office fetches the account's entitlements. What has not: an actual licence, because the test account had no Microsoft 365 subscription that includes the desktop apps. In that case Office tries to open its in-app purchase dialog, a WebView2 window in DirectComposition mode, and Wine's DirectComposition is a stub, so Word exits with code 64 instead. Buy or manage the subscription on the web, then sign in again in Word.

Other WinRT gaps the ole32 shim fills for the licensing code: Windows.Globalization.Language statics (ILanguageStatics) and Windows.Data.Json.JsonObject statics (Parse/TryParse, built on Wine's JsonValue).

Known problems

• Proofing categories are mapped by file role. The Click-to-Run manifests list which qualified component categories a language package publishes but not which file each one stands for; msi-components.py maps them by name (speller and "Normal" dictionary to MSSP*.LEX, grammar to MSGR*.LEX, hyphenation and thesaurus split between engine DLL and lexicon). Spelling works; if hyphenation or the thesaurus (Shift+F7) refuse a language, those two mappings are the suspects.
• Right-click and other popup menus close immediately under sway on the X11 driver (MS365_WAYLAND=0). Office activates its popup, hides and re-shows it while positioning it, and sway's Xwayland layer moves keyboard focus back to the main window in between; Wine then sends Office the message that cancels the menu. The Wayland driver, the default, keeps focus inside Wine.
• Wayland driver and HiDPI. The driver reports the monitor at 96 dpi, so the launcher sets Wine's dpi from the sway output scale. At exactly 192 dpi Word overflows its main thread's stack while building its first window (an Office recursion; same on GE-Proton 11-6 and 11-7), so the automatic value is capped at 180, which renders and takes input correctly on GE-Proton11-7. GE-Proton11-6's driver mixed pixel and logical coordinates in the window geometry (input offset, no input at all at 168/180 dpi) and could get disconnected for committing a surface before its configure; the flake pins 11-7 for its Wayland fixes.
• Direct2D comes from a different Wine (d2d1-fix/): nixpkgs' Wine 11.16 d2d1.dll runs on GE-Proton 11's Wine 11.0. It only depends on public DLL interfaces, but if a future Proton bumps its Wine past the fix the override becomes unnecessary; if a future nixpkgs Wine adds a dependency the Proton base lacks, the launcher's log will show d2d1 failing to load.

Expectations

This is the college try, not a guarantee. Things that historically break: Microsoft account sign-in (WebView2/Edge based), OneNote, Teams, and anything touching WinRT Windows.* APIs. If the installer dies early, pin an older build with MS365_VERSION, or switch runners.