I uploaded a new set of Wine packages. I know that Wine HQ itself is offering Wine packages for Slackware (see this sourceforge.net link) but being the control freak that I am, I want to know exactly what I am using. I am using my own build script.

My Wine package needs some explanation. As you know, Wine traditionally was meant to run Windows software – 32bit Windows software. Therefore it will run fine on 32bit Slackware but if your computer is equipped with 64bit Slackware, you need to enhance it with multilib capabilities to make this 32bit software work on a 64bit OS.

Microsoft caved in at some point and started offering 64bit versions of their Windows OS. The 64bit MS Windows can run 32bit software out of the box… a wise move since a lot of Windows software is still 32bit binary code. They made this work transparently by adding something akin to our multilib. Microsoft calls it WoW64 or “Windows on Windows 64”.

The Wine package I provide for the 64bit Slackware therefore mimicks this WoW64 configuration and offers both a 32bit “wine” and a 64bit “wine64” environment. You still need multilib to make this work on Slackware64 but you will be able to run 64bit Windows binaries just as easily as 32bit Windows programs.

Now, recent versions of my package have been enhanced again. You may recall that I offer a “pipelight” package which allows you to use MS Windows browser plugins with your Slackware Firefox. Pipelight uses a patched version of Wine. This patch set was orginally called “Wine Compholio” but as more and more people saw how useful these patches were for regular Wine users, an effort was made to formalize these patches and make them more widely known – and used. Nowadays, this patch set is known as “wine-staging” and on 25 September the team announced their integration into WineHQ, making wine-staging a structural part of the Wine development process. I have decided to apply the wine-staging patch set to my Wine package by default since the 1.7.51 release. Fedora does this too for their package.

And with my 1.7.52 package I have added a second patch set which should bring near-native performance to Direct 3D 9 applications in Wine. This patch set is called “direct3d9” and leverages the new “d3dadapter” of the mesa package (provided by the Gallium Nine state tracker of Mesa). The d3dadapter library has been enabled in the mesa package of Slackware-current. My wine.SlackBuild script checks for this library and applies the direct3d9 patch set if that library is found. The wine-1.7.52 packages for Slackware 14.1 and -current are therefore different.

I noticed that there is some overlap between the wine-staging the direct3d9 patch sets. After applying wine-staging there are some chunks of the direct3d9 patches that fail to apply. I do not know if this will have any adverse effects when running Windows applications. I checked with other distros and found that Arch Linux is also applying both patch sets in their “wine-staging-d3dadapter” and don’t seem to be bothered by failing patch-chunks. If you are on Slackware-current and want to (re-)compile Wine without the direct3d9 patch set, you can simply run the SlackBuild script like so:

# USE_NINE=NO ./wine.SlackBuild

I would like to hear from you if these patch sets are making a difference in running your Windows games and other programs.

Cheers, Eric