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.
- 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*andC2R*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.
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 -- helpOr 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.
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- 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 configurererun a single phase.
- ms365 reset --yesdeletes the prefix but keeps the downloaded Office payload.
- If a run wedges, ms365 kill.
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).
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).
- 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.pymaps 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.16d2d1.dllruns 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 showd2d1failing to load.
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.