wine notes

Running Windows Programs on Linux (20:10), ExplainingComputers, 2017.
Wine Installation (19:58), Chris Titus Tech, 2019.

---

Simplistically, when one wishes to install or run a Windows app in Linux, one can open a terminal and...

$ wine fooapp.exe

This command creates a hidden ~/.wine/ folder (or "bottle" in wine-speak). In the folder is a spurious C drive and an imitation Windows file structure. With such a structure in place, Wine operates fooapp.exe consistent with the app's Windows file and library calls.

However, suppose one has more than one Windows app? Perhaps an older Windows app that ran best under WindowsXP, as well as newer Windows apps which run best on Windows10. The single ~/.wine bottle folder can be adjusted to match various Windows applications, but not without slowed performance and/or occasional errors. I wanted a way to reliably run any number of Windows applications with reasonably good performance.

application-level bottles

After reading and viewing several vids¹, my solution was to create a Wine bottle for each Windows application I use. A per-application bottle approach is not unwieldy if a person takes the time to keep each bottle lean, and it nearly ensures each Windows app will run predictably. Further, the subfolders for the Wine bottles can be placed into an unhidden directory, eg. ~/wine, making the entire configuration transparent and comprehensible.

configuring

For Wine installation, there were only three...

# pacman -S wine winetricks zenity

Zenity is needed for the winetricks GUI and wine is obviously the emulator. Think of winetricks as the Wine installation aid. I tried PlayOnLinux, but it was always coming-up short on DLL's and sending confusing errors. Some ppl will probably do a MONO installation as well, but I just do whatever version of NET is needed by the Windows app itself, in that bottle.

launching

Suppose I have some Windows app, "fooapp.exe". As noted above, I would configure a bottle for it, eg ~/wine/fooapp. To launch, I want to see any spawned errors and possibly avoid the generic 64-bit Wine version noted at the top of this post. A terminal launch can solve both...

$ WINEARCH=win32 WINEPREFIX=~/wine/fooapp wine fooapp.exe

The two environment setting commands keep Wine locked into the application's bottle and at 32bits. From the terminal I can watch for errors and relaunch winetricks to add additional DLL's. Rinse and repeat.

Once I have trouble-shot the application DLL's and its launch parameters, I'm done with the terminal; I'll want to create a menu item for easy launch. For me, this was a problem. My Windows Manager is IceWM, a great WM, but which only allows a single command per menu item. I needed to set environmental variables also. The only way to do this was with a script, as there was no lightweight application for multiple command menus.

$ nano fooapp.sh
#!/bin/bash
WINEARCH=win32 WINEPREFIX=~/wine/fooapp wine ~/wine/fooapp/drive_c/fooapp.exe
exit 0

$ chmod +x fooapp.sh
$ ./fooapp.sh

...and then in my menu, I have...

$ nano /home/foo/.icewm/windows
prog foo foo sh "/home/foo/wine/fooapp.sh"

shutdown

If Wine crashes, I always run $wineserver -k, just to be sure I've killed all Wine windows and memory usage.

NET

Wine installation will prompt to install mono, so NET operations will work.

safety

Windows stuff is susceptible to viruses, and Wine is not a bona fide sandbox.

1. there's no reason to run Wine as root, and I make a special effort to avoid mistakenly doing so.
2. when exiting a Windows app, I can use htop to be sure all processes have been killed.