The following paper I wrote a few months ago because I got sick and tired of seeing people switching to GNU/Linux only to continue to run their Windows programs without even bothering to look for alternatives. Of course, they all used either WINE or Cedega to achieve this. Since I am active in testing WINE for a few select Windows-only applications, my views on what WINE should be used for differs greatly from others. I firmly believe that WINE’s only use in todays age is to allow one the ability to retrieve information from old applications or programs which are no longer developed and are not released as open source (e.g. trying to view tax records from 1995 on Quicken). Because of this, I got to reading WINE’s article on Debunking WINE Myths and upon reading it, I was amazed at how many “opinions” and/or “beliefs” were part of the debunked myths. The following are my debunks of the debunked myths. Some of which I do agree with, but many others I do not.
“Some people mean by that that Wine must emulate each processor instruction of the Windows application. This is plain wrong. As Wine’s name says: “Wine Is Not an Emulator”: Wine does not emulate the Intel x86 processor. It will thus not be as slow as Wabi which, since it is not running on a x86 Intel processor, also has to emulate the processor. Windows applications that do not make system calls will run just as fast as on Windows (no more no less).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).”
Actually, this is right and wrong at the same time. It is true that WINE is not an emulator and should not be thought of one (it’s even in the name.) The added application layer does, in theory, increase lag and even though in practice, most of the time, it is not an issue, the number of cases of slow downs, crashes, non-executable binaries far surpasses that of the number of 100% compatible executable binaries. The WINE goal is to focus more on getting as many programs to run in WINE than to actually have them run stable. This is a double edged sword because that makes the bigger name titles more desirable to the WINE developers, hoping that the lesser named titles also follow the same structure as the bigger named (in essence, knocking two birds out with one stone.) This is seldom the case, however.
A well written Windows application running in WINE will run better than a poorly written Unix program. However; that is a bullshit statement because you are comparing a Porsche to a Pinto on the Autobahn. How about some benchmarks showing the performance of a native Windows program running in WINE verses the Linux version.
One undeniable fact exists: there is a vast software library that works with Microsoft’s operating systems. Many of these applications already have Linux equivalents, however for most people there remains a handful of programs keeping them tied to Windows. Some of these programs have almost no chance of getting ported to Linux (e.g. Microsoft Office), others simply can’t be ported because they’ve become abandonware (e.g. Turbo Tax 1999). Would I want to have Windows just because someday I may need to access an old tax program?The fact that Wine exists won’t prevent companies from porting their software, but having less than a few percentage points of market share 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 market share leads to more commercial development. More commercial development has always led to more efforts to develop better free software equivalents.
This one is completely wrong. It is true that one should not have to use Windows just because of one piece of software, however, high market shares do not increase efforts to develop cross-platform applications. Take a look at Valve with their blockbusters Steam, Counter Strike and Half Life application and game offerings. These are three of the biggest names in the gaming market and yet the GNU/Linux community sees nothing coming from Valve in terms of ports. Blizzard owns the biggest MMORPG currently (World of Warcraft) and they even wanted to develop a GNU/Linux client. What happened with that? The project got scrapped a few weeks before release. It seems that they would rather stick with the windows libraries and just make WoW as compatible to WINE as possible. That in its self is a problem because no way can a company develop an application 100% compatible with WINE because WINE is always changing. History does NOT show that higher revenue increases efforts to develop better free software equivalents. A company that produces closed source, proprietary programs are not going to, all of a sudden, develop open source/free software just because they are making a lot of money. They will continue to stick with their ways and ideas on how they should run their business because by being closed source, they got to where they are.
Now, if what they meant was that by having a big commercial program, this will get the FLOSS community to develop something of the same ilk… That may be true on some accounts, but not on all. There is still no equivalent to Propellerhead’s Reason, for example. The list goes on and on with big name titles that still do not have FLOSS equivalents.
Sure they’re better.. if you like purchasing a full copy of an operating system just to run it under a virtual machine. Not to mention you need to purchase a copy of VMWare to make it work.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.
This one is actually true. Virtualization is not the answer when it comes to being able to run Windows applications, and now that Microsoft made a statement that they will forbid users from running a Virtual Machine of Windows on top of GNU/Linux, this will just cause more problems later on.
No. The goal of Wine is a full reimplementation of the Windows API which will make Windows unnecessary.
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.
You can run a lot of applications, but you will also have a lot of applications crash and just not run properly. There are also many parts of Windows which are required that even WINE can not do because of violations of Microsoft’s intellectual property. Unless WINE sees no problem in fighting Microsoft in court, WINE will never get to 100%. Without 100% compatibility, there are still companies and outfits that are forced to use Windows.
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 and this is shared anyway.
So, bugs come from the implementation of the Windows API and Winelib is supposed to be a reimplementation of the Windows API. If the reimplementation is exact, then there should be no issues between running an application on Windows or WINE. But wait, there are issues, millions of issues. Yet, those issues are only with running those applications on WINE.
This reminds me of all the third party developers complaining about their programs have memory leaks because of the poor coding on Microsoft’s end. It’s never your fault, its always someone else. That is the wrong attitude to have. There are many issues in both WINE and Winelib that needs to be addressed before this myth can be truly proven wrong.
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.
This myth wasn’t even answered or rebutted properly. This is not a myth and is in fact a truth because the WINE developers, doesn’t matter how many they have, will always have to catch up to Microsoft because they don’t know what Microsoft will put in Windows until it’s released. And the little bit about the native DLLs. You can only use them IF you own a copy of Windows. It is illegal to download Windows DLLs without owning a copy of the original or original installation medium. So, if you do not own a copy of Windows, you can not, by law, use the original DLLs.
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. Windows XP support is simply not that important – most applications only require Windows 95 or Windows 98. 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.
Most applications being developed right now REQUIRE Windows XP and will not run on anything older than 2000. And with Vista being here, with its stricter hardware requirements and specialized drivers, it is going to be even harder to get applications to work properly.
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. 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.
This one is true. The number of native WindowsXP64 titles are no where near the number of 32bit applications available. Once the big push is made to get everyone to switch to 64bit operating systems is when we will start to see development for 64bit usage in WINE.
This is just plain incorrect. Okay, as of now Wine does not run on many platforms: just Linux, 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.
This is also true. Hell, they have WINE for Windows.
Well, it is true that Wine only runs on Intel’s 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.
This is one of those “Yeah so?” things. For anyone to make this an issue has no idea or concept on what architecture means. Different architectures work differently and in order to get a binary which is ONLY for x86 architectures to work on a non-x86 architecture would require the use of virtualization, going back to the vwmare myth.
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.
Do you remember that one myth about how WINE will always have to play catch up? This is the same thing. Developers of copy protection are not going to disclose information about their products to WINE developers because, like Blizzard did, WINE is viewed as a third party hacking program.
At this time, I would like to include some of my own Myths/Truths in hopes that someone can correct them.
It has been said on WINE’s site that WINE is a good transition program to help people get accustomed to GNU/Linux. I do not see this happening at all. A lot of GNU/Linux users coming from a Windows background are constantly relying on WINE to continue to use their Windows programs, even when there are free/open source solutions readily available.
Also to note, developers will only develop for whatever their boss tells them to. When an application is in the planning stage is when the company decides on weather to make it for windows only, cross-platform, mac only, etc. That being said, companies do not see a reason to develop their applications cross-platform because, why should they? Their users can just use WINE, even though WINE does not work with that application at ship time, let alone a few months afterwards. However, the companies do not see this as a problem and this, in turn only makes the WINE developers continue to have a reason to continue the development of WINE.
The problem with WINE and those new to GNU/Linux is that they rely too heavily on WINE to work because they do not know of an alternative, however, at the same time, they do not see a reason to even look for anything else because to them, there is no point because they can still get their games or programs to work in WINE (sometimes). There are two ways to migrate to an alternate operating system. The first way is to, while using Windows, start to experiment with alternate applications to what you are used to (e.g. instead of using Internet Explorer, start using Firefox instead). The other way is to let go of Windows, let go of MS Office, let go of iTunes, etc., is the only way to get used to using a different operating system. There are some that say “I just can’t let go of XYZ. I need XYZ.” etc. This is just apathy to learning something new.
I gave up on Windows a long time ago and have never needed to go back. It really is not that hard. You just need to know where your priorities lay.
Now, let’s look at the marketing aspect of the industry. For WINE to be considered as a transitional application for new comers to GNU/Linux, that means that at one point, software will be eventually made cross-platform, since there are just some pieces of software not available, nor ever be made available for GNU/Linux. However, let us look at just what happens in the sales department…
Joe builds a computer and installs his favorite distribution of GNU/Linux. Since there is no really functional way to be marked as a GNU/Linux user (Unlike in windows. I know there are a few programs on Fedora and Ubuntu which will count each install, but they are optional, unlike in Windows.) Now, Joe needs to get Visio to do some work at home. Since Visio is a Microsoft product, when he purchases Visio, that is labeled as a Windows-based sale and the entire industry assumes that Joe will be installing it on a Windows-based computer. So, even if everyone who runs GNU/Linux were to buy Visio, they are all labeled as being Windows users. The same is said with games and any application which one can buy at a retail store. Even though the owner has no intention of ever installing it on Windows, they get marked as a Windows user. This only hurts the entire industry because now Microsoft can pull out their sales figures and show everyone that people are buying their products, so they must also be using Windows. This will, in turn, allow Microsoft to persuade third party developers to develop exclusively for Windows. All the while, Microsoft includes more API’s making it harder and harder for the WINE developers to keep WINE up to date enough to run all the latest software.
The way that programs like WINE should be looked at is a means to run outdated software which is no longer supported and yet is mandatory for the user to run. Everything else out side of that scope is just fuel for Microsoft to continue to spread their FUD and lies.