The open-source Wine project is less a solution and more a workaround when it comes to the issue of running Windows applications on Linux.
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
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.
Source
|
