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.
mmap() isn’t the vain of BeOS programmers – BArea’s will do just fine. The only problem is that the port is no longer trivial and cannot be done with minimum code changes (like my half arsed attempts with Qt and Konqueror, done in less than a day). Since the porter isn’t the person who initially designed the app, the time needed to reimplement the functionality is much higher than what your averaged bored geek is willing to spend. Hence its easier to cry “we want mmap() and select() and AF_UNIX IPC” than to sit down and work around the problem. Having the kernel and applications live in seperate address spaces is a different story, though.
Now if we only had a cross-platform binary compatible environment in which to program in … wait a sec, we do 😉
http://www.scaredcity.com>We found no use for wine yet, but you never know.
I think it’s amazing that the Sims now runs in WINE, and yet it won’t run in either VMWare of Windows NT. For many purposes Windows is now already obsolete. The few Windows programs that our weather station runs (BUFKIT, GeoClock, etc.) all run more or less perfectly either in WINE or DOS, which can be emulated. All other programs run in Linux.
Has someone worked towards adding Linux kernel/libc support for using
windows DLLs as a native Library format.
It seems that this is what all those divx/asf players try to
emulate at that application level.
Ooo nooooooo
( So there is no hope to have WINE on BeOS?? what about NewOS (and OpenBeOS)? Does it have address space model needed for WINE?
Well, I got my answer on having an independent GUI. I guess it comes down to their philosophy of coexistence with the X framework on the native OS which pretty much implies it’s got to be Unix. I wonder how many Wine ports have been done to non-unix platforms? I don’t fully buy the line that the unix stuff is confined to a small section. If the X dependence is included, I suspect the unix dependence would be much stronger.
P
Why in the fud would anyone want to run some virotic liesense filled bugwear, on their gnu/linus box? Does anyone think father william would NOT FUDge up any efforts to run his bugwear, without his ‘supervision’/ransom being paid? Seems like a study in futility. We did once recommend wine as something that’s needed. Now we’re taking IT back.
Don’t forget to enter our big http://www.opensourceworks.com>web giveaway. Includes a year’s free hosting. fud is dead. everything’s gnu now. get with IT.
LOL ;]
do You have Macromedia Flash on other os than windoze? Macromedia Fireworks? Ultima Online, and other popular games? Internet explorer (well except mac, and don’t start war about browsers, i like IE’s compability with all pages
? I thought so… WINE is a great project, too bad i can’t use it on BeOS 
IT scares <a href=http://www.scaredcity.com>us a little (as you might guess), when something reads: Works ONLY with m$IE, etc…. Kind of like saying, the only functioning entities left in the garmeNT disstricked, were subscribers to john gotti’s ‘plan’, & IT was good that way.
We run over 100 websites. I doubt we’d even be able to afford to run one under father williams’ liesense plan. Not even counting all the ViWorm DOWntime, etc…….
Not to mention: What if the kingdumb didn’t like what we have to say, would they simply revoke our license/block access to us? IT says they can in their eula.
Does anyone know why father william, & his ?pr? machine, spend so much time/money on vicious, deceptive, cowardly, unamerican attacks on the good GNUs guys? Are they really all that bad, with their ‘free’ stuff? I DOWt IT.
Those quotes around `pr’ in your post probably look just fine from Windows, but they show up as question-marks here in Mozilla on Linux.
’cause that’s what they are. talk about realistic rendering. NO whoreabull payper liesense m$bugwear boxes here.
Gnu_bob. THIS IS NOT SLASHDOT.
Continue writing all this crap and spam our forums as you do the last 2 weeks and you will have your IP banned from this web site completely by the end of the day. You won’t be able to even read the news, let alone reply to forums.
A little off topic but I got codeweaver’s plugin for
netscape over the weekend. I don’t have it working for
Konqueror, Mozilla or Galeon but it works pretty well
with netscape. I really enjoyed being able to view
Quicktime movies and VR on linux. OK, I would prefer
a free protocol but it’s great to run windows plugins
under linux since I won’t have a M$ OS in my home.
Don’t forget freedos and dosemu. I facet gemstones in
my sparetime. The major design program for gemstones
is GemCad. It is not avaiable for windows, NT, Mac
or linux. It only runs under dos or dosemu. This program
is freeware but the market is too small to justify a
port to Mac or Linux. I’m not sure a windows version
will ever be developed. Their are many small market
programs like this. A huge benefit for a very small
market. There are not enough bucks for smoeone to spend
months porting to linux but dosemu and freedos enable
me to use a great tool.
Dan
Zenja said:
mmap() isn’t the vain of BeOS programmers – BArea’s will do just fine. The only problem is that the port is no longer trivial and cannot be done with minimum code changes (like my half arsed attempts with Qt and Konqueror, done in less than a day). Since the porter isn’t the person who initially designed the app, the time needed to reimplement the functionality is much higher than what your averaged bored geek is willing to spend. Hence its easier to cry “we want mmap() and select() and AF_UNIX IPC” than to sit down and work around the problem. Having the kernel and applications live in seperate address spaces is a different story, though.
I say:
I’m no pro programmer, but is it possible to create an mmap() function on BeOS that uses BArea or something like that.
Just create a library to translate the mmap() calls of Wine and other programs….
It will be interesting to se what ReactOS can do with a modified port of WINE.
A free Windows with NT functionality is what i’m waiting for.
Why WINE? It is an entrance vector to move Win users into Linux. Until Linux elitists understand that this is an important avenue of growth, Linux will remain an ‘also ran’ and always be marginalized on the desktop.
In other words, the goal is to gain the upper hand and take a chunk out of MS business. You can’t do that unless you take MS users. MS tactics will not drive a significant number of the disinfranchised into Linux, OS X, or any other OS. Making the OS insignificant is the only way. If a user can run his/her favorite store bought apps and games on a choice of OS’s, then, and only then, will Linux become viable for the average computer user, and only when the AVERAGE computer user is captured will it matter.
WINE is a vector towards capturing those users.
Please learn how to spell gnu_bob. JMP is quite right, I hate M$ as much as anyone, but I do need to run some of their apps. I get around paying the tax to big Bill by using warezed WinXP, but I’d much rather do it the wine way…
An entrance vector indeed… But so was OS/2’s ability to run Windows apps. IBM saw this as neccessary to get people to *start* using OS/2, and they were right about that. But remember the line “it’s the apps, stupid”? What keeps an OS alive is that there are apps, especially killer ones, that are native to the OS, take advantage of its best features and, most importantly, don’t exist elsewhere. Since OS/2 could run Windows apps the major software companies said they didn’t need to expend resources to write OS/2 native ports – they had their hands full with the Windows versions already. As a result, no critical mass was reached of OS/2-only apps to sustain it. Linux hasn’t reached critical mass either, and may not reach it if the only reason that people run it is for some better stability in the OS when running their favorite Windows apps. And what have they gained if the apps themselves are less stable and need to keep getting restarted after they crash? As with OS/2, there’s some pain involved in just getting the Windows apps running under Linux and more to keep them running, and it’s not worth it if you can just run the same app under its native OS.