GitHub - Tombert/office365_flake: A set of Nix Flakes and scripts to get Office 365 working on Linux without virtualization. · GitHub

Skip to content

Navigation MenuSign inAppearance settingsPlatformAI CODE CREATIONGitHub CopilotWrite better code with AIGitHub Copilot appDirect agents from issue to mergeMCP RegistryIntegrate external toolsDEVELOPER WORKFLOWSActionsAutomate any workflowCodespacesInstant dev environmentsIssuesPlan and track workCode ReviewManage code changesCode QualityEnforce quality at mergeAPPLICATION SECURITYGitHub Advanced SecurityFind and fix vulnerabilitiesCode securitySecure your code as you buildSecret protectionStop leaks before they startEXPLOREWhy GitHubDocumentationBlogChangelogMarketplaceView all featuresSolutionsBY COMPANY SIZEEnterprisesSmall and medium teamsStartupsNonprofitsBY USE CASEApp ModernizationDevSecOpsDevOpsCI/CDView all use casesBY INDUSTRYHealthcareFinancial servicesManufacturingGovernmentView all industriesView all solutionsResourcesEXPLORE BY TOPICAISoftware DevelopmentDevOpsSecurityView all topicsEXPLORE BY TYPECustomer storiesEvents & webinarsEbooks & reportsBusiness insightsGitHub SkillsSUPPORT & SERVICESDocumentationCustomer supportCommunity forumTrust centerPartnersView all resourcesOpen SourceCOMMUNITYGitHub SponsorsFund open source developersPROGRAMSSecurity LabMaintainer CommunityGitHub StarsArchive ProgramREPOSITORIESTopicsTrendingCollectionsEnterpriseENTERPRISE SOLUTIONSEnterprise platformAI-powered developer platformAVAILABLE ADD-ONSGitHub Advanced SecurityEnterprise-grade security featuresCopilot for BusinessEnterprise-grade AI featuresPremium SupportEnterprise-grade 24/7 supportPricingSearch/Sign inSign upAppearance settings

You signed in with another tab or window. Reload to refresh your session.
You signed out in another tab or window. Reload to refresh your session.
You switched accounts on another tab or window. Reload to refresh your session.

Dismiss alert

Tombert

/

office365_flake

Public

Notifications
You must be signed in to change notification settings

Fork
0

Star
9

Code

Issues
0

Pull requests
0

Actions

Projects

Security and quality
0

Insights

Additional navigation options

Code

Issues

Pull requests

Actions

Projects

Security and quality

Insights

mainBranchesTagsGo to fileCodeOpen more actions menuLatest commit History51 Commits51 CommitsFolders and filesNameNameLast commit messageLast commit dated2d1-fixd2d1-fix  ole32-shimole32-shim  sppcsppc  uia-shimuia-shim  .gitignore.gitignore  README.mdREADME.md  flake.lockflake.lock  flake.nixflake.nix  ms365.nixms365.nix  ms365.shms365.sh  msi-components.pymsi-components.py  View all filesRepository files navigationREADMEMore itemsMicrosoft 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:

Variable
Default
Meaning

MS365_RUNNER
ge
ge (nixpkgs proton-ge-bin), protosoda (Bottles Soda core), or an absolute Proton dir

MS365_PREFIX
~/.local/share/ms365/prefix
Proton compat-data dir (Wine prefix lives in pfx/)

MS365_PRODUCT
O365ProPlusRetail
ODT product id (O365BusinessRetail, O365HomePremRetail, ProPlus2024Retail, ...)

MS365_CHANNEL
Current
Update channel

MS365_VERSION
unset
Pin an Office build, e.g. 16.0.18129.20158. Older builds are less likely to trip Wine

MS365_EDITION
64
64 or 32

MS365_LANG
en-us
Language

MS365_EXCLUDE
Teams OneDrive Lync Bing Groove
ODT ExcludeApp ids. Add Outlook OneNote Access Publisher for a minimal install

MS365_WINETRICKS
corefonts msxml6 riched20 gdiplus
Verbs applied before install

MS365_ODT_SETUP
unset
Use a local ODT setup.exe instead of downloading the current one

MS365_SCA
0
1 switches to Shared Computer Activation (business subscriptions only) instead of vNext token licensing

MS365_RADV_DEBUG
unset
AMD driver flags to export as RADV_DEBUG (debugging aid, not needed)

MS365_TRACE_MODULE
unset
debugging: the shim logs every export lookup into this DLL and every failed lookup (MS365_DEBUG=1 to see them)

MS365_WAYLAND
1
Wine's Wayland driver in a Wayland session; 0 for X11/Xwayland (popup menus close instantly there under sway and other wlroots compositors)

MS365_DPI
unset
Wine dpi. Unset: 96 × the focused sway output's scale (capped at 180, see "Known problems") on the Wayland driver, 96 on X11

UMU_LOG
unset
1 or debug for umu output

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:

Problem
Fix

Installer error 0-2031 (17002): integrator aborts in sppc.dll.SLInstallLicense, a Wine stub
sppc/: replacement Software Protection Platform client DLL that accepts licence installs and reports nothing installed

Installer crash in the LastRun task: Wine's WinRT PackageManager returns E_NOINTERFACE for a newer interface and Office dereferences NULL
appxdeploymentclient DLL override disabled; Office logs the failure and continues

Excel never touches ole32, so the ole32 shim (all of the fixes below that live in it) never loaded there
the same DLL is also installed as ms365shim.dll and loaded into every process through AppInit_DLLs; whichever instance loads second stays passive

Word: CoRegisterActivationFilter missing from ole32 (mso30win32client dereferences NULL)
ole32-shim/: forwarder ole32.dll that re-exports the builtin (kept as ole32_wine.dll) and implements the function

Word: SetFileShortNameW, FindPackagesByPackageFamily, SetThreadpoolTimerEx not exported by Wine's kernel32; the loader binds them to aborting stubs
the ole32 shim registers a loader notification and rewrites those import slots in every module with benign replacements

Word: special user APCs (QueueUserAPC2) dispatched wrongly by this Wine, Office aborts
the shim hides QueueUserAPC2 from GetProcAddress; Office uses its pre-20H1 path

Word: splash-screen thread crashes in combase during COM apartment teardown, Office's crash handler kills the app
Word is launched with /q

mso.dll and friends live in Office's VFS tree; the App-V redirection layer is unreliable under Wine
the VFS tree is mirrored into Program Files with symlinks

Office offers safe mode after every crash via a modal prompt
the launcher clears the Resiliency key before starting an app

Sign-in dies with 53u4r / 12009 after the password (or on the email page)
Wine's winhttp/wininet reject unimplemented option codes with 12009; the shim accepts them (winhttp 77/140, wininet 11)

Licensing dialog fails with E_NOINTERFACE
shim serves ILanguageStatics and IJsonObjectStatics, which Wine's WinRT factories lack

Word exits at start on the legacy licensing path
product set to vNext licensing mode (LicensingNext = 2), SCA off by default

Ribbon font/size boxes, Comments/Editing/Share buttons and the title-bar search field are solid grey blocks; a control only shows its text while hovered, icons vanish under the hover highlight
GE-Proton 11's Wine (11.0 base) ships a d2d1 that ignores the fill mode of geometry groups. Office draws each control's border as two nested rounded rectangles with even-odd fill (a ring); Wine fills the union, and the compositor stretches that slab over the text. d2d1-fix/ ships d2d1.dll from nixpkgs' Wine 11.16 (fixed upstream in February 2026) with its builtin signature blanked so Proton loads it, registered as a native override.

Dialogs (e.g. "save changes?") make the whole window flicker and the document area draw at the wrong scale on the Wayland driver; Excel shows black crosshair lines across the window
Office draws dialog shadows with unowned layered MSO_BORDEREFFECT_WINDOW_CLASS popups; the Wayland driver makes each an independent toplevel, sway tiles them and the layout reshuffles until the dialog closes. The shim gives those windows an owner (the active window), so they become transient and float

"Missing proofing tools" banner and no spell checking although the dictionaries are installed
Office finds its proofing tools through the Windows Installer API (component paths, feature states, "qualified components" per category and language), registrations the Click-to-Run integrator never writes under Wine. msi-components.py rebuilds all of them from the package manifests, and the ole32 shim answers the MSI calls Office makes with an empty product code (its "whichever package owns it" convention, imported by ordinal) from the registered products

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.
AboutA set of Nix Flakes and scripts to get Office 365 working on Linux without virtualization. ResourcesReadmeActivityStars9 starsWatchers0 watchingForks0 forksReport repositoryReleasesPackagesContributorsLanguages

Footer

© 2026 GitHub, Inc.

Footer navigation

Terms

Privacy

Security

Status

Community

Docs

Contact

Manage cookies

Do not share my personal information

You can’t perform that action at this time.

This repository details a set of Nix Flakes and scripts designed to achieve the functionality of Microsoft Office 365 on Linux environments by circumventing the need for traditional full virtualization. The approach leverages specialized layers, specifically combining the umu-launcher with GE-Proton, a specific Wine build, and the ProtoSoda Wine core from the Bottles project, to execute the application. The underlying goal is to address the fact that the standard Microsoft Office installation process, which relies on Windows APIs, often fails within the Wine environment.

The installation process is managed through specific Nix commands, such as nix run .#ms365 -- install, which orchestrate the downloading of necessary components, including the Office Deployment Tool, and trigger the click-to-run installer within a dedicated prefix directory. The system relies on a complex shim layer, particularly the ole32-shim, to manage interactions between the Office application and the Wine environment. This shim is crucial for handling necessary low-level calls and registering necessary functions that are missing or incorrectly implemented in the Wine kernel32 layer.

The configuration of this setup is controlled by numerous optional environment variables that allow for fine-grained control over the execution environment. These variables define elements such as the runner (e.g., ge, protosoda), the prefix location, the specific Office product ID, the update channel, language settings, and exclusions for specific features like Teams, OneDrive, and Lync. The process highlights that successful execution depends on correctly managing these variables to compensate for the inherent incompatibilities between the Windows ecosystem and Wine.

The development process involved extensive debugging, which yielded several specific fixes incorporated into the flake. These fixes addressed numerous reported issues arising from the interaction between Office and the Wine environment, including installer aborts, crashes, and failures related to API calls. For instance, issues related to the Software Protection Platform (SPP) validation were resolved by shifting the licensing mechanism to Microsoft’s token-based licensing mode, utilizing the vNext licensing model. Sign-in functionality works by redirecting the authentication process through mechanisms handled by the shim and the underlying Wine components, including the installation of necessary runtime dependencies like the webview2 runtime.

The summary also addresses specific observed complications related to graphical rendering and input handling within the Linux environment. Problems were identified concerning the Wayland compositor and Direct2D implementation, where graphical elements like dialog boxes and window borders exhibited incorrect rendering or positioning. The reported solutions involved patching specific DLLs and adjusting driver flags to ensure proper handling of geometry, DPI scaling, and window focus across the X11 and Wayland drivers.

Regarding functionality post-installation, the system successfully manages the sign-in process and allows Office to fetch user entitlements from the Microsoft account. However, the summary notes that while the process is functional, it does not guarantee actual license activation because the testing environment typically lacks a valid Microsoft 365 subscription. Furthermore, certain complex features are noted as persistently challenging, such as OneNote and Teams integration, reflecting historical difficulties in replicating these Windows-centric services. In conclusion, the effort demonstrates a complex, layered technical solution involving custom tooling and shim layers to bridge significant architectural gaps between Microsoft Office applications and the Linux operating environment, demonstrating sophisticated techniques for cross-platform software execution.