This page is linked from the main WineHQ About page, edit with care.
Debunking Wine Myths
This page will replace the "Debunking Wine Myths" article linked from the front of WineHQ.
Here are some common Wine "myths" that are either completely wrong or not very correct:
- Debunking Wine Myths
- "Wine is slow because it is an emulator"
- "Wine is bad for Linux"
- "You need Windows anyway"
- Myth 5: "Wine is bad, Winelib is better"
- Myth 7: "Because Wine only implements a small percentage of the Windows APIs, it's always going to suck"
- Myth 9: "Wine is for Linux only"
- Myth 10: "Wine is for x86 only"
- Myth 11: "My game has copy protection that doesn't work with Wine"
- Myth 13: Wine is not a "native" way to run a program and therefore inferior.
- Myth 14: Wine will never be finished
- Myth 15: Porting with Wine "doesn't count" (eg Google Picasa)
"Wine is slow because it is an emulator"
Wine's not that kind of emulator
When users think of emulators, they think of programs like Dosbox or zsnes. These applications run as virtual machines and are slow, having to emulate each processor instruction. Wine does not do any CPU emulation - hence the name "Wine Is Not an Emulator."
Some people argue that since Wine introduces an extra layer above the system a Windows application will run slowly. While technically true, Wine is no different from any other software library in this regard; even newer versions of Windows must load extra resources to support older applications.
Importantly, the combination of Wine and Unix can sometimes be faster than Windows itself. This is especially true when the system has good drivers and the application isn't exposing any Performance Related Bugs.
See also: BenchMarks
Some argue virtual machines are better. This is true if you don't mind:
- purchasing a full copy of an operating system just to run it under a virtual machine,
- purchasing VMWare (or similar technology) to make it work,
- using much more memory and disk space, and
- taking a performance hit.
A virtual machine is just like a separate machine - you end up with 2 start menus, 2 system trays, no drag-and-drop or copy-and-paste between Linux and Windows, separate filesystems, different network settings, and other issues. Wine integrates with the desktop and filesystem, and makes Windows applications first-class citizens. Now you can start your Windows application straight from your regular desktop environment, place that application's window side by side with native applications, copy/paste from one to the other, and run it all at full speed.
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.
"Wine is bad for Linux"
For most people there remain a handful of programs locking them in to Windows. It's obvious there will never be a Microsoft Office ported to Linux, however older versions of programs like TurboTax won't be ported either. Similarly, there are tens of thousands of games and internal corporate applications which will never be ported. If you want to use Linux and rely on any legacy Windows application, something like Wine is essential.
Wine hurts other Linux applications
Wine makes Linux more useful and allows for millions of users to switch who couldn't otherwise. This greatly raises Linux marketshare, drawing more commercial and community developers to Linux.
Wine is Pointless
Sure, if all your computing needs are fulfilled by native Unix applications, then you do not need Wine and should not be using it. However, if you need/want to use one or more of the tens of thousands of Windows applications, then Wine is not pointless.
Wine is often the best way to use Windows software without giving up on Unix. Let's look at the alternatives to see why:
The most obvious alternative is to dual-boot. This is the solution that provides the best compatibility. However it requires that you acquire a Windows license and then dedicate a good chunk of your hard-drive to Windows. The most significant drawback is that each time you will want to use a Windows application, you will have to reboot to Windows. Then you will find yourself forced to close all your Linux applications just to run that one Windows application. You may quickly get tired of this, or will find that such a situation is impossible to justify in a business environment.
The next solution is to install virtual machine emulation software such as VirtualBox, VMWare, Win4Lin or Plex86. Then you can use windows applications without suffering such a big disruption. But it still requires that you acquire a Windows license and dedicate as much disk space to Windows. Furthermore you will pay for the added convenience: if using VMWare or Win4Lin you have to buy another license, and more importantly you now have to dedicate a good chunk of your computer's memory to the virtual machine. Performance will take a significant hit too.
Using Wine lets you avoid all of that overhead: Windows license, hard-drive space required by Windows, memory and performance hit taken by emulated virtual machines. Now you can start your Windows application straight from your regular desktop environment, place that application's window side by side with native applications, copy/paste from one to the other, and run it all at full speed.
A revamp of this page is in progress.
"You need Windows anyway"
No. The goal of Wine is a full reimplementation of the Windows API which will make Windows unnecessary.
You can already run many applications without having Windows installed. But you have to realize that because Wine is still far from completion many applications will indeed require a few Windows components for some functionality that Wine does not yet provide itself. However, with each Wine release this becomes less the case.
"Wine will always be playing catch up to Windows and can't possibly succeed at running new applications"
The architecture of Wine makes adding new APIs (or DLLs) fairly easy. Wine developers rapidly add functions as needed, even applications requiring the latest functionality are usually reported working within a few months of release. Examples of this include Office XP and Max Payne (a DirectX 8.0 game) - both of which were fairly new as of this writing (5/2002.)
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.
"Wine is only for Windows 3.1 / Wine will never support Win64"
Wine started back in the days when Windows 95 did not exist yet. And although Windows NT (and thus the Win32 API) already existed, it only supported Windows 3.1 applications. Anyway, almost no-one used Windows NT in that time anyway.
But these days are long gone. Currently, Wine advertises its version as Windows XP, so 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.
As of January 2009, Win64 support is being worked on, but is still far from stability. There are very few (if any) Win64 applications which do not have Win32 versions, so this isn't a problem. (See Wine64 for more information.)
The 32-bit version of Wine works on 64-bit systems. (See WineOn64bit for more information.)
Myth 5: "Wine is bad, Winelib is better"
This seems to be a quite popular myth on Slashdot. Basically some people think that running a regular Windows application with Wine is much less reliable and yields much lower performance than recompiling this same application with Winelib. It seems to be a variant of the 'Wine is slow because it is an emulator' myth.
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 which is shared between Wine and Winelib anyway.
One possible reason for the perception is that a typical Windows binary is built with MSVC or an old version of gcc (the latest stable MinGW comes with gcc 3.x), while winelib makes use of the relatively modern compilers available on the native OS. Rebuilding the Windows binary with a current version of gcc and running that in wine would have the same effect.
Myth 7: "Because Wine only implements a small percentage of the Windows APIs, it's always going to suck"
APIs are like a library - it's always nice to have as many books on the shelves as possible, but in reality a few select books are referenced over and over again. Most applications are written to the lowest common denominator in order to have the widest audience possible. Currently Wine supports over 90% of the calls found in popular Windows specifications such as ECMA-234 and Open32. Wine is still adding Win32 APIs, but a lot of the work right now involves fixing the existing functions and making architecture changes.
Myth 9: "Wine is for Linux only"
This is just plain incorrect. OK, as of now Wine does not run on many platforms: just Linux, MacOS X, FreeBSD and Solaris. Still, this is not '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 x86 only"
Well, it is true that Wine only runs on x86 processors. Unfortunately it will also require quite a lot of work before it runs on other processor architectures.
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"
Currently SecuRom works in Wine, and directory objects support has been added to get us toward implementing an ntoskrnl.exe that will support loading copy protection drivers like SafeDisc. Once ntoskrnl.exe is implemented Wine will have full support for SafeDisc versions 1 and 2.
Myth 13: Wine is not a "native" way to run a program and therefore inferior.
It is true that Wine is not a "native" way to run a program which is designed to run under Windows(tm). It is a way to run software designed for Windows(tm) on a different Operating System. This is useful in situations where one is unable or unwilling to run a Windows(tm) operating system. Cost, security requirements, and personal choice are some possible reasons for this to occur. Claims that software which is not run in a "native" environment is inherently inferior to software which is run in a "native" environment are spurious.
Software (i.e. Wine) is not inferior by virtue of not being written by Microsoft (native). One may use words such as "genuine" to perpetuate such a myth, but it is not something that most users care about. Most users care about being able to run a variety of software, of their choosing, which Wine lets them do.
Myth 14: Wine will never be finished
Large software projects are never finished, only released. Wine is chasing a moving target since every new release of Windows contains new API calls or variations on the existing ones. (Although Windows XP is a steady target that is still more popular than Windows Vista.) Wine 1.0 was released in mid-2008, Wine 1.2 was released in mid-2010, Wine 1.4 will be next.
See also: Myths 6 and 8.
Myth 15: Porting with Wine "doesn't count" (eg Google Picasa)
- See related Myths:
- Myth 5: "Wine is bad, Winelib is better"
- Myth 2: "Wine is bad for Linux"
- Myth 13: Wine is not a "native" way to run a program and therefore inferior.