Wine can run Windows applications on Linux without installing a complete Windows operating system. Bottles adds a graphical interface for managing those applications, their settings and the extra components they need. The combination is useful when one Windows program stands between you and an otherwise workable Linux desktop.
Compatibility is not universal, though. Installing successfully, opening a window and completing real work are three different tests. A sensible setup keeps applications separate, grants access only to the files they need and preserves a working configuration before you start experimenting.
This guide covers installing Bottles, creating an application environment, handling dependencies and diagnosing common problems. Before starting, check whether a suitable native package or browser version exists through the usual Linux application installation options. Running the Windows edition should solve a genuine requirement, not become a maintenance project by accident.
What Wine and Bottles Actually Do
Wine provides a program loader and implementations of Windows application programming interfaces. Windows software calls those interfaces, and Wine supplies the corresponding behaviour on the host operating system. It is not a virtual machine running a separate Windows installation; the Wine project’s technical introduction describes this division between loading Windows binaries and implementing their interfaces.
Bottles manages the environment around Wine. Instead of remembering which settings belong to which program, you create named bottles and adjust them individually. Three terms matter:
A prefix is the directory containing an application environment’s Windows-style files, registry data and configuration. A bottle is the environment Bottles manages around that prefix. A runner is the Wine build used to execute the software.
Think of a bottle as a separate application workspace, not a separate computer. You might keep an old diagram editor in one bottle and a newer document utility in another. That separation makes configuration changes easier to track. It does not, by itself, establish a security boundary between hostile programs.
The distinction also helps with troubleshooting. A problem might belong to the application, its prefix, the selected runner or Linux itself. Reinstalling everything treats those very different causes as though they were the same.
Decide Whether Wine Is the Right Approach
Start with the task you need to complete rather than the application’s name. Does the job require editing an old project format, exporting a report, connecting a USB instrument or reproducing a document’s printed layout? These requirements determine what you must test.
| Requirement | Practical starting point | What to verify |
|---|---|---|
| A standalone Windows desktop utility | Test in a fresh bottle | Opening, saving, exporting and repeated launches |
| An application with a suitable Linux edition | Evaluate the native edition first | Project compatibility, plugins and required features |
| A program tied to Windows drivers or hardware services | Investigate a Windows environment before investing time in Wine | Driver requirements, device access and vendor support |
| A Windows game distributed through Steam | Assess the Steam and Proton route first | The game’s current compatibility and required online features |
If the application needs behaviour that your Wine setup cannot provide, a Windows virtual machine using KVM and QEMU may be a better experiment. That involves a complete guest operating system, with its own installation, updates and resource requirements.
For games, follow the separate Steam and Proton guide. Bottles can manage games, but productivity software and Steam gaming need different troubleshooting priorities.
Search for compatibility reports matching the exact application release and relevant features. A report that an older edition opens successfully does not establish that a newer subscription installer, plugin or login component works. Treat reports as starting points for your own checks, not purchase guarantees.
Install Bottles Through Flathub
Use the stable Bottles Flatpak as the starting point for this workflow. The Bottles listing on Flathub identifies the application as com.usebottles.bottles and lists its environment, runner, dependency and backup features. The listing currently provides an x86_64 build, so do not assume the same installation route applies unchanged to an ARM laptop.
On a distribution with Flatpak and Flathub already configured, search for Bottles in the software centre. Check the package’s origin before installing: similarly named utilities and unofficial packages are not interchangeable.
If Flatpak is not configured, complete your distribution’s setup first. Installing packages through different channels can otherwise become confusing, particularly when the software centre displays more than one entry. Our guide to Linux package managers covers the distinction between distribution packages and other installation methods.
Launch Bottles and allow its initial component setup to finish before creating an environment. Keep an internet connection available during this stage. A component download that never completed is a different problem from a Windows application that fails after installation.
Avoid beta builds for your first attempt. Establish whether the ordinary stable setup works before adding another variable.
Create a Separate Bottle for Each Unrelated Application
Create a new bottle and give it a recognisable name, such as “Diagram Editor” or “Legacy Reports”. Choose the Application environment for ordinary desktop software. Leave the initial runner and settings alone unless you have a documented reason to change them.
Presets provide starting configurations, not compatibility certificates. Selecting Application does not mean every office program will work, just as selecting a gaming preset does not make every game compatible.
Keep unrelated applications in separate bottles. If a document converter needs a different runtime or Windows compatibility setting, you can change its environment without disturbing the diagram editor. Separation also makes removal cleaner: you know which application owns the environment you are deleting.
There are reasonable exceptions. A program and its plugins, helper tools or companion applications may need shared registry entries and files. In that case, keeping them together can make sense. Group by software relationships, not by the fact that everything arrived as an EXE.
Record the application version and selected runner once you have a working installation. A short note now is more useful than trying to remember six months later which combination finally behaved.
Install and Launch the Windows Application
Download the installer from the software publisher or another authorised distribution channel. Keep the original filename and version information. If an offline installer is available, consider it for troubleshooting because it separates application installation from a web installer’s download stage.
- Open the intended bottle. Confirm its name before running anything.
- Select Run Executable. Choose the application’s installer, usually an EXE or MSI package.
- Complete the installer. Keep its default installation directory unless the application requires something else.
- Find the installed program. Check the bottle’s Programs area rather than repeatedly reopening the installer.
- Perform a small work test. Open a sample file, make a change, save it and reopen the result.
Interface wording and placement can change between Bottles releases. The useful distinction is between running an installer once and launching the installed application afterward. An installation wizard appearing again usually means you selected the setup program, not the installed executable.
If the program does not appear automatically, locate its executable within the bottle and add it to the Programs list. Choose the application itself rather than an updater, crash reporter or uninstaller. Set a working directory only when the program needs one, such as when it expects supporting files beside its executable.
Portable applications need similar care. Keep their complete directory, including accompanying libraries, configuration files and resources. “Portable” does not necessarily mean the EXE is the only file required.
For a practical acceptance test, use a disposable copy of a real project. A blank document might open perfectly while a project containing embedded fonts, plugins or external assets exposes the problem you actually need to solve.
Install Dependencies Only When There Is a Reason
Some Windows applications need extra runtime libraries, fonts or framework components. Bottles includes a dependency manager that installs supported components into the selected environment. Its dependency documentation covers components including Visual C++ redistributables, .NET Framework releases and XML libraries.
Do not install the entire dependency catalogue as a precaution. Every addition changes the environment, and a collection of overlapping runtimes makes later diagnosis harder. Start with the application’s documented requirements or a clear error message.
If the publisher names a Visual C++ runtime, use the matching dependency where available. If the error refers to a missing library, establish which official runtime supplies it. Downloading individual DLL files from an unfamiliar archive is not a sound repair method.
Framework names also deserve attention. “Needs .NET” is incomplete guidance: identify the required product and release. An installer detecting a framework is not proof that every feature the application uses will work under Wine.
Make one dependency change at a time, then repeat the same test. Keep a brief record of what you added and why. If an experiment makes matters worse, restore a known working copy rather than trying to reverse a dozen undocumented changes.
Avoid mixing Bottles’ dependency workflow with unrelated system Wine commands against the same environment. Even when an advanced procedure is valid, you need to know which prefix and runner it targets.
Handle 32-Bit Applications Without Following Outdated Advice
Older tutorials often tell every user with a 32-bit Windows program to create a purely 32-bit prefix. That is no longer reliable general advice. Wine 11.0, released on January 13, 2026, made its new WoW64 mode fully supported and deprecated pure 32-bit prefixes; those prefixes are not supported in the new mode. The Wine 11.0 release announcement documents these architecture changes.
WoW64 allows 32-bit Windows software to run within a 64-bit Windows environment. For Bottles users, the practical approach is to start with the selected runner’s supported defaults rather than forcing architecture settings copied from an old forum post.
The Wine build supplied by a distribution and a runner downloaded by Bottles may differ. Advice that applies to one does not automatically apply to the other.
If a compatibility workaround requires another architecture or runner, test it in a new bottle. Preserve the existing environment until the replacement passes your application tests.
Manage Files and Flatpak Permissions Carefully
A bottle’s C: drive is a directory structure, not a Windows partition. It contains familiar locations such as Program Files and user application data, but those files live within the Linux storage used by Bottles. Use the bottle’s Browse C: function rather than guessing its full path.
This distinction matters when saving work. A document stored inside a bottle may be removed when that bottle is deleted. Decide where project files belong, and confirm the actual Linux location before trusting an application’s familiar-looking Documents shortcut. The Linux filesystem guide helps explain how these locations fit into your home directory.
Flatpak adds another layer: an application can only reach resources allowed by its permissions or granted through supported portal interactions. Selecting a file through a portal can grant access to that file without exposing a whole directory. The Flatpak sandbox and filesystem permission documentation describes these access rules and recommends avoiding broad home-directory permissions.
That can affect installers distributed as several files. Selecting the setup EXE does not necessarily provide access to every archive or resource beside it. If installation stops while looking for a companion file, check directory access before blaming Wine.
One practical approach is to copy the complete installer or portable application directory into the bottle’s C: drive and run it there. For ongoing work, use a dedicated Linux project directory and grant access only to that location through your Flatpak permission manager.
Prefer read-only access when a program only needs to inspect files. Give write access when saving or updating is required. Do not expose your entire home directory just to make one missing folder appear.
Flatpak permissions and ordinary Linux permissions are separate checks. A folder can be visible inside the sandbox yet remain unwritable because of its ownership or access mode. Use the file permissions and ownership guide to diagnose that layer instead of making everything writable.
Adjust Graphics Settings After Establishing a Baseline
Start with the bottle’s graphics defaults. Change them only after observing a rendering problem or finding a relevant application requirement. Several switches with impressive names do not add up to a faster document editor.
DXVK implements Direct3D interfaces using Vulkan. It can matter for applications that use those interfaces, not just games. The DXVK project documentation lists its supported Direct3D versions and driver requirements. Check the requirements of the component version actually selected in your bottle rather than assuming every Vulkan-capable GPU is sufficient.
If an application displays a black window, corrupted panels or a crash when opening a 3D view, check the Linux graphics stack before installing random Windows components. Our NVIDIA and AMD graphics driver guide covers the host-side checks.
Test one graphics change at a time using the same project and operation. If you toggle several options together, you cannot tell which one helped or introduced the next problem.
On a hybrid-graphics laptop, use the discrete GPU when the workload justifies it rather than for every small utility. Consider power use alongside performance; the Linux laptop battery guide covers the wider trade-offs.
Troubleshoot the Failure You Can Reproduce
Write down the exact failure point before changing settings. “Does not work” could mean the installer cannot download, the program crashes at startup, a login page stays blank or exporting produces a damaged file. Each points to a different investigation.
The Installer Runs, but the Application Does Not Start
Confirm that you are launching the installed executable in the same bottle used for installation. Check whether the application needs supporting files, a runtime or a working directory that was not preserved in its launch entry.
For a portable application, test from its complete directory inside the bottle. For an installed application, do not move only its EXE to another location and expect registry entries and resources to follow.
Read the available diagnostic output around the failure. Capture the application version, runner, error message and steps that reproduce it. Remove usernames, document contents, tokens and other private details before sharing logs.
The Program Opens, but Documents Look Wrong
Separate file compatibility from display problems. Test a simple new document, then a copy of the affected file. Check whether the issue involves missing fonts, text scaling, embedded objects or a plugin.
If exact layout matters, compare both exported and printed output. A document that looks acceptable in the editor may still produce different pagination or positioning. Use a reference file with known output rather than judging by memory.
Opening or Saving Files Fails
Check the destination directory, available space, sandbox access and Linux write permissions. Save a new file with a simple name into a known writable test directory. Then close the application and verify the file from the Linux file manager.
If that succeeds, move outward one variable at a time: another directory, an external drive, then the original project. This separates an application failure from a storage or access problem.
A Previously Working Application Breaks
Identify what changed: the application, runner, graphics components, dependencies or host system. Test against a preserved bottle where possible. Reinstalling the application immediately can destroy evidence and consume activation attempts without addressing the cause.
A fresh bottle is also a useful comparison. If the same installer works there, the old environment’s accumulated configuration deserves attention. If both fail at the same step, investigate their shared components and external requirements.
When to Use Wine Directly Instead
Bottles is convenient for interactive desktop use, but direct Wine can suit scripted workflows, development testing or environments where you need explicit control over every setting. The trade-off is that you manage prefixes, dependencies and launcher configuration yourself.
The WINEPREFIX environment variable selects the directory Wine uses for its data; without an explicit setting, Wine normally uses $HOME/.wine. The Wine manual distributed by Debian documents prefix selection, diagnostic settings and library overrides.
The important habit is consistency. Installation, configuration and launching must target the intended prefix. A fix applied to the default prefix will not repair an application installed somewhere else.
Do not casually open a Bottles-managed prefix with a different system Wine build. If you need to compare runners or management approaches, work from a copy. Reproducibility is worth more than saving a few clicks.
Back Up Working Bottles and Protect Their Data
Once the application passes its work tests, preserve that state. Bottles provides backup and duplication functions, covered in its bottle backup documentation. Check what your chosen export includes and verify that it can be restored before treating it as a recovery plan.
Preserve the application installer, version details, runner information and notes about added dependencies. Back up project files separately, particularly when they live outside the bottle. A copy of the application environment does not automatically protect every folder you allowed it to access.
Close the application and its background processes before copying its environment. Keep backups on separate storage, and test recovery with disposable data. The broader Linux desktop backup and recovery guide covers protecting files beyond Bottles.
Use copies for experiments and keep the working bottle available until a replacement passes the same tests. Avoid stacking application, runner and graphics changes immediately before a deadline.
Security needs the same restraint. Do not treat Wine or a separate prefix as a malware-analysis sandbox. Run trusted installers as your ordinary desktop user, never with administrator privileges as a troubleshooting shortcut. Keep unrelated confidential files outside directories you expose to the Windows application.
Keep Linux, Flatpak components and Bottles maintained, while scheduling application compatibility checks around updates. Our guide to managing Linux security updates explains how to organise that maintenance rather than postponing it indefinitely.
Set a Clear Point for Keeping or Replacing the Setup
A useful Wine installation should survive ordinary work: repeated launches, representative projects, saving, reopening and the output you depend on. Test printing, plugins, login and device access when those belong to your workflow. Do not wait until the deadline to find the untested feature.
If the program needs repeated repairs, depends on unavailable Windows components or fails a required task, stop treating another setting change as the default answer. A native alternative, a virtual machine or access to a Windows system may cost less time.
Wine and Bottles work best as a controlled bridge for an application you still need. Keep that bridge narrow: one clear purpose, a reproducible configuration, sensible file access and a recovery copy that actually restores.