Title: Welcome to the Wonderful World of Porting!

Since learning C++ back in 2000, I've been one of the programmers on the open source desktop publishing package called Scribus. This application looks, feels and works well and has been favourably compared to commercial offerings from Quark and Adobe. It is already used around the world for commercial applications - from newspapers and magazines to catalogues, the application gets around (especially as it is being championed by Novell's SuSE Linux distribution).

The application is written in standard C++ and uses the Qt widget set primarily with libart, littlecms and libxml2 also in the mix. There are a few quirks, but nothing much. Due to this and now Apple are using (effectively) BSD, there is already a native Mac OS version of the software. Same cvs tree, but with a couple of small alterations to accommodate the different hardware.

Time rolls on and the programming team have been under a bit of pressure to produce a native Win32 version. There is already a cygwin version available, but it has been a long term aim for there to be a truly native version without the baggage found on the cygwin port.

As I have experience of programming under Win32, I was elected to do the port. Oh well, that should be fun...

I initially approached the porting process by using Visual Studio .NET under WinXP and with an education licensed copy of Qt.

Um. That was fun. The compile of Qt failed and I had to do that by hand. Not a pleasant experience. I then had to install TortoiseCVS to enable me to obtain the source code. Another pain in the backside process. Finally, they were installed and I could begin.

The first problem with any port is to resolve the dependencies. LittleCMS already has a prebuilt version for Windows as do most of the other parts required for the build (including fontconfig, which can be found on the gimp website).

After the dependencies had been resolved (and installed correctly), the next stage was to find the aspects which differ greatly between how the different operating systems work. There are two as far as Scribus is concerned: printing and files. File systems vary greatly from platform to platform, Linux and Windows are no different in this respect.

While to any Linux application developer having self-built applications in /usr/local seems fine, to a Win32 user who has only ever used Win32, the logic of having parts of the application in the Windows directory with parts in the Program Files directory would seem fine. Unfortunately, when you've exclusively been based on one platform, this logic vanishes (or at least becomes hazy). Another example, files under Linux are (typically) saved in $HOME, under Windows they can be just about anywhere. $HOME also doesn't exist under Windows (well, not that I could use!).

The difference in file systems also has another drawback as far as porting is concerned. The Makefile cannot be "just" used. The paths have to be altered to reflect the fact that /usr/local would be of little use under Win32. Also anywhere in the code which relied on $HOME would also have to be altered with either a conditional for Linux / Mac OS and Windows or just be removed totally. Reliance on any hard-wired system variable is not a good idea when porting an application.

The next major difference between Linux and Windows is in the printing system. Linux uses CUPS while Windows uses its own system. Due to a decision made early on in the development cycle of the original versions of Scribus, the Qt qprinter class was never used for the printing, instead interfacing with CUPS was opted for. At the time, there wasn't a plan for a Win32 version and Mac OS has a port of CUPS already, so the main alternate platform was already covered in those terms.

My idea was to omit the printing system completely until I had time to understand how printing works under Windows.

Right, that's all the parts in place, any environment variables gone and dependencies met. Now to import the source into Visual Studio.

My last experience with the Microsoft Visual series was Visual C++ version 5. Quite a lot has changed, but not for the better from what I could see. The importer was awful. I wasted more time in trying to import a cvs repository than any other aspect of the port so far. In the end, I gave up, wrote a script and restarted Visual Studio. Good. That's the code in. Let's build.

Let's not. The compile failed at the very first file as I'd not remembered to switch off that very annoying bit that includes the non-standard <stdafx.h> header. Why on earth that is switched on by default is anyone's guess. I find it more of a hindrance than a help.

The actual build went quite nicely until the printing and font handling files came to being compiled. Here, my system gave up with memory fault errors (which is strange as the system has over a gig inside). On closer examination, it wasn't the computer at fault, but the compiler giving some very strange errors. It seems that VS.NET is still having problems with templates, especially with the way I'd been optimising the code. Either there is a leak in the version of the compiler I was using or the compiler was plain daft. At this point I was asked not to continue porting Scribus. I won't go into the politics, but I was thankful. Not least as it meant that I didn't have to carry on fighting the build system in order to just compile some pretty straightforward source code.

All went quiet at this point for about a year until March 2005. During this time, I was approached to start the port again. To ensure that the same pressure was not bought down on me as before, I attempted to do the port under emulation on my Linux machines.

Emulation is good fun and can be very useful (there is nothing like firing up a ZX-Spectrum emulator and playing Match Day for hours on end on a typically wet summer afternoon or a ARM emulator to ensure some code will actually run on a target platform), but it really does have its limits.

I attempted to get Borland C++ vsn 6 running using CrossOver Office (a more professional version of Wine). The install went fine, but it plain refused to run.

Next was to try MinGW (a Win32 version of GCC). This worked, but was quirky and on the whole, using CrossOver wasn't really proving to be too good. Win4Lin Pro fared little better. While Win4Lin requires a full install of Windows to be installed, it was incredibly slow.

Next time : Onward to a Win32 box and porting.