Install and run Windows applications
How do I install and run Windows applications downloaded from a website? Windows applications do not run natively on Linux, but can be run using Wine. When downloading these applications from a webpage, I will have a .exe or .msi installer in my Downloads directory. What are the next steps to install these on Linux? How do I then run the installed application? How do I add it to my applications list readily available with a mouse click in my desktop environment?[1] I should be able to use the application as if it is any other native application on my system.
Applications downloaded from a webpage may include their own built-in updater. Will that work as intended (automatic)?
-
Having to resort to the Terminal to open the application, is not sufficient. It needs to be available when I search in my app launcher list, or open the GUI app list. ↩︎
2 answers
You are accessing this answer with a direct link, so it's being shown above all other answers regardless of its score. You can return to the normal view.
Installation
At least in KDE Plasma all you really need is to have the .exe files associated with wine. Right click > Open with in Dolphin will do the trick.
Once you got that covered, the installer can be run by just doubleclicking the exe, just like in windows. It will be installed to your default wine prefix (which might not be what you want. One prefix per program would be a more principled approach.)
Wine will also map windows desktop entries to freedesktop .desktop files. Your desktop environment should pick these up.
Tldr: Given a working wine and desktop environment, it should just work.
Updaters
I don't think that wine will install any daemons to your linux. I guess you could manually create e.g. a systemd service to run an updater with wine, but I would recommend against it. Many windows programs will anyway check for updates on launch and nag you about an outdated version.
Or just sign up to a release mailing list.
1 comment thread
You can use Wine, or a VM. With a VM, it's pretty straightforward - install Windows in the VM, and then run the program as you would normally inside the VM.
With Wine, the "basic" way (which you shouldn't do!) is to run wine evil.exe in a terminal. By default, this uses the Wine prefix under something like ~/.wine, opens your whole filesystem to the Windows program, and often leads to littering your desktop and/or file associations with crap from Windows, all of which is IMO undesirable. You should at least create a separate Wine Prefix, configure it with winecfg and set the WINEPREFIX environment variable.
If you're not thoroughly familiar with Wine, your head might be spinning at this point. The good news is that you don't have to do these steps by hand, people have written utilities for it. I like using Wine Bottles - this has a GUI where you can select Windows programs and run them easily. It also has the important benefit of sandboxing the Windows programs so they can't just have full access to your entire hard drive.
Wine creates a fake C: drive for Windows programs, which is really just a folder inside the Wine prefix. You can run an installer like any other program, but you will have to choose where to install. Usually, it's more convenient to install outside the prefix, that way you can easily run the installed program with other prefixes (useful for troubleshooting). Usually, your actual drive (/) will show up as Z: in Wine, you can go from there. Keep in mind that with Bottles sandboxing, the root at Z: might be a fake one, and not the real files of your /, unless you specifically permit Bottles to share some part of your drive with Wine programs.
After you run the installer, the actual program's EXE should be created somewhere. You then find it, and run that with Wine, and hopefully everything now works. In Bottles, you can create a shortcut to make it easier to find later. Bare Wine and other helpers like Lutris have their own shortcut mechanism as well, but I don't know how it works.
A lot of Windows programs don't like it if the "working directory" is not just right. The easy solution is to make sure you cd into the directory of the executable when running, instead of doing wine /full/path/to/the/binary.exe. Lutris etc have a special configuration field where you can specify a working directory.
Occasionally you'll run into a program that fails when installed on Z:, but works on C:. IMO the best strategy is to try installing on Z: first, and if it fails, then try C: as one of the troubleshooting steps. If you install everything on C:, you end up with a lot of unnecessary extra directory levels, which is annoying.
Many Windows installers also want to install dependencies like C++ Runtime, .NET runtime, DirectX, etc. Be careful with these because they don't always work exactly right in Wine - these are system-level things that sometimes conflict with the parts that Wine abstracts away. If possible, it is better to install dependencies with winetricks rather than the official Windows installer. In Bottles, there is an easy to use GUI for this. When a dependency has not been added to winetricks/Bottles yet, I have had decent luck just downloading the installer from Microsoft's site and running in Wine (it has to be the same prefix as the program that needs it). But if you do it often you are likely to start running into annoying problems.
3D-heavy programs like games usually rely on DirectX. Vulkan is an open source replacement for this. I've seen a good amount of cases where a game crashes on launch, is slow, has artifacts with DirectX on Wine. But with Vulkan it runs much better, even though Vulkan is 3rd party and DirectX is official. IMO using Vulkan by default, and falling back to DX as a troubleshooting step, is more efficient.
There are also multiple flavors ("runtimes") of Wine these days. The big ones are Proton from Valve, Glorious Eggroll (based on proton) and Soda. I like to use Soda instead of vanilla Wine by default, since some programs that crash on vanilla seem to not crash on Soda. The Glorious Eggroll version of Proton is like the nuclear option for games, almost everything will run with it. But most of my games run with Soda already these days, so I don't usually bother with GE except for the really annoying ones like Total Wars (notorious for being hard to run on Linux). Proton is useful when running through Steam, since you then get other benefits of Steam as well, like Steam Input. Switching runtimes is much easier with a helper like Bottles or Lutris.
1 comment thread