Common Wine Myths
Wine is one of the best known, but least understood open source projects. It is a mystic application that everyone knows about, many use, but few truly understand. Reading forum posts, blog entries and tutorials about Wine show that Wine is surrounded by many myths and half truths. In this article, we will attempt to clear up some of the misconceptions about the project.
Myth: Wine doesn't run any program well: There are currently 1863 applications with a Platinum rating (applications which install and run flawlessly on an out-of-the-box Wine installation) in Wine's Application Database (AppDB). Additional applications are receiving a Platinum rating at a rapid rate. Popular Windows applications such as Adobe Photoshop CS3, World of Warcraft and Microsoft Office 2007 all run under Wine.
Myth: Wine requires native Direct3D support: Wine implements the Direct3D libraries already. Direct3D 9 and earlier has been implemented for the most part. There are of course implementation bugs, but those are being worked on. The Direct3D runtime is a slow work in progress, and so may be missing some features. Direct3D 10 is unimplemented, but the core infrastructure is in place and future implementation is in the planning stages. Native Direct3D should not be used in Wine, except for the DirectX runtime library (d3dx9_*.dll), to work around missing features in Wine.
Myth: Wine requires native Internet Explorer 6: Wine comes with its own version of Internet Explorer based on Mozilla's Gecko layout engine for applications that use IE for rendering. See the Wine Gecko project for details. There is a ton of work being put into this area of Wine since it covers such a large area of code. As a result, many applications depending on Internet Explorer rendering may not run well. For those applications, using native Internet Explorer serves as a workaround. This is neither required nor recommended because Internet Explorer's license does not allow people without a Windows license to use it.
Myth: Wine is only for Linux: Wine should run on any POSIX system that has kernel threading. However, since most Wine developers are using some version of Linux, these other operating systems don't enjoy the same level of support or compatibility. Wine currently builds and runs applications on Linux, Mac OS X, FreeBSD, Solaris and OpenSolaris. Work is also being done to get Wine to work on NetBSD and OpenBSD, the effort is progressing well.
Myth: Wine is only 32-bit capable: This is partially true, but the situation is changing. Wine has the capability of running 64 bit applications, (see this December, 2008 thread), but it is not yet enabled by default. A ton of work is being put into making the internals of Wine 64 bit compatible. Checking the Wine commit log, one can see frequent additions of patches aimed at 64 bit Wine. Running 64-bit Wine currently requires the use of a special GCC compiler from SVN to compile, so it's mostly for developers at this point. It is worth pointing out though that about two thirds of the internal Wine conformance tests already pass.
This is, of course, different from running Wine as a 32-bit application on 64-bit hardware. Doing so works fine as long as your operating system has the 32-bit compatibility libraries installed. Wine is commonly used for playing games on 64-bit Linux distributions. In fact, most packagers already build 32-bit binaries for 64-bit operating systems.
Myth: Wine stole code from Microsoft! It's illegal to use! Wine is a clean room implementation of the Microsoft Windows API. Wine developers have never used leaked Windows source code or disassembled its output. The implementation is made and tested using a suite of conformance tests, ensuring that Wine has the same behavior as Windows. The conformance tests are built daily and tested on various versions of Windows and Wine. Results can be seen on the Wine Test Runs page.
Wine is a very complex piece of software that has come a long way in the past 15 years of development. Releasing its first stable version (1.0) this past year is a testament to the complexity and size of this program that took thousands of hours of development to implement what Microsoft did with many times the resources. While Wine does not yet have perfect compatibility with all Microsoft Windows applications, the Wine team is working hard to change this. Wine is a very mature, fast-moving and complex piece of software. There's no better time than now to try Wine. Binaries and source code are available here.
| Index entries for this article | |
|---|---|
| GuestArticles | English, Austin |
Posted Jan 22, 2009 2:37 UTC (Thu)
by johnmccutchan (subscriber, #54000)
[Link] (2 responses)
Posted Jan 22, 2009 14:41 UTC (Thu)
by pr1268 (guest, #24648)
[Link]
Do the readers of LWN.net really need these myths cleared up for them? I'm kind of shocked this made it past the editor. Absolutely! I use Wine on a regular basis to run a few Windows-only programs, and I've been Windows-free (Linux only) for 4 1/2 years now. I am pleased that LWN's editors included this article. Thanks to the Wine developers for your hard work.
Posted Jan 22, 2009 19:04 UTC (Thu)
by iabervon (subscriber, #722)
[Link]
Posted Jan 22, 2009 4:24 UTC (Thu)
by ncm (guest, #165)
[Link] (2 responses)
Posted Jan 22, 2009 4:26 UTC (Thu)
by jwb (guest, #15467)
[Link] (1 responses)
Posted Jan 22, 2009 18:22 UTC (Thu)
by timschmidt (guest, #38269)
[Link]
Nevertheless, it's here, it works for many applications already, and when ISVs decide they should start caring about the Linux desktop - it will be a much easier target for many of them to hit than an entirely different toolkit.
Posted Jan 23, 2009 9:16 UTC (Fri)
by luya (subscriber, #50741)
[Link]
Posted Jan 24, 2009 1:20 UTC (Sat)
by mjr (guest, #6979)
[Link] (8 responses)
'course, probably not a major focus for either developers or users at this point...
Posted Jan 24, 2009 17:23 UTC (Sat)
by nlucas (guest, #33793)
[Link] (3 responses)
Nothing new here, as that is a limitation of the processor, not of the system (you can't run 16-bit code on 64-bit mode as you can on 32-bit mode).
But I don't actually run any windows machine, so can't test it.
Posted Jan 24, 2009 18:22 UTC (Sat)
by mjr (guest, #6979)
[Link] (1 responses)
Hmh. I read in a Finnish computer mag that doesn't tend to get things that wrong that it doesn't do 16-bit code. (If you're talking about running a 32-bit windows in a VM, of course that'll do it at the latest...) Actually, as for Wine, the 64-bit version was last I checked slated to run semi-similarly only 64-bit code, while you can run the 32-bit version for 16/32-bit Windows code using the host kernel's 32-bit userland facilities. Anyway, I have no first-hand knowledge — or interest — either, was just trying to be funny.
Posted Jan 24, 2009 18:48 UTC (Sat)
by nlucas (guest, #33793)
[Link]
Anyway, not much interested to know the truth either.
Posted Jan 25, 2009 3:13 UTC (Sun)
by tialaramex (subscriber, #21167)
[Link] (3 responses)
Posted Jan 28, 2009 0:13 UTC (Wed)
by bluefoxicy (guest, #25366)
[Link] (2 responses)
Entering full-blown virtual 8086 mode is impossible, however.
Posted Feb 16, 2010 22:15 UTC (Tue)
by yuhong (guest, #57183)
[Link] (1 responses)
Posted Feb 17, 2010 4:26 UTC (Wed)
by viro (subscriber, #7872)
[Link]
You can get around that by playing with amd64 virtualization (i.e. run a guest in legacy mode and use _that_ to run 16bit real-mode code). If you don't have that, you are SOL - you pretty much have to emulate 8086. Instruction set is there, but address translation is incompatible.
Posted Jan 29, 2009 12:55 UTC (Thu)
by renox (guest, #23785)
[Link] (1 responses)
Now what could be the reason behind this myth?
Posted Feb 2, 2009 9:01 UTC (Mon)
by archdev (guest, #56434)
[Link]
Posted Feb 2, 2009 13:09 UTC (Mon)
by hozelda (guest, #19341)
[Link] (1 responses)
There are very real patent risks whenever you develop using technology/APIs invented/designed by a lover of patents that is threatened by you (FOSS); however, third-party (proprietary) developers may not mind making sure their already-built Windows apps work well on wine.
As long as wine and others don't encourage developers to target wine over, say, LSB, then I think the wine project is a great asset.
The following were written with mono in mind, but everyone should pay attention:
Posted Feb 2, 2009 18:22 UTC (Mon)
by hozelda (guest, #19341)
[Link]
Interoperability is a two-way street. If Windows developers were using open source tools instead of things like MSVisStudio, their apps might just work off the bat with a clean implementation of the specs, instead of being married to the MS platform in undocumented (eg, buggy) ways. Of course, with open source build tools, they might not get as acceptable behavior on Windows in the first place.
This is why I stopped targeting Windows (the lock-in and MS dependency at every turn) and want Linux to displace Windows as the standard.
Common Wine Myths
Common Wine Myths
Common Wine Myths
Common Wine Myths
Common Wine Myths
Common Wine Myths
Common Wine Myths
Indeed not only 32-bit
Indeed not only 32-bit
Indeed not only 32-bit
Indeed not only 32-bit
Maybe the "basic"/"home" versions don't include the virtual machine to run those legacy 16-bit applications.
no 16-bit in long mode
no 16-bit in long mode
no 16-bit in long mode
no 16-bit in long mode
Common Wine Myths
Mmmm, perhaps it's because very important applications such as Microsoft Office are not platinium and still need improvement.
Common Wine Myths
Great but be careful
http://www.linuxtoday.com/news_story.php3?ltsn=2009-01-20... and
http://www.linuxtoday.com/news_story.php3?ltsn=2009-01-20...
Great but be careful