WINE is definetely not an emulator. Neither a runtime. Wine is an implementation of the Windows 3.x and Win32 APIs on top of X and Unix featuring a Windows compatibility layer. Wine provides both a development toolkit (Winelib) for porting Windows sources to Unix and a program loader, allowing unmodified Windows 3.1/95/NT binaries to run under Intel Unixes (some screenshots here). Wine does not require Microsoft Windows, as it is a completely alternative implementation consisting of 100% open source Microsoft-free code, but it can optionally use native system DLLs if they are available. WINE’s project leader and CodeWeavers’ software engineer (a company which sells a modified WINE version), Alexandre Julliard, answers a series of questions to OSNews regarding the project and its future.1. For more than a year the WINE users are waiting for the promised WINE 1.0 version. How far or close are we today from such a release?
Alexandre Julliard: We are getting closer every day. We are now working on the last missing piece (inter-process window communication) to complete the transition from a Win3.1 architecture to a NT-like architecture. Once this is done we’ll be able to release 1.0. I won’t give any dates though…
2. There are developers who suggest that WINE should build a graphics subsystem directly into WINE (bypassing X) and do a lot more of the basic Win32 API closer to the kernel. They claim that this way, WINE could probably be more stable and faster. What is your opinion?
Alexandre Julliard: I think this would be a complete waste of time. X overhead is fairly small, so you wouldn’t gain much performance, and you would lose a lot in stability (not to mention network transparency). If there are really places where X performance is a problem, the effort is much better spent fixing X than trying to bypass it.
Also our goal is not to build a Windows clone that runs only Windows applications; we want to bring Windows applications to the Unix desktop, and have them interact smoothly with the rest of the system. This means supporting copy/paste between Windows and Unix, drag&drop, playing along with the window manager, etc. You cannot do that if you bypass most of the OS.
3. Does WINE implement the Win32 bugs? Is the goal to recreate a ‘good’ Win32 API without the bugs, or to have as much application support as possible even if this means to recreate the Win32 bugs?
Alexandre Julliard: We try to implement the bugs, or at least the ones that applications depend on. The only reason for implementing the Win32 API is to run all the applications written to it, there is no point in trying to improve on it if it breaks compatibility. If you want to design a good API, Win32 is the last thing you want to start from (actually Win32 is probably a good example of how *not* to design an API 😉
4. How do you overcome problems like the poor Microsoft documentation and the extremely large number of API functions that you have to implement?
Alexandre Julliard: Usually we start from whatever documentation is available, implement a first version of the function, and then as we find problems with applications that call this function we fix the behavior until it is what the application expects, which is usually quite far from what the documentation states.
This is of course a time-consuming process, since a single problem can have multiple causes and it’s not always easy to find which function needs fixing. We have a number of tracing and debugging tools to help, and beyond that we depend on having a lot of people test a large variety of application; this is one of the big advantages of the open
source development model.
5. Has implementation work started for some new API functions found on WindowsXP?
Alexandre Julliard: No, not really. We only implement functions that are needed by applications, and so far there are no applications that depend on XP-specific functions to work. In fact there are many APIs from older Windows versions that we haven’t implemented, simply because we haven’t found yet a single application that requires them.
6. Transgaming, Lindows and CodeWeavers are developing and also commercializing WINE for their own purposes. Do these companies return their diffs to the main WINE source tree? Please tell us about the relationship between these companies and the WINE open source community.
Alexandre Julliard: (Disclaimer: I’m employed by CodeWeavers)
CodeWeavers business model is to use Wine to build applications, so we benefit from having the standard Wine tree being as good as possible. So yes, CodeWeavers tries hard to return everything possible to the main tree. In fact, sometimes our work goes into the main tree even before being included in our customers trees.
Transgaming is also returning a lot of things, and helping the project a lot; I think their business model is interesting, and I hope they can reach their subscription goal. My only problem with their approach is that by releasing part of their DirectX work for free, but not under an open-source license, they remove the incentive for people to improve the DirectX implementation of the standard Wine tree. They are planning to release everything back to Wine eventually, so things should work out well in the long-term, but in the short-term this is causing the standard tree to not be as good as it could be.
I think the relationship between both companies and the Wine community is very good; in fact most of the developers hired both by CodeWeavers and Transgaming are Wine hackers that were already working on Wine before being paid for it, so they are part of the community too.
7. WINE uses mmap() extensively. However, because of this reason, it is almost impossible to port WINE to a non-Unix OS. BeOS and AtheOS are somewhat POSIX compliant (they support around 85-90% of the POSIX standard), but they do not support mmap() and some efforts to port WINE in the past have ended up in vain. Is there a way to make WINE “more compatible” with other operating systems so a porting effort would be easier for these OSes?
Alexandre Julliard: In fact Wine itself shouldn’t be hard to port; the Unix-specific parts are well isolated, and most of the code doesn’t contain anything system-specific. The main problem is that Wine requires a number of features from the underlying system, simply because these features have to be made available to Windows applications.
So Wine doesn’t so much depend on mmap() than it depends on the ability to map files in memory; if the OS doesn’t offer this, there’s nothing we can do, because Windows applications depend on having this functionality. If the OS has memory-mapped files but under a different system call than mmap(), then fixing Wine to use it should be trivial.
Actually the problem we had with BeOS is not so much mmap() itself, but the fact that the address space layout is not compatible with what Windows applications expect. There is nothing we can do in Wine to fix this, the only solution is to change the address space allocation strategy in the BeOS kernel.
8. Have you ever heard from Microsoft officials or from random Microsoft employees regarding WINE? What do they think about WINE, its implementation and its legality?
Alexandre Julliard: I haven’t heard anything directly, no. They did mention Wine during their trial so they are definitely aware of it, but they probably don’t think it is enough of a threat to do anything about it.
I am convinced that what we do is completely legal, and they probably agree, otherwise we would have heard from them a long time ago…
9. Do you personally find the performance of WINE satisfying? What else could it be done to increase speed?
Alexandre Julliard: I think the performance is perfectly acceptable. There is still a lot of margin for improvement, since so far the effort has been spent entirely on ensuring compatibility. I’m confident that once we start seriously profiling and fixing the performance hot spots, we’ll get close enough to Windows speed for all practical purposes; and in many cases we have the potential to be noticeably faster than Windows.
10. Please list for us some well known Windows applications that were marked as ‘WINE compatible’ the last few weeks.
Alexandre Julliard: Well, it doesn’t really work this way, we don’t have a certification program for Wine compatible applications. There is a database where users can report their experience with various applications and give them compatibility ratings. But given the rapid pace of development, progress is not always linear; an application can work great one week and be broken the next. This should improve as we get to 1.0, but for now the only way to be sure if an application works is to try it. And if you find that your favorite application doesn’t work, reporting the problem to us is the best way to ensure it will work in the near (or not so near…) future.