If you need to run Windows-only desktop software on a Linux desktop without rebooting, two open‑source projects now make that painless for many workflows:
WinApps and
WinBoat. Both run a real copy of Windows inside a managed virtual machine and export individual Windows program windows to your Linux compositor using Microsoft’s RemoteApp/Remote Desktop Protocol (RDP). The result is closer to “native” app integration than firing up a full desktop VM, and far higher compatibility than Wine for demanding commercial applications — but it also shifts complexity into virtualization, licensing, and system resources. The Register’s hands‑on review walked through both tools, tried Docker/Podman and KVM/libvirt approaches, and came away convinced the approach works — with tradeoffs. rview
Linux desktops have matured dramatically, but some applications — notably current Microsoft Office, Adobe Creative Cloud, and other commercial suites — remain Windows‑native and difficult or impossible to run reliably under Wine or Proton. That leaves three pragmatic options for Linux users who
must run Windows GUI apps: dual‑boot, Wine/Proton, or run a real Windows instance in a VM. The WinApps/WinBoat approach takes the VM option and tightens integration: a headless or hidden Windows guest runs locally (or in a container), a tiny guest agent cooperates with the host, and FreeRDP/RemoteApp presents each Windows application as its own top‑level window on the host desktop. The technique trades the translation work of Wine for full fidelity by running the genuine Windows binaries, and modern implementations automate much of the plumbing.
WinApps has been armature, flexible toolkit that supports Docker, Podman, and direct libvirt/KVM control. WinBoat is newer, designed around automation and ease of use, shipping an Electron UI and prebuilt packages (AppImage, .deb, .rpm) and focusing on getting a Windows guest up and exposing per‑app RemoteApp windows with as little user fiddling as possible. The WinBoat project, its README and v0.9.0 release notes show a deliberate push to simplify provisioning and add Podman support and UWP (Microsoft Store) visibility. (
github.com
How the technology actually works
The components, in plain English
- A real copy of Windows runs as a guest in a virtualized environment (QEMU/KVM under libvirt, or QEMU inside a container).
- A tiny “guest server” or agent inside Windows exposes program windows and control hooks to the host.
- The host uses FreeRDP (xfreerdp) with RemoteApp support to receive and display individual application windows rather than a whole remote desktop.
- The VM’s filesystem can be bind‑mounted or shared so your Linux home appears in the Windows guest (eg. \tsclient\home).
- A launcher or applet on the host starts the VM when needed, launches the Windows app via RDP/RemoteApp, and puts the app into your native application menu or dock.
Thi idea behind enterprise RemoteApp or Azure Virtual Desktop (AVD), but executed locally to integrate a single user’s apps into their desktop workflow.
Why RemoteApp + FreeRDP?
FreeRDP implements the RDP protocol and includes RemoteApp support, which was added to FreeRDP some time ago; in practice the reliable choice for per‑app windows is xfreerdp. The FreeRDP documentation discusses RemoteApp and explicitly recommends the xfreerdp client for this mode. This is the glue that turns an entire Windows window surface into a composited native window on Linux. (
github.com
WinApps vs WinBoat — the design math
WinApps (mature, flexible)
- Origin and scope: WinApps began around 2020 and evolved through forks and community maintenance; the winapps-org project documents support for Docker, Podman and libvirt, and ships a wide range of integration features such as Nautilus file associations, desktop icons, and a system tray control/launcher. It is explicitly aimed at power users and sysadmins willing to configure containers or VMs. (github.com
- Strengths:
- Flexible backends: Docker/Podman or full KVM/libvirt give choices for performance, security, and storage placement.
- Deeper integration: desktop shortcuts, MIME type mappings, custom icons, and a lightweight launcher/tray applet.
- Advanced VM customizations: with libvirt you can configure memory ballooning, remote hypervisor connections, passthrough devices and even dedicate a separate machine to host the Windows VM.
- Weaknesses:
- Setup complexity: the libvirt/KVM path requires manual configuration and comfort with virtualization tooling.
- Storage/partition demands: container defaults may put large VM images under /var/lib so you must plan disk layout (the docs recommend at least a 32–64 GB virtual disk for a Windows system). (github.com
WinBoat (automation, approachable)
- Design: WinBoat packages a GUI installer and automates provisioning. It runs a Windows guest inside a container and uses FreeRDP + RemoteApp to present apps. The project explicitly positions itself as an easier, “it just works” alternative to WinApps. The repository and the v0.9.0 release notes document the automated flow and added features like Podman support and UWP app visibility. (github.com
- Strengths:
- Minimal user effort: guided install, AppImage/.deb/.rpm packaging, built‑in VM download/auto‑install flows.
- UX focus: simple dashboard, per‑app list, resource monitor and click‑to‑open apps.
- Storage choice: installer asks where to store the containerized VM assets, making it easier to keep large files off root.
- Weaknesses:
- Less configurable than WinApps’ libvirt route.
- Podman support exists, but Podman rootless limitations (e.g., USB passthrough) mean some advanced peripheral use cases may be blocked. WinBoat’s release notes explicitly call out USB limitations under Podman. (github.com
Installation and first‑run realities (what to expect)
Both projects put prerequisites in the foreground: you need KVM enabled on the host (VT‑x/AMD‑V and KVM modules), an RDP client (FreeRDP/xfreerdp), and either Docker or Podman (or libvirt/qemu for the KVM path). WinBoat’s AppImage makes it convenient across distributions, but AppImages can trigger sandboxing or userns AppArmor restrictions on some distributions; a common workaround is toggling the kernel sysctl that controls unprivileged user namespaces or using the AppImage’s --no-sandbox flags. The Register’s tester noted needing to set kernel.apparmor_restrict_unprivileged_userns to 0 during AppImage runs; community posts and distribution notes show this is a known issue on some Ubuntu builds. (
reddit.com
A realistic setup checklist:
- Enable virtualization (BIOS/UEFI: VT‑x or AMD‑V) and KVM on the Linux host.
- Install Docker (or Podman) and FreeRDP/xfreerdp. Podman offers rootless operation by default; Docker historically required a root daemon but now offers rootless mode with limits. Choose based on your trust model and device passthrough needs. (docs.podman.io
- Allocate disk and RAM for the guest: aim for 32–64 GB disk and at least 8 GB RAM recommended for a comfortable Windows desktop experience. WinApps docs and WinBoat’s own prereqs make similar recommendations. (github.com
- Run the installer (WinBoat AppImage or WinApps installer). For libvirt/KVM manual installs you’ll use virt‑manager or virsh to create the guest. Virt‑manager can also connect to remote libvirt hosts if you prefer to run the Windows VM on another box. (michelebologna.net
- Activate Windows: you must supply a valid Windows license (no project supplies activation). Windows IoT Enterprise LTSC is an option commonly chosen for low‑maintenance installs and was used by The Register for testing, but LTSC has specific licensing and usage limits — it’s intended for specialized devices and volume licensing channels. Read Microsoft’s documentation and ensure your licensing matches yourn.microsoft.com](https://learn.microsoft.com/en-us/windows/iot/iot-enterprise/deployment/volume-license)
Performance, integration, and user experience
- Launch speed: Wine typically launches a Windows app faster than starting an RDP‑exported app backed by a full Windows guest. The extra overhead on older hardware can be noticeable; the Register on an older ThinkPad and much smoother behaviour on a newer laptop. Expect the Windows guest to consume memory and CPU even when “hidden”.
- Display and multi‑monitor: FreeRDP RemoteApp generally presents windows as native, but edge cases arise — the Register noted display glitches with two screens. RemoteApp compositing depends on both FreeRDP’s capabilities and your compositor/window manager; some combinations can reveal artifacts. If you use multiple high‑DPI displays or exotic compositors, test carefully.
- Filesystem and clipboard: Both projects expose your Linux home folder inside Windows (WinApps via \tsclient\home and WinBoat via \host\lan in referenced docs), letting you open and save files seamlessly. Clipboard integration is supported in both, making copy/paste work between Linux and Windows apps.
- Hardware passthrough: KVM/libvirt offers richer passthrough options (GPU, USB, network), while containerized approaches are easier but can limit passthrough. Podman’s rootless mode is a security advantage but restricts some device passthrough; WinBoat’s release notes explicitly mention USB passthrough limitations under Podman. Use libvirt if you need PCIe GPU passthrough or complex USB devices. (github.com
Compatibility: when this beats Wine (and when it doesn’t)
Why run a full Windows guest?
- Full fidelity: any Windows app that refuses to run under Wine or needs deep Windows APIs (UWP/Microsoft Store apps, some MS external integrations, or proprietary drivers) will run correctly in a real Windows guest.
- Complex enterprise apps: large Microsoft/Adobe suites, commercial engineering or finance tools, or applications with bundled installers and services are much likelier to work unchanged.
- Anti‑compatibility blockers: kernel‑level anti‑cheat systems or drivers rarely work in Wine; a VM has better chances but even then anti‑cheat kernel hooks may still block or break in a virtual environment.
When Wine/Proton is still better:
- Lightweight apps and many games: Wine/Proton often launches faster, has less overhead, and integrates well for gaming via Proton’s graphics translation (DX → Vulkan). For full‑screen gaming, VMs typically underperform compared with native Wine/Proton unless you pass a GPU through.
- Maintenance and licensing: Wine eliminates the need for a Windows license, antivirus, and Windows updates — a big operational simplification.
The practical rule: use Wine/Proton for what they do well (games, many desktop apps), and use WinApps/WinBoat when you need
guaranteed Windows compatibility (Microsoft Store, current Office, Adobe’s latest releases, or specialised corporate apps).
Security, updates, and licensing — the real costs
Running a Windows VM is running another OS you are responsible for:
- Licensing: neither project provides Windows licenses. You must supply a valid license key or use an evaluation ISO. Windows IoT Enterprise LTSC and other SKUs have special licensing terms; consult Microsoft’s licensing docs if you plan volume or embedded scenarios. (learn.microsoft.com
- Patching: the guest needs Windows updates and antivirus like any other Windows installation. Automating patching inside the VM matters if the guest is network‑exposed or used daily.
- Attack surface: exposing remote desktop services or guest agent channels can raise risk if misconfigured. Prefer local VM instances, careful firewalling, and minimal guest services.
- Resource sharing risks: bind‑mounting your home directory into Windows is convenient, but it means that malware on the Windows side can access Linux files exposed to the guest. Use least privilege mounting and consider read‑only mounts for risky workflows.
Flagged vulnerabilities and cautionary notes:
- Some claims about “USB passthrough works with Docker” or “Podman behaves identically” are environment dependent and have clear limitations; WinBoat’s own docs and release notes call out pods/Podman USB limitations, and community reports show quirks with Docker Compose versions and AppImage preflight checks. Treat those features as conditional depending on container runtime, kernel, and distribution packaging. (github.com
Advanced topics: libvirt customization and memory ballooning
If you choose WinApps with libvirt/KVM, you can tune VM behavior:
- Ballooning: memory ballooning lets the hypervisor reclaim unused RAM from the guest. WinApps’ libvirt mode explicitly supports advanced configuration such as ballooning, which can let a 4 GB nominal VM grow to 8 GB when needed. However, automatic ballooning isn’t a solved problem — default libvirt/QEMU setups typically require scripted or manual adjustments to reclaim memory dynamically; community posts and Q&A resources note that generic automatic ballooning is limited and often requires custom orchestration. If you expect aggressive memory sharing between host and guest, plan to script or monitor ballooning metrics. (unix.stackexchange.com
- Remote VM hosts: virt‑manager can manage libvirt/QEMU on remote machines over SSH, so you can host your Windows VM on an older box or a dedicated machine and expose apps to your main desktop. This enables scenarios like using an under‑powered laptop as an on‑prem Windows server while your daily machine acts as a thin client with per‑app windows. (michelebologna.net
A pragmatic decision guide: which approach should you pick?
- If you only occasionally need one or two Windows apps that Wine/Proton supports: stick with Wine/Proton for speed, simplicity, and zero‑cost licensing.
- If you need guaranteed compatibility with modern Microsoft/Adobe enterprise apps, or UWP/Microsoft Store apps, and you accept the cost of a Windows license and updates: use WinBoat if you want an easy, automated setup and don’t need advanced passthrough; use WinApps with libvirt if you want maximum customization, remote hypervisor support, and advanced device passthrough. (github.com
- If you need to publish apps for many users or want centralized management with official support: consider Windows Server RemoteApp or Azure Virtual Desktop rather than a local, community solution.
Practical recommendations and best practices
- Plan storage: don’t let container defaults place multi‑tens‑of‑GB Windows disks on a tiny root partition. Put VM images or container storage on a large data partition.
- Allocate RAM sensibly: for daily productivity work, 8 GB guest RAM with ballooning up to 16 GB is reasonable on hosts with 32+ GB; lower‑spec systems will feel sluggish.
- Use libvirt if you need GPU or full USB passthrough. Use WinBoat’s ease of use if you want a fast path to per‑app windows.
- Harden the guest: enable automatic Windows updates, restrict network exposure, and limit bind mounts. Consider snapshotting the VM before major installs or Windows updates.
- Test multi‑monitor and high‑DPI setups before committing to the workflow — RemoteApp/FreeRDP integration depends on the client, compositor and the guest configuration.
- Keep container tools up to date but be aware of version quirks — community threads report Docker Compose version mismatches can break the WinBoat install flow; check release notes and version requirements before upgrading. (reddit.com
Strengths and risks — final critical analysis
Strengths
- Compatibility parity: because these solutions run a genuine Windows guest, virtually any Windows desktop app that works on a normal Windows PC can run inside the VM.
- Tighter desktop integration: RemoteApp + FreeRDP can make Windows apps feel native — separate windows, compositor integration, and desktop menu entries.
- Open source: both WinApps and WinBoat are community projects under permissive licenses that invite scrutiny and contribution. (github.com
Risks and caveats
- Operational overhead: you’re responsible for Windows licensing, updates, and antivirus; that increases the maintenance surface compared to Wine.
- Resource cost: a full OS guest consumes RAM, CPU and disk. For all‑day usage, budget a host with plentiful RAM and a fast SSD.
- Security exposure: bind‑mounting home, enabling network services, or exposing RDP without care increases risk. Treat the guest as a networked device.
- Ecosystem maturity differences: WinApps’ libvirt path gives deep control but requires skill; WinBoat is smoother but sometimes lags in edge capabilities (USB passthrough under Podman). Release notes and community threads show active iteration and occasional regressions tied to container runtime versions. (github.com
Where claims are uncertain
- Any claim that “everything just works on every distro” is optimistic. AppImage oddities (AppArmor/userns issues) and distribution packaging idiosyncrasies mean real installs can require small fixes. Documented heuristics exist (sysctl changes or persistent sysctl config files), but these are system dependent and should be considered operational caveats,ed. (reddit.com
Conclusion
WinApps and WinBoat bring a practical and powerful third path to running Windows applications on Linux: not emulation, but real Windows in a locally managed VM whose app windows appear as native on your desktop. For users and organizations that must run modern Microsoft and Adobe applications or other Windows‑only enterprise tools, these projects deliver reliable compatibility with impressive desktop integration. Choose WinBoat if you want a guided, largely automated experience; choose WinApps (especially its libvirt route) if you prefer maximum control and advanced passthrough options.
Neither option eliminates the tradeoffs: running a full Windows guest means licensing, patching, and resource overhead. But for many workflows that can’t be ported and can’t be trusted to compatibility layers, WinApps and WinBoat provide a sensible, open‑source, and increasingly polished way to “run Windows apps on Linux” while keeping the Linux desktop at the center of your work.
Source: theregister.com
Contain your Windows apps inside Linux Windows