Wine prefixes explained: separate Windows environments on Linux

One game needs a different setting from another. If they share a Wine environment, a change can affect both. Separate prefixes help keep registry settings, installed components and virtual Windows files organized.

This article extends my Linux gaming guide, which covers the roles of Steam, Proton and Lutris. Here we focus on a single prefix and test Wine's own configuration interface without running an unfamiliar game installer.

What is a Wine prefix?

A prefix is the directory Wine uses to maintain its Windows environment. The usual default is ~/.wine. Setting WINEPREFIX to another absolute directory chooses a different environment for an invocation.

Wine is not a complete Windows operating system inside a virtual machine. It provides Windows interfaces for programs. The VM tutorial describes the different architecture of a guest operating system.

Separate the prefix from the Wine version

The prefix stores settings and installed files. The Wine version, often called a runner, is a separate choice. A directory's existence does not tell you which version last used it.

Lutris can manage a prefix and runner per game. Steam/Proton maintains its own compatibility data. Avoid testing a managed environment with an arbitrary system Wine version. Switching runners can update files and settings; back up important data before experimenting.

The following low-impact exercise needs installed Wine and a graphical Linux session. Check the version:

wine --version

Choose a separate test environment

First check whether ~/wine-tutorial already contains your work. Choose another name if needed. Using a new directory avoids your normal ~/.wine environment.

Launch the configuration interface with an explicit prefix:

env WINEPREFIX="$HOME/wine-tutorial" winecfg

env sets the variable only for this invocation and its child processes. This command works from fish too, without permanently changing shell settings. The path is absolute because $HOME expands to the full home-directory path.

Wine creates its directory structure for a new environment. Depending on the package and version, prompts for additional components or downloads may appear. The configuration exercise needs no game account. Read additional installation proposals before accepting them.

Change one setting and undo it

winecfg offers areas including applications, libraries, graphics and drives. Begin with one understandable display setting, such as a virtual desktop if your version offers it. Record the original value.

Apply the change, close the window and run the same command again. Expect it to remain in the test prefix. Then restore the original value. Another prefix does not receive that change automatically.

Choosing a Windows version specifies compatibility behaviour; it does not install that Windows release. A DLL override is also a specific compatibility decision rather than a universal speed improvement. Avoid installing multiple runtimes and overrides at once when investigating a problem.

Inspect files and drive mappings

After first launch, inspect two common directories:

ls -ld ~/wine-tutorial/drive_c ~/wine-tutorial/dosdevices

drive_c contains virtual Windows directories. dosdevices may also map parts of your real Linux filesystem. A visible Windows drive is therefore not necessarily isolated storage.

This establishes an important boundary: a prefix is not a security sandbox. Malicious software can access files allowed by your user permissions. Use trusted programs; deliberately examining unknown software needs a different isolation arrangement.

Do not blindly change architecture or filesystems

A prefix's architecture is chosen at creation. Setting WINEARCH later does not simply convert an existing environment between 32 and 64 bits. Available configurations depend on your Wine packages and their WoW64 implementation.

The first exercise uses the package default. If a game specifically requires another architecture, create a suitable independent environment following its current installer or runner guidance. Old win32 instructions do not apply automatically to every modern Wine package.

A prefix also needs appropriate filesystem behaviour and permissions. Problems on additional drives can involve mounts, case sensitivity or links. My storage guide explains the layer underneath the game environment.

Back up a prefix and investigate problems

Close all programs using the environment. If needed, wait for its Wine processes to finish:

env WINEPREFIX="$HOME/wine-tutorial" wineserver --wait

This waits; it does not close an open game for you. Then back up the whole prefix to a new, unused destination. Important saves may live outside the prefix or be synchronized by a launcher, so verify their actual locations.

Record the prefix path, runner version, launch command and last change during diagnosis. A fixme line alone does not establish the cause of a crash. Compare behaviour before and after one change, and read surrounding output near the failure.

Use Lutris and return to normal settings

In Lutris, inspect the game's configured prefix path and runner. Record original values and preserve important data before changing them. A separate test installation should receive its own game/prefix entry so the existing setup remains understandable.

Close winecfg when finished. A normal Wine invocation without our env selection returns to its regular environment. Keep the exercise directory while you need its contents. Remove it only after inspection, avoiding blanket deletion of every prefix.

References

• Debian's Wine manual: WINEPREFIX and environment settings.
• winecfg and wineserver.
• Lutris documentation: runners and game setup.
• Proton project: Steam compatibility environments.

References checked on 8 October 2026. The test prefix is a teaching example, rather than a compatibility promise for a particular game.