After devoting my last couple of columns to the topic of choosing an
alternate OS (in particular, Linux) without giving up your Windows apps, I
didn't plan on extending the discussion further—that is, until a lively reader
exchange prompted me to turn that pair of columns into a trio.
If we're to discuss Windows applications on Linux and other Unix-like
operating systems, how can we forget about Wine,
the open-source project devoted to building a sort of shim between the APIs
that Windows applications require and the equivalents of those interfaces on a
Linux machine?
I've been keeping tabs on Wine for as long as I've been following Linux, and
my exclusion of Wine was less about having forgotten about it than about having
set it aside—at best as a “maybe someday” solution and at worst as an altogether
lost cause. For a time, I hoped that Wine would be the answer to the Linux apps
chicken-and-egg problem. However, things never quite worked out that way.
First off, many (it's probably safe to say most) Windows apps don't run
under Wine at all. For instance, neither of the two Windows-bound applications
that I miss the most as a Linux user—iTunes and the VMware vSphere client—works
under Wine. In the case of iTunes, Wine lacks USB
support, so there's no way to use it to communicate with my iPod Touch. The
vSphere client relies on Version 3 of Microsoft's .NET
framework, which Wine does not support, either.
What's more, even when it is possible to get your Windows apps running on
Wine, various tweaks are often required to get there. For instance, while
getting reacquainted with Wine to write this column, I found that the Windows
apps I tried to run appeared on my desktop with jagged-looking fonts. I managed
to enable font anti-aliasing to address the issue, but only after fiddling
around in the registry of my Wine installation.
Once you've gotten an application running, the next set of system updates
you apply—whether to your Linux machine, to the Windows app in question or to
Wine itself—could well sour your installation, requiring still more tweaking
and forum searching.
For certain popular applications, you can save yourself some of this hassle
by purchasing a Wine distribution such as Codeweavers' CrossOver product as a
way of outsourcing some of that tweaking and searching work. But if you need
support from your application's vendor, I imagine you'll have a tough time
finding Wine in any supported configurations matrix.
For all these reasons, I can't see Wine serving as a reliable option for
addressing the Windows-apps-on-Linux problem. Rather, it's a workaround,
something to keep in mind and try if you're in a pinch, but not something to
count on.
Now, if, as the reader I discussed this with suggested, all the big Linux
vendors got together and invested in Wine, I don't doubt that they could
improve the project a great deal.
According to the project's bug tracker, some work toward USB
support is under way, and versions of the .NET
Framework earlier than the one I need for the vSphere client are reported to
work.
However, these vendors have reacted toward Wine with unambiguous ambivalence
for going on 10 years now. Considering how slow the projects and companies that
drive Linux have been to seize on and integrate the largely Linux-powered apps
of the Web into first-class citizens of their desktop distributions, it's tough
to imagine them working hard to enlarge the application base for Windows.
Executive Editor Jason Brooks can be reached at jbrooks@eweek.com.