Windows application compatibility
Open a Windows application from search, Files or its pinned launcher. The app opens beside native and Linux applications. You do not have to choose Wine, Proton or a virtual machine before every launch; the launcher uses the first route known to run that application correctly and shows the route beside its name.
Wine and Proton ship with the system and are integrated into its launcher, files, windows and permissions. There are three routes because “Windows compatibility” is not one mechanism.
1. Windows applications run through Wine
Wine is installed with the system and integrated into the normal app launcher, file picker, notifications, clipboard and window management. There is no separate Wine desktop and no prefix directory to manage by hand.
Each application receives its own managed Windows environment. The environment contains the Windows libraries and application data that belong to that app; one application cannot quietly change the compatibility settings or registry of another. Known-good settings are versioned with the app entry and can be rolled back when an update stops working.
The application window is an ordinary window in the current strip. It can be tabbed beside a native app, moved between strips and restored with the workspace. Its menus and controls remain the Windows application’s own UI.
2. Windows games run through Proton
Proton is installed with the system rather than left as a setup exercise. Games you add appear with the tested Proton version, launch flags, controller mapping and graphics settings attached to each title rather than kept as one global compatibility gamble.
The system keeps shader caches and large game data outside the small per-game compatibility environment, so changing a Proton version does not download the game again. A game can be pinned, searched for and launched like any other app.
Anti-cheat systems, kernel drivers and hardware-bound launchers sometimes require Windows itself. Games marks that requirement before download instead of letting the same launch fail in six slightly different Proton configurations.
3. The side-by-side Windows VM runs what translation cannot
An application that needs Windows services, drivers or behaviour Wine cannot provide opens in the managed Windows VM. Only the application window is placed on the desktop by default; the Windows taskbar and desktop stay out of the way. Choose Open Windows desktop when the full VM is actually useful.
The VM can remain suspended between launches, so opening an app resumes its existing Windows session rather than booting a second computer each time. Its windows participate in the compositor normally: they sit beside other apps, can join a tab group and return with the workspace.
The VM uses a Windows installation and licence supplied by the person or organisation using it. Setup can import an existing Windows installation into a new VM, install from an ISO, or connect to an organisation-managed VM.
Files cross through a door, not a mounted home directory
A Windows compatibility environment does not receive the home directory or every file in a workspace. Open a file with a Windows app and the desktop grants that item to the app’s Wine environment or VM. Choose a folder explicitly when the application genuinely needs a folder.
The same rule applies to the clipboard, camera, microphone, USB devices and network destinations. A grant is visible under the application’s permissions and can be revoked without dismantling its prefix or VM.
Files changed by the Windows app remain normal workspace files. Removing the app, resetting its compatibility environment or deleting the VM does not delete the work unless that deletion is selected separately.
See and change the route
Every Windows app entry shows one of these labels:
- Wine — translated locally, with a managed per-app environment;
- Proton — a game using its tested Proton profile;
- Windows VM — running inside Windows, with its window presented beside the rest of the desktop;
- Windows boot required — needs hardware or system behaviour that should not be promised through translation or virtualisation.
Open Compatibility on the app to change Wine or Proton versions, reset the environment, move the app into the VM, or keep it for Windows boot. Changes show what application data they affect before they happen.
Add applications from an existing Windows computer
Install Windows applications individually after Tilo starts. Before copying any application data, identify where that application stores it and keep the original Windows installation or a checked backup. Tilo does not inventory or migrate installed Windows applications during USB creation or installation.
For each application, choose its route explicitly: a native or Linux version, Wine, Proton, the side-by-side VM, or Windows boot. Keeping Windows available is a disk-layout decision you make before installation; an application route never changes it automatically.
If an update breaks an application
Open the app’s Compatibility page and choose the previous known-working environment. This rolls back its Wine or Proton version and compatibility settings without rolling back documents or the operating system.
For a VM app, restore the VM checkpoint created before its Windows or application update. The checkpoint contains Windows and application state, not the workspace files shared into it.
If neither path works, choose Open in Windows at next boot. A compatibility layer should have a clear exit instead of turning one necessary application into an evening of registry edits.