Windows apps, as native Linux windows.

Everything else re-encodes the picture. This doesn't.

WinApps and WinBoat solve the same shape of problem, and both do it over RDP RemoteApp. That one choice is what most of the difference comes down to.

RDP's video path was designed for documents. It is fine for a text editor and it falls apart on anything that moves, because every frame is encoded on one side and decoded on the other before you see it. Vypr leaves each frame in the VM's own memory and the host reads it from there, so there is no encoder to wait for and nothing to lose — about 7 ms from Windows capturing a 1440p frame to Vypr having it on this side, measured. Nothing has to be installed in Windows to make that work: no driver, Looking Glass's or anyone else's.

A window, not a desktop.

• Any Windows application, as its own native window. Several at once, each its own. Starting a second does not disturb the first.
• No driver in Windows for the picture. Frames sit in pages of the VM's own memory that the host reads directly — nothing to install, sign, or keep in step with a Windows update.
• Games, including ones that capture the mouse and read raw input, through kernel-level HID injection.
• Controllers, presented to Windows as real XInput devices.
• Audio, pinned to whatever the application is actually playing to — and your microphone, as an ordinary Windows device.
• Notifications the guest raises appear as ordinary desktop notifications here, even from an app that is minimised or not being streamed at all.
• Double-click a Linux file to open it in a Windows application — a .psd in Photoshop, an installer, a document. Saving writes back to the file you opened, not to a copy stranded in the VM.
• Drag a file from the Linux desktop straight onto a running Windows application.
• A folder from this machine, mounted in Windows as a drive over virtiofs. Files inside it are opened directly — no copy anywhere.
• Menus, popups and dialogs, positioned against the window they belong to.
• Windows come back where you left them, at the size you left them.
• Only what changed, for mostly still apps. With VYPR_DAMAGE=1 a typed character crosses as a few kilobytes rather than a whole frame. Off by default, because it costs a game more than it saves.
• Latency you can check. VYPR_STATS=1 prints, every second, how old each frame is from capture in Windows to the moment it is shown here.
• The guest's whole screen when something is wrong, at its own size or scaled to a window that fits.

Where it wins, it wins on what it was built for.

Arranged as the README has it: everything all three do sits at the top, and the rows where they part company are at the foot. Compared against WinApps and WinBoat documentation as of August 2026.

Where it loses, it loses on reach. It needs a second GPU, which most machines do not have and which cannot be worked around. There is no graphical manager. If you want Office or Photoshop occasionally on an ordinary laptop, WinApps or WinBoat will cost you far less effort and serve you better. Vypr is for the case they cannot reach — when the thing you are running has to be fast, and you have a second GPU to give it.

The parts that don't work, in full.

Every one of these is checked for and explained by vypr doctor rather than left to fail quietly.

• Exclusive fullscreen has nothing to capture. The game bypasses the compositor entirely. Set it to borderless or windowed — Vypr says so when it happens instead of showing a black window.
• Games that read raw mouse input need Parsec running in the guest, for its driver only. Nothing in userspace can produce the mouse deltas they expect. Everything else works without it.
• The passed-through GPU needs a display — a monitor or a dummy plug. The compositor has nothing to draw on otherwise.
• Clipboard is text only. Images and file lists need a format negotiation the protocol does not have.
• Dragging goes one way, and files only. Out of Windows is not implemented, and neither are folders.
• Administrator prompts cannot be answered through Vypr. Windows draws the UAC prompt on the secure desktop and refuses injected input to it. So by default Vypr turns the prompt off inside the VM, which is what makes installers work — and lowers the VM's security, which is why it says so and why vypr open-elevation --remove puts it back.
• A file outside the shared folder is copied, not shared. Each saved version is copied back out, usually within seconds — invisible in ordinary use, and wrong if you edit the same file on both sides at once.

Vypr does not create your VM. It makes an existing one useful.

Two installers, one per side.

On Linux, from a clone

./install/install.sh

It builds and installs the binaries, configures your VM, generates a key for the guest, and prints the two commands that need root rather than asking for your password. It only changes the VM where something is actually missing, and saves the original settings first.

In Windows

Run vypr-setup.exe from the latest release inside the VM, then restart Windows. One file, nothing to unpack: it carries the agent, gives it the one Windows right it needs to stream — no driver — and authorises the key the Linux installer printed. It can also add Parsec's mouse driver, for games that read raw mouse input.

Then let it find your apps

vypr detect

That reads the guest's desktop — shortcuts and Steam entries alike — lists what it found, and adds the ones you pick, pulling each app's real icon out of the guest executable so it lands in your application menu like anything else.

Day to day

vypr run <app>

start it, bringing up the VM and session if needed

vypr add <app> <path>

register a Windows application by path, or a Steam URL

vypr open <file>

open a Linux file in the Windows app that handles it

vypr associate

make double-clicking .psd, .exe and friends do that

vypr --debug desktop

stream the guest's whole screen, for when something is wrong

vypr doctor

check the setup for the things that fail quietly

Close the last window and the VM shuts itself down a minute later. Launching something during that minute cancels it.

It started with one goal: play FiveM on Linux.

FiveM does not run under Wine, and the usual answers were all unsatisfying. A whole-desktop stream means alt-tabbing inside someone else's desktop. RDP hands over individual windows properly, but its video path was built for documents and falls apart on anything that moves. Running the game on a second machine means owning a second machine.

What was actually wanted was narrower than any of those: one window, from the VM, behaving like a native one. Vypr is that, and it turned out to work for everything else in the VM too.