Run Windows applications with Wine

Synopsis #

Wine translates Windows application interfaces into host operating-system interfaces. It is not a Windows virtual machine and does not provide a Windows kernel. Compatibility therefore depends on the application’s architecture, installer, libraries, graphics and audio requirements, copy protection, and use of kernel drivers.

Start with one nonessential application in a dedicated Wine prefix. A prefix separates application files and configuration, but it is not a security sandbox: a program running through Wine has the files, devices, display, and network access of the FreeBSD account that started it. Untrusted Windows software needs a separate operating-system boundary rather than another prefix.

Qualify the application first #

Record the exact application and installer version, then inspect the executable:

$ file setup.exe

PE32 normally identifies a 32-bit executable; PE32+ normally identifies a 64-bit executable. A nominally 64-bit application can still have a 32-bit installer or helper, so successful inspection of the main executable does not prove that a 64-bit-only Wine installation is sufficient.

Check the Wine Application Database and the application’s own requirements for the same release. Treat reports for Linux distributions as compatibility evidence, not as FreeBSD package instructions. Reject Wine as the initial approach when the workload requires:

• a Windows kernel driver, anti-cheat driver, or device-management driver;
• a vendor-supported, exact Windows environment;
• reliable operation of an important business application that has not been qualified under Wine;
• hardware or copy-protection behavior that Wine does not implement;
• meaningful containment of untrusted code.

A Windows virtual machine or a remote Windows host is the clearer boundary in those cases. Review Choose a jail or a bhyve virtual machine before assuming that a jail can supply Windows kernel behavior.

Choose the FreeBSD Wine implementation #

Install packages from one coherent repository policy. The stable package is the usual starting point:

# pkg install wine

The current stable port supports amd64 and i386 builds. On amd64 it installs a direct 64-bit loader and a wrapper that can use a separate i386 package root for 32-bit Windows components. Development Wine 11.14 and later can instead build Wine’s combined i386,x86_64 architecture on amd64. wine-devel conflicts with wine; the two must not be mixed in one installation or prefix merely to work around an unidentified failure.

Use Choose quarterly or latest packages and Choose packages, ports, or poudriere before changing branches or building a private variant.

FreeBSD 14.4 on amd64 #

For a confirmed 64-bit-only application, the installed wine64.bin command bypasses the stable port’s wrapper and avoids requiring the i386 component. The wine64 wrapper can still inspect the separate i386 package root. For an application with any 32-bit executable, install the matching i386 Wine and graphics packages through the helper supplied by the stable port:

$ /usr/local/share/wine/pkg32.sh install wine mesa-dri

Run this helper as the desktop account, not as root. It creates an i386 package root under $HOME/.i386-wine-pkg by default. The wrapper checks that the 32-bit and 64-bit Wine versions match; update both sides together when the host package changes.

FreeBSD 15 on amd64 #

FreeBSD 15 does not publish an ordinary FreeBSD:15:i386 package set. The current stable Wine port consequently offers two explicit choices when 32-bit support is needed:

$ /usr/local/share/wine/pkg32.sh --old install -r FreeBSD-ports wine mesa-dri

The --old path installs the current helper’s FreeBSD 14 i386 packages beneath the account’s private package root. It is a compatibility bridge, not a native FreeBSD 15 i386 repository. The alternative is to build a matched amd64 and i386 package set with poudriere as described by the installed Wine wrapper. Preserve identical Wine versions across the two package roots.

wine-devel 11.14 and later from a sufficiently current Ports tree or latest package branch use Wine’s newer combined WoW64 architecture on amd64 and do not use the stable port’s split wrapper. A quarterly repository can still carry an earlier development version. Check the repository version and installed package message before relying on the combined layout:

$ pkg rquery %v wine-devel
$ pkg info -D wine-devel

It is a development release and should be chosen only when a recorded application requirement or fixed defect justifies the different maintenance track. Recheck these details before switching because this transition is still active.

Do not copy a FreeBSD 14 package into the host package database or force an ABI override for the whole system. The supplied helper deliberately confines its i386 packages to a separate root.

Create one prefix per application #

Keep application-specific installers, registry changes, DLL overrides, and compatibility workarounds separate:

$ mkdir -p "$HOME/.local/share/wineprefixes"
$ WINEPREFIX="$HOME/.local/share/wineprefixes/example" winecfg
$ WINEPREFIX="$HOME/.local/share/wineprefixes/example" wine /path/to/setup.exe

Use wine64.bin instead of the wine wrapper only for a confirmed 64-bit-only application under the stable amd64 port, including the corresponding winecfg and diagnostic invocations. Always set the same WINEPREFIX when configuring, installing, and running that application.

Record the Wine package version, prefix path, executable architecture, required overrides, and test result. A disposable prefix is cheaper to reconstruct than a shared prefix containing unrelated applications and contradictory workarounds.

Treat DLLs and helper recipes as code #

Wine’s built-in DLLs are the default. Add a native Windows DLL only when a specific application requirement and a lawful, trusted source are known. The DLL must match the expected architecture and application version. Configure an override in the application’s prefix rather than replacing Wine files globally.

winetricks can automate fonts, runtimes, DLLs, and registry changes, but every verb changes the prefix and can download third-party material. Review the selected verb, source, and license before running it. Do not let several prefix-management tools modify the same prefix without a reproducible record.

A native DLL does not turn Wine into Windows and does not provide a missing kernel driver. Random DLL download sites add an unreviewed executable supply chain and should not be used.

Qualify graphics and audio on the host #

Establish native graphics and audio operation before diagnosing Wine. Windows graphics drivers must not be installed in a Wine prefix; Wine uses the FreeBSD graphics stack.

Review Choose and check a graphics driver and Choose Xorg or Wayland . Then use winecfg in the application prefix to confirm display integration and an audio test. If native audio already fails, follow Diagnose audio output or input before changing Wine libraries.

Games and accelerated applications add Vulkan, Direct3D translation, controller, launcher, and anti-cheat requirements. Confirm each layer separately. A compatibility report for a game does not prove that a particular FreeBSD GPU, driver, or compositor supports the same path.

Diagnose one boundary at a time #

Capture a baseline without changing the prefix:

$ uname -mKU
$ pkg info wine
$ file /path/to/program.exe
$ WINEPREFIX="$HOME/.local/share/wineprefixes/example" wine --version
$ WINEPREFIX="$HOME/.local/share/wineprefixes/example" wine /path/to/program.exe

If the stable wine wrapper reports a missing or mismatched 32-bit component, follow the wrapper’s release-specific pkg32.sh instruction rather than installing the retired i386-wine package. If the loader starts but the application fails, preserve the terminal output and compare a clean prefix before adding overrides:

$ WINEPREFIX="$HOME/.local/share/wineprefixes/clean-test" winecfg

Interpret failures by layer:

Do not run Wine as root to bypass a permission error. That gives the Windows process root’s host access without supplying the missing Windows behavior.

Primary references #

• FreeBSD Handbook: Wine
• FreeBSD ports: stable Wine port
• FreeBSD ports: stable Wine 32-bit package helper
• FreeBSD ports: stable Wine amd64 wrapper
• FreeBSD ports: development Wine port
• Wine User’s Guide
• Wine FAQ: application sandboxing
• Wine Application Database
• file(1)
• pkg(8)