For the last few weeks I've been focused on the
Fedora MinGW project. This project gives Fedora users a compelling new feature: you can build your software for Windows, without ever needing to leave the Fedora / Linux environment. In fact you can do everything, up to and including creating a Windows installer for your customers, without needing once to touch Windows.
To demonstrate how this works, I'm going to show you how to port a simple application to Windows, using Fedora MinGW. The app I've chosen is
virt-viewer, a graphical console viewer for virtual machines, written in C.
First we install the cross-compiler environment and any libraries that our program requires. (Until the MinGW packages are accepted into Fedora, you'll have to get them from
our temporary yum repository)
yum install mingw32-gcc mingw32-binutils \
mingw32-gtk2 mingw32-gtk-vnc mingw32-libvirt mingw32-libxml2 \
mingw32-nsis mingw32-nsiswrapper
With software such as virt-viewer that is based on the standard
autoconf "configure" script, the cross-compiling step is simple. You just have to do:
./configure --host=i686-pc-mingw32
That's all you have to do to configure virt-viewer (and most other software) to cross-compile for Windows.
Now we just do
make and discover ... ah, that it doesn't compile. This leads us to the hard part of porting software over to Windows. Windows uses the Win32 API instead of the usual POSIX / libc API found on Linux.
For virt-viewer there are several problems:
- virt-viewer uses some header files like <sys/socket.h> which aren't found under Win32.
- We need to include <windows.h> on Windows (but not on Linux). For Win32, this header file is analogous to <stdlib.h> or <unistd.h>, and almost every C source file should include it.
- virt-viewer makes some Linux-specific system calls which aren't available in the Win32 API. The problematic calls are:
- usleep (sleep for a specified number of microseconds)
- fork (create a subprocess)
-
socketpair (create a pipe to communicate with the subprocess)
Problems (1) and (2), the missing header files, are easily solved in a very portable way. For each header file which is missing on Windows or Linux, we will just add a configure-time test and some #ifdef magic. Into configure.ac we put:
AC_CHECK_HEADERS([sys/socket.h sys/un.h windows.h])
and then into the C sources files we put:
#ifdef HAVE_SYS_SOCKET_H
#include <sys/socket.h>
#endif
and so on.
Problem (3) -- missing APIs -- are the hardest problems to solve. In general there are three strategies we could try:
(a) Try to find an equivalent but different API which is present on Linux and Windows. As an example here, Windows has a call which is very similar to
pipe, and might be used to replace socketpair.
(b) Write a replacement function for each problematic API.
(c) Comment out the particular feature in the code which uses the missing calls. This is less satisfactory of course: Windows users will now be missing some feature.
We're going to fix problems in (3) with a mixture of strategies (b) and (c).
Windows doesn't have usleep, but looking at MSDN I see that it does have a function
Sleep (DWORD milliseconds) which can be used as a replacement for usleep.
You can test and replace functions conditionally by adding this to configure.in:
AC_REPLACE_FUNCS([usleep])
Remember that you
don't want to replace this on Linux and any platforms that have usleep, and that is what AC_REPLACE_FUNCS does.
The code to implement usleep is now placed into a single function in a file with the same name,
usleep.c:
#ifdef WIN32
int
usleep (unsigned int usecs)
{
unsigned int msecs = usecs / 1000;
if (msecs < 1)
Sleep (1);
else
Sleep (msecs);
}
#endif
The magic of autoconf will ensure this file will only be linked into the main program when it is needed.
As for
fork and
socketpair, it turns out we are quite lucky. These two calls are only used to implement a specific virt-viewer feature, namely tunneling connections over ssh. If you conclude, as I did, that ssh isn't that common on Windows machines, then you can do as I did and just comment out that feature conditionally when building on Windows.
With those changes, we have now completed our port of virt-viewer to Windows (
full patch). After rerunnning:
autoconf
./configure --host=i686-pc-mingw32
make
we are left with
virt-viewer.exe, a full Gtk application that runs on Windows.
Creating a Windows installer
To package up Windows applications into full-featured installers, that include menu shortcuts, desktop icons and an uninstaller, we wrote a little helper program called
nsiswrapper. As its name suggests, it is a wrapper around the
NSIS Windows Installer, which we also ported over to run natively under Fedora.
You'll need to wrap up not just
virt-viewer.exe, but the Gtk-related DLLs and helper modules. With nsiswrapper you would do:
nsiswrapper --run \
--name "Virt-Viewer" \
--outfile "Virt-Viewer-for-Windows.exe" \
--with-gtk \
/usr/i686-pc-mingw32/sys-root/mingw/bin/virt-viewer.exe
