Debunking Wine Myths

Here are some common Wine "myths" that are either completely wrong or not very correct:

• "Wine is slow because it is an emulator"
• "Wine is bad for Linux"
• "Emulators like VMware are better"
• "You need Windows anyway"
• "Wine is bad, Winelib is better"
• "Wine will always be playing catch up to Windows and can't possibly succeed at running new applications"
• "Because Wine only implements a small percentage of the Windows APIs, it's always going to suck"
• "Wine is only for Windows 3.1 / Wine will never support Win64"
• "Wine is for Linux only"
• "Wine is for Intel x86 only"
• "My game has copy protection that doesn't work with Wine"

Myth 1: "Wine is slow because it is an emulator"

Some people argue that since Wine introduces an extra layer above the system a Windows application will run slowly. It is true that, in theory, Windows applications that run in Wine or are recompiled with Winelib will not be able to achieve the same performance as native Unix applications. But that's theory. In practice you will find that a well written Windows application can beat a badly written Unix application at any time. The efficiency of the algorithms used by the application will have a greater impact on its performance than Wine.

Also, and that's what people are usually interested in, the combination Wine+Unix may be more efficient that Windows. Just as before it's just how good/bad their respective algorithms are. Now to be frank, performance is not yet a Wine priority. Getting more applications to actually work in Wine is much more important right now. For instance most benchmarks do not work yet in Wine and getting them to work at all should obviously have a higher priority than getting them to perform well.

But for those applications that do work and from a purely subjective point of view, performance is good. There is no obvious performance loss, except for some slow graphics due to unoptimized Wine code and X11 driver translation performance loss (which can be a problem sometimes, though).

Myth 2: "Wine is bad for Linux"

The fact that Wine exists won't prevent companies from porting their software, but having less than a few percentage points of marketshare will. Wine puts more free software into the hands of people who would otherwise not use it. In turn, history has repeatedly shown that larger marketshare leads to more commercial development. More commercial development has always led to more efforts to develop better free software equivalents.

Myth 3: "Emulators like VMware are better"

Oh, and don't forget the huge performance hit you take to run an application on a full-blown operating system running on top of an operating system.

However, having said that there are instances where emulators are quite useful. Developers can create sandboxes to run applications in, test other operating systems without rebooting, etc. But having a full-blown emulator just to run a word processor probably isn't the best solution.

Myth 4: "You need Windows anyway"

You can already run a lot of applications without having Windows installed. But you have to realize that because Wine is still far from completion many applications will indeed require Windows for some functionality that Wine does not yet provide itself.

Myth 5: "Wine is bad, Winelib is better"

There is really no reason for this. For starters I certainly did not observe any performance difference between Wine and Winelib for the (relatively few I admit) applications I tested in Winelib. Furthermore you have to realize that bugs are not in the way Wine handles PE, i.e. Win32's executable format, programs. Bugs, and performance issues alike, come from the implementation of the Windows API and this is shared anyway.

Myth 6: "Wine will always be playing catch up to Windows and can't possibly succeed at running new applications"

In addition, Wine supports using native DLLs when the built-in versions don't function properly. In many cases, it's possible to use native DLL versions to gain access to 100% of the functions an application requires.

Myth 7: "Because Wine only implements a small percentage of the Windows APIs, it's always going to suck"

Myth 8: "Wine is only for Windows 3.1 / Wine will never support Win64"

But these days are long gone. Since August 2005, Wine advertises its version as Windows 2000, and for several years before this it was Windows 98, so really Win32 is the primary thing Wine supports. Support for Windows 3.1 applications is still around, of course, as is some support for DOS applications.

Win64 support would allow Wine to run native Windows 64-bit executables, and as of February 2006, Wine does not yet have this support. That's okay, since there are very few commercially available Win64 applications. One exception, Unreal Tournament 2004, is available in a native Linux 64-bit version, so nobody (except maybe a Wine hacker) should want to run the Windows version anyway.

This doesn't mean that Wine will not work on 64-bit systems. It does. See this entry in the Wine Wiki for more info.

Myth 9: "Wine is for Linux only"

It is true too that most developers work on Linux. So you run a higher risk of having a specific release of Wine not compile/work on a non-Linux platform. But this is usually fixed in the next release. Also Wine has been known to be missing some important functionality on non-Linux, e.g. good multi-threading. As far as I know these problems are now solved and Wine works just as well on any of the three platforms mentioned above.

There also is a Win32 compatibility project for OS/2 (Odin), which makes use of Wine code.

Myth 10: "Wine is for Intel x86 only"

But what do we mean by 'running on a non x86 processor'.

First it can mean 'I can compile a Windows application on Sparc, link it with Winelib, and have it run on Solaris'. I know, this is not what you had in mind. This may seem very restrictive and yet would be very useful: it means easy porting of Windows applications to almost any Unix architecture. In any case this is the first step towards allowing Wine to run on other processor architectures. Unfortunately Wine's code is not very portable to other processor architectures, partly because some parts of it have to know a lot about the processor, and partly because most of it makes assumptions like 'sizeof(int)==sizeof(pointer)' and 'byte-sex==little-endian'. This is being worked on though, and progress is being made albeit slowly.

Then we could take it to mean 'Wine on Alpha should be able to run Windows NT Alpha applications'. The prerequisite for this is that Winelib compiles on Alpha (or MIPS, the other defunct Windows NT platform). Now, would it be really useful? I don't think many people have Windows NT applications for the Alpha or MIPS processor. So this is probably not that useful and also rather unlikely to happen since we would need a programmer who has just this combination of hardware and software to work on it.

Then there's what everyone has been waiting for: 'I want to be able to run my x86 Windows applications on any processor architecture I like. That's the most complex one. Again the prerequisite is that Winelib works on this architecture, which will definitely happen someday. Then 'all that is needed' is to integrate an x86 emulator with Wine (and also change Wine's name :-). Ulrich Weigand just did that as an experiment some time ago when he had 'some spare time'. He even managed to get some Win16 applications to run. His code was not in a state where it could be integrated into Wine yet and I don't know how much work has been put into pursuing it. His attempt did spark many discussions on Wine's mailing list though. The result is that we would need a sophisticated emulator including a JIT in order to get something really viable (i.e. not too slow). And developing such an emulator is a whole project in itself.
Does it mean it will never happen? Not sure. Maybe we'll get some motivated developers once the Winelib problems are solved. Of course, it would happen much faster if, for instance, Compaq made its Fx32! Intel x86 emulator Open Source and financed the development of Wine for their Alpha machines. As with all Open Source projects, if enough people are interested and pool their resources together, it will happen.

Myth 11: "My game has copy protection that doesn't work with Wine"