While Linux has one of the largest software catalogues on the planet, there are still many software applications which are either only available for Windows or are only possible to make on Windows. For users, it means that they will miss out on some of their favourite software (for example, Microsoft Office and a lot of games). For developers it means losing a significant market to people who are using Linux. While most of the software can be written for both the platforms if you plan ahead, it becomes painfully difficult (and sometimes impossible) when the software is already written. This is where Wine comes to rescue.
For users, Wine provides a way of running Windows applications without any modification on a Linux system. For developers, it provides a way of making their applications work with Linux with maximum compatibility.
Before we dive into the tutorial, let’s understand what Wine is. Wine is not an emulator that emulates the Windows OS to run Windows applications. It is a compatibility layer for Windows applications on POSIX-compliant operating systems such as Linux, BSD and Mac OS X. It translates Windows API calls into POSIX calls on-the-fly. Being just a compatibility layer means that Wine runs applications at native performance. That’s not all: since it doesn’t need Windows to function, you won’t need a Windows licence to run Windows applications. In addition to the Windows compatibility, Wine provides open source implementations for some of the most sought-after APIs in the industry (like DirectX, ActiveX, DDE etc).
Wine helps Windows developers to bring their software to Linux in the following ways…
Direct binary execution: This is achieved with the tool called ‘wine’ (part of the Wine distribution). In this process, application source code is compiled on the Windows platform, and then the binary file is taken to the Linux system and is run through Wine. When the application is run with binary compatibility, it can use all existing .dll files. This process is pretty straightforward, but is not able to unleash the full power of the Wine subsystem. However, this is the only way to go if you do not have the access to the source code. You can also wrap Wine with your application to create an easy-to-use way to run it on the Linux platform.
Recompiling the application with Winelib: In this method the source code file is taken to the Linux box, where it is compiled against the Winelib libraries using GCC. This way, the application will also be able to catch up with UNIX API calls in order to leverage the full power of UNIX. Winelib ships with a tool called Winemaker, which creates a GNU standard autoconf-based makefile out of a VC++ project. Winemaker is a Perl script that does all the dirty work involved in converting the source code, making it UNIX specific, clearing up case issues and a lot more.
Winelib is a software development kit for building Windows applications for Linux (and other POSIX operating systems). It includes the Win32 API implementation providing the necessary libraries and header files. It supports C/C++ and shares 100 per cent of its code with Wine.
Winelib is capable of building GUI applications, console applications and dynamic- link libraries (DLLs).
One of the biggest benefits Winelib provides is the ability to make calls to UNIX APIs directly from your Windows source code, resulting in better integration than with the direct binary execution method.
In this tutorial we will be using Winelib to compile a Visual C++ application on the Linux platform.
Mandatory development tools: GCC, G++, Make etc
Git: It is used by the Wine project as the primary source control system
Optional: Access to Windows system with Microsoft Visual Studio 2008 installed
Step by Step
Rules of engagement
The first step to any porting project is to make sure your code is ready for the new platform. There are a few basic rules of thumb that apply to any application which is supposed to be ported. These cover some basic Windows and Linux operating environment differences. First, differences between DOS and UNIX text files must be fixed. Otherwise you may receive errors related to carriage returns and numerous other similar errors.
Then there’s the case of filenames. As you will probably be aware, kunal.c and Kunal.c are the same in a Windows environments, but not in Linux. So, the filenames used in include statements might be different from the original files you are actually referring to.
Include statements should avoid using ‘’ – instead they should use ‘/’. ‘/’ is recognised in both the environments, but using ‘’ may cause errors in UNIX.
Makefiles should be changed accordingly to fit into the new environment. Makefiles are not generally cross-platform compatible.
Sprinkle your code with #ifdefs. This good old technique can be used to isolate the platform- specific code in a very efficient manner.
#ifdef _WIN32 // Windows (x64 and x86) #elif __unix__ // all unix // Unix #elif __posix__ // POSIX #elif __linux__ // linux #elif __APPLE__ // Mac OSX code #endif
There is a very good chance that the Wine shipping with your favourite Linux distribution is outdated. That’s why we will build Wine directly from the source. This will allow us to build Wine to our liking.
NOTE: We are using Ubuntu 12.10 64-bit for this tutorial. If you are using any other 64-bit distribution you will need the respective package management command. If you are using Ubuntu 12.10 32-bit or any other 32-bit distribution, skip this – go directly to installing build dependencies.
Creating chroot for Wine: Since Wine depends upon a lot of 32-bit libraries, it is a good idea to build it in a chroot environment. A chroot is a way of isolating applications from the rest of your computer, by putting them in a jail. In this case we will set up a chroot with the 32-bit binaries and libraries.
Install the chroot packages
$ sudo apt-get install dchroot debootstrap
Create a directory which will hold the root of the chroot environment
$ sudo mkdir /var/chroot
Create chroot configuration for the
@config file: /etc/schroot/schroot. conf [quantal] description=Quantal Quetzal directory=/var/chroot users=kunal groups=sbuild root-groups=root
You’ll need to replace ‘Quantal’ with the name of the distro you are using. You will also need to replace ‘kunal’ with the correct username.
NOTE: The distribution name should be a valid distribution, else chroot environment will not be created. To find valid and supported distribution names, look in the directory /usr/share/debootstrap/scripts/.
Install the base system for your chroot
$ sudo debootstrap --variant=buildd --arch i386 quantal /var/chroot/ http://mirrors.us.kernel.org/ubuntu/
NOTE: You can replace the mirror with one of your liking, preferably nearby. A list of mirrors is located at https://launchpad.net/ubuntu/+archivemirrors. You will need to make sure that the mirror you are selecting contains the distribution you are chrooting.
Set up the Apt sources
$ sudo cp /etc/apt/sources.list / var/chroot/etc/apt/
Enter chroot and install the build dependencies
$ sudo chroot /var/chroot # apt-get update # apt-get build-dep wine # apt-get install git
Install additional dependencies
# apt-get install libosmesa-dev ocl- icd-opencl-dev libhal-dev libxml- perl
Cloning the Wine Git
$ git clone git://source.winehq.org/ git/wine.git
Build and install Wine
We are now all set up to build Wine. # cd wine* # ./configure # make # make install
Setting up the X-server
To make the GUI applications work from within the chrooted environment, you will need to set up the X-server:
On the system shell
$ xhost +
On the chrooted shell
# export DISPLAY=:0.0
You can now test the setup by running the following command
# wine notepad
Now you can use the chrooted environment for all your Wine-related activities.