Content tagged GNU/Linux

Simple Wine Workflow

posted on 2014-10-21

For a little while, I've been wanting to write an introduction to Wine. Wine is not an emulator, so do not call it one. Or else, terrible things will happen. Wine is "a compatibility layer capable of running Windows applications on several POSIX-compliant operating systems, such as Linux, Mac OSX, & BSD". It isn't perfect but it works often. You might still have to boot under Windows from time to time but it will help to minimize these. Of course, Wine is free software (as in free speech). Let's see how to use it.


You'll need a few tools. Lets' start with wine.


Civilized Operating Systems

You probably don't have a lot to do: your OS probably already integrate a package manager or port system that alreay includes wine. Just install it. ;)


Mac OSX doesn't come with a serious package manager or port system. However, third party software exist. You can either use Netbsd's pkgsrc, on which you can find OSX tutorials here, or Macports.


Why would you want to do that? Because Wine has a better compatibility list than any individual version of Windows.

May the Force be with you


Winetricks is a script that allows you to get Windows ressources such as libraries, runtimes, fonts, etc. It's very useful if not necessary.

Your package manager or port system might already have a package. If it doesn't you can simply download it here.

Gecko and mono

Those two are Wine's usual way of dealing with the need of Internet Explorer and .NET. Gecko is Mozilla's engine used in its software like Firefox; Mono is an open-source implementation of .NET. There are two wine packages that contain these and are included as packages or ports into distributions, generally with names such as "wine-gecko" and "wine-mono".

You do not need to download these per-se as Wine is able to download them but it's practical to already have them installed.

Basic usage

To launch windows binaries simply call it with wine like this:

wine mySyperSoftware.exe

That's about it. Of couse, things are always more complicated than they should be.

Where it gets complicated

A lot of Windows software require specific libraries, specific registry keys, either the wine implementation of a library or its windows implementation. Often these pre-requisites will conflict, making you unable to use one piece of software once you've configured another. Thankfully, there's a solution.


Wine prefixes or bottles are basically your fake windows installation used by one. They contain your registry, your installed programs, your configuraiton files, etc. The default one is stored in ~/.wine.

How to use another one? It's easy. You need to use the environment variable WINEPREFIX.

Example : WINEPREFIX=/path/to/my/wine/prefix wine mySyperSoftware.exe

To just create a prefix, use the wineboot command.

Example : WINEPREFIX=/path/to/my/wine/prefix wineboot -u (-u is for --update)

You can of course, export this environment variable to make it permanent for the session.

export WINEPREFIX=/path/to/my/wine/prefix

Where to store a prefix.

I'd recommend to either store all your prefixes info a ~/.wine-prefixes folder or to use a naming convention in your home. I usually create ~/.wine-softwareName folders in my home as prefixes. Remember that you do not need to manually create the folders as Wine will create them for you.

For the rest of this article, I will use ~/.wine-example as my example prefix.

64-bit wine

If you are running a 64-bit system, it is likely that your wine installation has been compiled with 64-bit support. Unfortunately, it tends to not be appreciated by the Windows software you'll be using. You will need to you a second environment variable : WINEARCH=win32. If you use prefixes, you just need to precise it at the prefix creation.

WINEPREFIX=~/.wine-example WINEARCH=win32 wineboot -u will create a 32-bit prefix.

Also, make sure you have 32-bit versions of the libs that wine will need, like your graphic card drivers or your sound libraries for instance.


Inevitably, there will come a time, when you'll need to install some libraries. Some of them are harder to install than others. Thankfully, winetricks a a nice wrapper that will make everything easy. I will assume that winetricks is in your PATH, to make the example shorter and more readible. If it's not, just run the script with its path. It has a lot of parameters so take some time to play with it. Here are a few examples of useful commands :

winetricks --help will display some help.

winetricks list-all will display everything that you can install. Use grep to search through it.

For example: winetricks list-all | grep -i directx will look for directx.

winetricks corefonts vcrun6 will install the corefonts and vcrun6 packages.

Of course, make sure that you have set your prefix via the environment variable or else, it will use the default prefix.

A few scripts and advices

Launch scripts

I like to be able to launch my wine programs with a simple command. That's why, I've added to my PATH a ~/.wine-scripts where I keep launch scripts for my programs.

Here's my template:



Variable secion

export WINEPREFIX=/home/reihar/.wine-mySuperSoftware

Always cd into the right folder

cd "/home/reihar/.wine-thief/drive_c/Program Files/Steam/mySuperSoftware"

Finish with the program call

wine mySyperSoftware.exe ~~~

Always check the Appdb

The Wine Application Database or Appdb, is a compatibility repository that contains test results and instructions on how to run software with Wine. It's community-driven so everyone can contribute.

Read test results, howtos, frequent isues and a few comments and you'll have a good idea on what to do.

A few words about mono

I've briefly mentionned mono earlier. Although you can use mono in wine, you might want to try to run .NET applications using mono directly before using wine. It works pretty often.


I don't really have a conclusion. Try using wine. It's cool and relatively simple ;)

Arch i686 container

posted on 2014-04-07

Recently, I've been wanting to build package for my not very powerful eee-pc laptop. I just have one problem: all my computers except this one are use a 64bit architecture instead of a 32bit one. So I needed to make a chroot. So, instead of doing that I decided to play a little with systemd containers. Here is what I did.

Install a 32bit arch in a folder somewhere

I've decided to do that in my home folder. First, I made a copy of my /etc/pacman.conf, called pacman-i686.conf, in my home folder with the architecture explicitely stated as i686. So I've changed this line: Architecture = i686

Then, I've installed the extra/arch-install-scripts package.

After that, I created a folder and used pacstrap to install a basic arch in it using my custom pacman-i686.conf file. I use sudo because I'm lazy but you can do that using your root account, you just need to change your paths accordingly. Also, please disable the multilib repository, it won't work.

sudo pacstrap -C ~/pacman-i686.conf -c -i -d ~/i686 base

The first option, -C ~/pacman-i686.conf will allow you to choose a pacman.conf different than your host's /etc/pacman.conf, the second one -c uses the host's cache instead of the target's so that you can remove it more easily later and managing like the rest of your package cache. The -i option will disable auto-confirmation of packages so that you can choose what you install. And last, the -d option allows you to chose a non-mountpoint directory.

Starting the container

Simply use that command, the same thing about paths, sudo and root stays valid. sudo systemd-nspawn -bD ~/i686

It is now working. Login as root, there is no password. You might now want to install stuff, build packages, etc.

For some weird reason, my guest pacman.conf architecture was set on auto and it tried to install 64bit packages, probably due to my host, be sure to change it to i686. Make sure to synchronise your pacman databses with pacman -Syy to make sure you don't have any x86_64 packages.

Managing the container

The first step we have to do is to symlink the container to /var/lib/container/. Again, paths, sudo, root.

sudo ln -s ~/.i686 /var/lib/container/i686

I had to create /var/lib/container.

Now, you can see your container using machinectl list. Don't mind my prompt.

``-> % machinectl list MACHINE CONTAINER SERVICE i686 container nspawn

1 machines listed.``

You can now do fun stuff. man machinectl

Remember that you need to launch the machine using systemd-nspawn. Like that in the case of our example :

sudo systemd-nspawn -bD ~/i686

Edit: 2014-10-26

You can also use systemctl to launch the machine. Just use sudo systemctl start systemd-nspawn@MyContainer.service, in our case, the service is systemd-nspawn@i686.service. It will start and be listed in machinectl's list. You can also enable the service to start it with your computer.


Mostly Arch's Wiki, pacstrap --help, and man machinectl

Unless otherwise credited all material Creative Commons License by Reihar