winapps

Abstract

Run Windows apps such as Microsoft Office/Adobe in Linux (Ubuntu/Fedora) and GNOME/KDE as if they were a part of the native OS, including Nautilus integration. Hard fork of https://github.com/Fmstrat/winapps/

The Problem

Linux users who depend on Windows-only software (Microsoft 365, Adobe Creative Cloud, specialized tools like ChemDraw or SSMS) have historically faced a binary choice: run a full Windows VM with a clunky desktop, or use Wine with fragile compatibility. This project removes that trade-off by treating a Windows VM as a background service and rendering individual applications as native Linux windows via RDP.

What This Does

winapps is a hard fork of the popular winapps-org/winapps project (15.7k stars upstream). It runs Windows inside a Docker, Podman, or libvirt VM, then queries the guest for installed applications and generates host-side .desktop launchers. The bin/winapps script is the core entry point handling setup, app discovery, and shortcut creation.

The apps/ directory contains 177 files — each app subfolder has an info file (application metadata, MIME types, launch commands) and an icon.svg. This is the mechanism for the "community tested" app list: applications with entries here get proper icons and file-type associations. Any other .exe detected in the Windows registry gets a generic launcher with an icon extracted from the binary.

Integration extends beyond launchers: the host /home is mounted in Windows via \\tsclient\home, Nautilus right-click integration opens files in the correct Windows app based on MIME type, and apps/ms-office-protocol-handler.desktop routes ms-word:// and similar links into the Windows guest.

How To Use It

The repo provides compose.yaml (Docker/Podman) and default.nix (Nix), plus docs/docker.md and docs/libvirt.md for the two primary deployment paths. There is no Makefile or install.sh; setup is manual.

Setup (Docker path, from docs/docker.md): Clone and configure git clone https://github.com/winapps-org/winapps.git cd winapps Edit compose.yaml to set your Windows ISO path and VM options docker compose up -d Run the setup script to detect apps and create launchers bin/winapps install

Configuration: Edit compose.yaml for VM resources and ISO location. The apps/*/info files define per-app MIME types and launch commands — add your own entries here for unsupported apps.

Running it: bin/winapps is the CLI. Subcommands include install (initial setup), list (show detected apps), and update (rescan for new apps). Individual apps launch via their generated .desktop files in the host's application menu.

Real-World Use

A typical deployment: an Ubuntu 24.04 workstation with a Windows 11 ISO. The admin runs docker compose up -d, then bin/winapps install. The script provisions the VM, installs RDP prerequisites, and scans for installed software. The user now opens Word from the GNOME app grid; it renders as a native window. When a colleague sends a .docx, Nautilus offers "Open with Word" via the MIME mapping in apps/word/info.

Code Health & Issues

Med — No test suite: The analysis detected zero test files. The core logic in bin/winapps (VM provisioning, registry parsing, RDP session handling) has no automated verification. This is a shell script orchestrating complex infrastructure — regressions will surface as broken user setups. Med — No CI/CD: .github/ contains only templates and a CLA signature file. No workflow files exist, so there is no automated build, lint, or test gate. Given the project's reliance on community PRs for app definitions, this is a real gap. Low — Shell script robustness: bin/winapps is a single-file shell script. Error handling quality is unverifiable from structure alone, but complex shell scripts of this size typically have brittle failure modes (unhandled non-zero exits, missing set -e). Low — Dependency on external VM images: The project requires users to supply their own Windows ISO. Windows licensing and image provisioning are entirely on the user — documented in docs/docker.md but a friction point. Low — No lockfile or version pinning: compose.yaml and default.nix are the only dependency definitions; no image digests or checksums are pinned, so reproducibility depends on upstream image stability.

The Bottom Line

This is a practical, well-scoped tool that solves a real problem for Linux users with Windows-only software needs. The architecture is sound — RDP-based app streaming is mature — and the community app catalog is a genuine strength. The lack of tests and CI is concerning for a tool that manipulates VMs and system config, so treat upgrades with caution. Best suited to individual developers or small teams who need Microsoft/Adobe tools on Linux and are comfortable with a manual, VM-based setup.