How To Install Wine on Kali Linux

Wine lets a Linux desktop run Microsoft Windows binaries directly, with no virtual machine and no emulation layer in the way. On Kali Linux that matters more than it does on a general purpose desktop, because a good share of the tooling an analyst gets handed still ships only as a Windows executable, sitting alongside the native scanners you would already be running such as Nessus on Kali. The catch is that almost every Wine guide you will find still opens by telling you to enable the i386 architecture and pull in a few hundred 32-bit libraries. On current Kali that step is no longer needed, and this guide shows the route that skips it. Everything below was run on Kali rolling 2026.3 with kernel 7.1.5 in September 2026, against WineHQ stable 11.0.

Original content from computingforgeeks.com - post 76084

Why not just install Kali’s own wine package

Kali carries a wine package in its own archive, so the obvious move is a one line install. Check what it offers first:

apt-cache policy wine

The candidate comes from Kali’s repackaged Debian source, and it trails the current stable release by a full major version:

wine:
  Installed: (none)
  Candidate: 10.0~repack-11
  Version table:
     10.0~repack-11 500
        500 http://http.kali.org/kali kali-rolling/main amd64 Packages

That gap is the whole reason to add the vendor repository. The jump between those two lines is not a routine bug-fix bump either. The current stable branch completed the WoW64 rework and dropped the separate wine64 loader that older guides still tell you to check. Be careful how you read the WoW64 part, though: finishing that work made an i386-free package possible, it did not make every build i386-free. Only one of the WineHQ suites actually ships it that way, which is the section after next. Installing the archive package first and adding WineHQ later leaves you reconciling two package sets, so pick the repository before you install anything.

Confirm your Kali release

Which WineHQ suite you point at depends on the Debian branch your Kali install tracks, so start by reading the release file. If you are setting the machine up from scratch, work through installing Kali Linux first and come back here:

cat /etc/os-release

A rolling install reports the snapshot it was built from and the kali-rolling codename:

PRETTY_NAME="Kali GNU/Linux Rolling"
NAME="Kali GNU/Linux"
VERSION_ID="2026.3"
VERSION="2026.3"
VERSION_CODENAME=kali-rolling
ID=kali
ID_LIKE=debian

Bring the system up to date before adding a third party repository. A stale package list is the most common cause of unresolvable dependencies later on, and keeping a rolling install current avoids most of the dependency trouble people blame on WineHQ:

sudo apt update
sudo apt full-upgrade -y

Reboot if that pulled a new kernel. Do not bother with the /var/run/reboot-required test you may have copied from an Ubuntu guide, because nothing on Kali ever writes that file. It comes from Ubuntu’s update-notifier-common, which is not part of any Kali metapackage, so the check silently reports that no reboot is needed no matter what was upgraded.

Add the WineHQ repository on Kali Linux

WineHQ signs its Debian packages with a single key that every suite shares. Fetch it into the keyring directory that APT reads. There is no need to install gnupg2 first, whatever older guides say: a deb822 source with a Signed-By line is verified by gpgv, which APT already depends on, and the gnupg2 package is now just a transitional dummy.

sudo apt -y install wget
sudo mkdir -p /etc/apt/keyrings
sudo wget -O /etc/apt/keyrings/winehq-archive.key https://dl.winehq.org/wine-builds/winehq.key

Now the suite. Kali rolling tracks Debian testing, and WineHQ publishes a matching suite for it named after the current testing codename. That is the one to use. The Debian stable suite also exists and its stable branch will install, but on a current Kali its development and staging builds are compiled against an older ffmpeg and will refuse to resolve. Pull the sources file for the testing suite:

sudo wget -NP /etc/apt/sources.list.d/ https://dl.winehq.org/wine-builds/debian/dists/forky/winehq-forky.sources

The file it drops in is a deb822 stanza pointing at the suite and referencing the key you just saved:

Types: deb
URIs: https://dl.winehq.org/wine-builds/debian
Suites: forky
Components: main
Architectures: amd64 i386
Signed-By: /etc/apt/keyrings/winehq-archive.key

Refresh the package lists so APT picks the new source up:

sudo apt update

No Kali branch tracks Debian stable, so the Debian stable suite is a fallback rather than an alternative. Do not reach for it pre-emptively. The stable branch built for the testing suite asks very little of the system and will install on an old snapshot too, so switch only if APT actually refuses with a library it cannot satisfy. If that happens, swap forky for trixie in both the URL and the resulting filename, and enable the i386 architecture as well, because the stable suite still splits its packages by architecture and will not resolve without it:

sudo dpkg --add-architecture i386
sudo apt update

WineHQ also publishes a bookworm suite, but that is the oldstable build and there is nothing to gain by choosing it.

One optional tidy-up if you stayed on the testing suite. The sources file WineHQ ships lists Architectures: amd64 i386, so APT downloads an i386 package index on a machine that will never install an i386 package from it. Edit the file and cut i386 from that line to skip the extra fetch on every update. This is unrelated to the dpkg architecture above, and the testing route needs neither.

Skip the i386 architecture

This is the step almost every other guide still insists on, and on current Kali it is dead weight. Check what foreign architectures dpkg knows about:

dpkg --print-foreign-architectures

On a stock install that prints nothing at all, and it can stay that way. The current stable package from the testing suite is a single amd64 build that carries the 32-bit Windows modules inside it, so there are no i386 library dependencies to satisfy. Compare the two package shapes:

WineHQ suite	Package layout	Needs i386 architecture	Packages pulled	Disk used
Debian testing (forky)	one amd64 package	No	5	1,536 MB
Debian stable (trixie)	metapackage plus separate amd64 and i386 halves	Yes	256	2,096 MB

Both routes run the same 32-bit Windows binaries. The difference is that the stable suite still splits the build the old way and drags in roughly two hundred and fifty i386 libraries to do it. If you have already run dpkg --add-architecture i386 on this machine nothing breaks, you simply carry packages you no longer need.

Install Wine on Kali Linux

WineHQ ships three branches and they conflict with each other, so installing one removes any other that is already present. Stable is the branch to pick unless you have a specific reason not to:

sudo apt install --install-recommends winehq-stable

On a clean Kali desktop the transaction is small. Five packages, and not one of them is an i386 library:

Installing:
  winehq-stable

Installing dependencies:
  libasound2-plugins  libcapi20-3t64  libxkbregistry0  wine-stable

Recommended packages:
  libtiff5

Summary:
  Upgrading: 0, Installing: 5, Removing: 0, Not Upgrading: 2
  Download size: 228 MB
  Space needed: 1,536 MB / 61.6 GB available

The other two branches are there when you need them, but pick one, do not paste both. The development branch tracks the biweekly snapshots:

sudo apt install --install-recommends winehq-devel

Staging layers experimental patches on top of the development branch, and installing it removes whichever of the other two you already had:

sudo apt install --install-recommends winehq-staging

Confirm what actually landed:

wine --version

A single version string comes back, and it should match the stable release WineHQ currently publishes:

wine-11.0

There is no second command to run against a wine64 binary, because that loader was removed. If an older tutorial has you checking it, you will get wine64: command not found and nothing is wrong with your install. One wine command now reads the architecture out of the executable and dispatches accordingly. The binary on your path is a symlink into the vendor tree:

readlink -f /usr/bin/wine

Everything WineHQ installs lives under one directory, which keeps it cleanly separated from anything Kali’s own archive might drop in later:

/opt/wine-stable/bin/wine

Create the Wine prefix and open winecfg

A prefix is the fake Windows installation Wine builds under your home directory. Nothing runs until one exists, and the first command you run creates it. Start the configuration tool from a desktop session rather than over SSH:

winecfg

Before the configuration window appears, Wine offers to fetch its Mono runtime. That package is what makes .NET applications work, and unless you know none of your software touches .NET it is worth accepting. Click Install and Wine downloads roughly eighty megabytes into ~/.cache/wine.

Once Mono is in place the configuration window opens. The Applications tab is the one worth knowing: the Windows version set there is what every program in this prefix believes it is running on, and the default is Windows 10. Applications that refuse to start are often just checking that value.

The About tab is the quickest confirmation that the vendor build is the one in use, since it prints the same release string the command line reported.

Look at what the prefix actually contains, because the layout tells you the WoW64 story directly:

ls ~/.wine/drive_c

A Program Files (x86) tree is already there, on a machine with no 32-bit host libraries anywhere:

ProgramData
Program Files
Program Files (x86)
users
windows

So is the 32-bit system directory that serves it:

ls ~/.wine/drive_c/windows | grep -E 'sys(tem32|wow64)'

Both are present, which is the whole point. A 64-bit prefix carrying a populated syswow64 beside system32 is what lets 32-bit Windows binaries run with nothing 32-bit installed on the host:

system32
syswow64

All of that costs about two gigabytes of disk:

du -sh ~/.wine

The figure grows once you install applications into it:

1.9G	/home/kali/.wine

Do not try to force a 32-bit prefix with WINEARCH=win32. That mode is deprecated and unsupported under the current architecture. It still creates a directory, then fails to start the explorer process and cannot load Vulkan, which produces a prefix that looks valid and misbehaves in ways that are hard to trace back.

Turn on NTSync for faster Windows synchronization

NTSync is a kernel driver that implements Windows synchronization primitives natively instead of emulating them in userspace, and Wine uses it automatically when it is present. Kali’s kernel builds it as a module rather than compiling it in, which catches people out. Check whether your kernel offers it at all:

grep -i ntsync /boot/config-$(uname -r)

The m is the important part. It means the driver exists but is not loaded:

CONFIG_NTSYNC=m

Because it is not loaded, the usual check that guides tell you to run reports a missing device even though the kernel supports it perfectly well. Load the module and the device node appears:

sudo modprobe ntsync
ls -l /dev/ntsync

A character device owned by root and readable by everyone is what you want to see:

crw-rw-rw- 1 root root 10, 261 Sep 18 05:22 /dev/ntsync

That lasts until the next reboot. To make it permanent, drop the module name into a load file:

sudo vim /etc/modules-load.d/ntsync.conf

The file needs one word in it:

ntsync

Run your first Windows application

Notepad++ makes a good first test because its default installer is a genuine 32-bit executable, which is exactly the case people assume needs a separate 32-bit setup. Fetch the current release:

mkdir -p ~/Downloads && cd ~/Downloads
NPP_VER=$(curl -s https://api.github.com/repos/notepad-plus-plus/notepad-plus-plus/releases/latest | grep '"tag_name"' | cut -d '"' -f4 | sed 's/^v//')
wget "https://github.com/notepad-plus-plus/notepad-plus-plus/releases/download/v${NPP_VER}/npp.${NPP_VER}.Installer.exe"
file "npp.${NPP_VER}.Installer.exe"

That last line is the point of the exercise. The project also publishes a 64-bit build, under a filename carrying an x64 marker, and the plain one is genuinely 32-bit:

npp.8.9.8.Installer.exe: PE32 executable for MS Windows 4.00 (GUI), Intel i386, Nullsoft Installer self-extracting archive, 5 sections

Hand it to Wine the same way you would run any other program. Stay in the same shell, because NPP_VER does not survive a new terminal:

wine "./npp.${NPP_VER}.Installer.exe"

A language chooser appears first, then the familiar setup wizard. Work through it as you would on Windows. The components page is worth pausing on, because ticking Create Shortcut on Desktop is what gets you a launcher on the Kali desktop rather than a program you can only start from a terminal.

Leave Run Notepad++ ticked and the editor starts as soon as you click Finish. A 32-bit Windows application is now running on a Kali desktop that has no 32-bit libraries installed, which is the WoW64 rework doing its job.

Once an application is installed you can start it again without touching the installer, by pointing Wine at the executable inside the prefix:

wine "C:\\Program Files (x86)\\Notepad++\\notepad++.exe"

Where Wine puts menu entries and shortcuts

A fresh Wine install adds nothing to the Kali applications menu, and that is deliberate rather than a fault. Its own desktop file is marked hidden:

grep NoDisplay /usr/share/applications/wine.desktop

The entry exists only so that the desktop knows which program opens an .exe or .msi file:

NoDisplay=true

Menu entries appear once you install something. Wine writes them into your home directory, never system wide, so a second user account on the same machine sees none of it:

ls ~/.local/share/applications/wine/Programs/
ls ~/.config/menus/applications-merged/

Alongside the program’s own entry, Wine drops a set of wine-extension-*.desktop files that register Windows file types, a pair of directory files that build the Wine submenu, and a desktop shortcut if you asked for one:

/home/kali/.local/share/applications/wine/Programs/Notepad++.desktop
/home/kali/.local/share/desktop-directories/wine-Programs.directory
/home/kali/.local/share/desktop-directories/wine-wine.directory
/home/kali/.config/menus/applications-merged/wine-Programs-Notepad++.menu
/home/kali/Desktop/Notepad++.desktop

Deleting a launcher only removes the launcher. The application stays in the prefix, which is why the next section matters.

Install winetricks on Kali Linux

Winetricks is the helper you reach for when an application needs a Windows runtime, a font pack or a DLL override. Kali used to carry it and dropped it from the rolling archive in March 2026, and the WineHQ repository never packaged it, so apt install winetricks now comes back empty on both counts. Take it from upstream instead, which is the project’s own recommended route since the script updates far more often than any distribution package:

wget -O /tmp/winetricks https://raw.githubusercontent.com/Winetricks/winetricks/master/src/winetricks
sudo install -m 0755 /tmp/winetricks /usr/local/bin/winetricks

Check that it runs and reports a build date:

winetricks --version

The version string is a date stamp rather than a release number:

20260125-next

Running winetricks with no arguments is supposed to open a menu driven interface, and on a stock Kali install it will not, because the script needs zenity or kdialog to draw that menu and Kali ships neither. Most of its verbs also need cabextract to unpack Microsoft redistributables, which is likewise missing. Install both before you reach for the menu:

sudo apt install -y zenity cabextract

With zenity in place the menu opens as it should, starting with a prefix chooser:

Expect a warning from winetricks itself on every run. It flags the current WoW64 mode as experimental, which is worth knowing if a verb behaves oddly, because the script is telling you it has not been widely tested against this prefix layout:

warning: You appear to be using Wine's new wow64 mode. Note that this is EXPERIMENTAL and not yet fully supported. If reporting an issue, be sure to mention this.

Those two cover the menu and the Microsoft redistributables. Upstream’s full list for Debian systems also names 7zip, unzip and unrar-free, so add them if a verb complains it cannot unpack an archive. Many winetricks verbs still install 32-bit runtimes, and those land inside the prefix rather than on the host, so they work without the i386 architecture enabled.

Remove an application, reset the prefix or uninstall Wine

Wine has its own Add/Remove Programs, and it is the correct way to take a Windows application back out because it runs the program’s real uninstaller:

wine uninstaller

The list covers everything registered in the prefix, including the Mono runtime Wine installed for you. The publisher column makes it easy to tell your own software apart from Wine’s own components.

To throw away everything and start over, stop the Wine server first so nothing is holding files open, then delete the prefix:

wineserver -k
rm -rf ~/.wine

The next Wine command rebuilds a clean prefix from scratch. Keep ~/.cache/wine if you want to avoid downloading Mono again. Removing Wine itself is an ordinary package operation. Match the package names to the branch you installed, so wine-devel or wine-staging in place of wine-stable:

sudo apt purge winehq-stable wine-stable
sudo apt autoremove

Then drop the repository. The filename matches the suite you added, so use winehq-trixie.sources if that is the one you fetched. Delete the key only if this was your one and only WineHQ source, since a second sources file would still be pointing at it:

sudo rm -f /etc/apt/sources.list.d/winehq-forky.sources
sudo rm -f /etc/apt/keyrings/winehq-archive.key
sudo apt update

Package removal leaves your data and everything Wine wrote into your home directory alone, which means a set of launchers that now point at nothing. Clear those out too, and take the prefix with them if you want the disk space back:

rm -rf ~/.wine ~/.cache/wine
rm -rf ~/.local/share/applications/wine ~/.local/share/desktop-directories/wine-*.directory
rm -f ~/.local/share/applications/wine-extension-*.desktop
rm -f ~/.config/menus/applications-merged/wine-*.menu
rm -f ~/Desktop/Notepad++.desktop
sudo rm -f /usr/local/bin/winetricks

If you took the Debian stable route earlier and enabled the i386 architecture for it, that is a separate undo:

sudo dpkg --remove-architecture i386
sudo apt update

That only works once every i386 package is gone. While any remain, dpkg refuses outright:

dpkg: error: cannot remove architecture 'i386' currently in use by the database

Only fully installed packages hold the architecture, so filter on those rather than reading the whole list. Packages left in the removed-but-not-purged state still show up in dpkg -l and are not what is blocking you:

dpkg -l | awk '$1 ~ /^i/ && $4 == "i386"'

Purge whatever that prints, then run the architecture removal again.

Errors you are most likely to hit

The failures below are the ones that come up repeatedly, and none of them mean a broken install.

could not load kernel32.dll, status c0000135

This one is almost always self inflicted. Interrupting the first run while Wine is still laying down the prefix leaves a half built directory, and every later command fails against it:

0024:err:environ:run_wineboot boot event wait timed out
wine: could not load kernel32.dll, status c0000135

There is nothing to repair inside it. Kill the server, remove the prefix and let the next command build a fresh one.

Application tried to create a window, but no driver could be loaded

Wine needs a display server. Running winecfg or any graphical program from a plain SSH session gives you this:

0150:err:winediag:nodrv_CreateWindow Application tried to create a window, but no driver could be loaded.
0150:err:winediag:nodrv_CreateWindow L"Make sure that your display server is running and that its variables are set."

Run it from the Kali desktop. Forwarding with ssh -X also works, but only if the Kali box has xauth installed and its sshd_config still has X11Forwarding yes. Kali ships SSH disabled by default, so on a fresh install there is usually nothing to forward through yet.

Usage: wine PROGRAM

Typing wine on its own prints its usage text, and PROGRAM there is a placeholder, not a command you are meant to type. Wine expects the path to a Windows executable as its first argument:

Usage: wine PROGRAM [ARGUMENTS...]   Run the specified program
       wine --help                   Display this help and exit
       wine --version                Output version information and exit

winehq-devel refuses to install

If APT complains that a dependency has no installable candidate and names an ffmpeg library, you are pointed at the Debian stable suite on a current Kali. The stable branch there installs fine, because it carries no ffmpeg dependency at all, but the development and staging builds do, and Kali has moved on to a newer ffmpeg than they were compiled against. Replace the sources file with the testing suite and both branches resolve normally.

Related guides

Wine works the same way across the Debian family, but the repository suite and the package split differ enough between distributions to be worth their own walkthroughs:

• Install Wine on Debian
• Install Wine on Ubuntu
• Install Wine on Rocky Linux and AlmaLinux
• Run Windows apps with Winetricks

The short version for Kali is that the vendor repository is still worth adding, but the ritual around it has shrunk. Point at the suite that matches the Debian branch your install tracks, install the stable branch, and leave the i386 architecture alone.