Submitted by I took them 15 years. During those years, the project grew from something that didn’t work, to something that sometimes under special circumstances could maybe perhaps work, to something that sometimes just worked, all the way to something that works in a number of pre-defined cases. You won’t believe it, but Wine 1.0 is here.Wine, which is, in fact, not an emulator, is a reimplementation of the Windows API on top of X, OpenGL, and UNIX. It is completely free in that it doesn’t require any files from Windows, but you can optionally use Windows .dll files. Wine allows you to run unmodified Windows binaries on x86 UNIX-like systems such as Linux, BSD, Mac OS X, and Solaris.
The Wine team is proud to announce that Wine 1.0 is now available. This is the first stable release of Wine after 15 years of development and beta testing. Many thanks to everybody who helped us along that long road!While compatibility is not perfect yet, thousands of applications have been reported to work very well. Check http://appdb.winehq.org to see the details for your favorite applications.
Packages for your flavour of Linux or BSD can be downloaded from the Wine download page, or you can wait until it hits a repository near you.
I have been using Wine for some time for playing some of my Windows games.
For me, for Wine has really improved since the start of the year to the point where I left Windows completely.
The following programs work for me…
foobar2000
Half life 1 and 2 (Including the episodes.)
Portal
Counter strike source
Day of defeat source
Team fortress 2 (Some performance issues)
GTA:SA (Performance issues)
etc
I use native applications to actually get work done
Nice work Wine!
Well done lads, it’s been a long time coming (not to mention I’ve been watching this project for a long time).
Just goes to show that doing a clean room reimplementation of such a purposely obscured set of API’s is much harder than most people realize.
After 15 years, I think these guys deserve a beer. 🙂
Or a bottle of fine wine.
Yeah, a HQ Wine indeed
Congratulations, but personally I would of liked to the the 0.9 series continue until version 1 was released after 0.9.99. But hey ho, hope their six monthly schedule goes well, or will even one just use the development branch? Time will tell.
Edited 2008-06-17 17:28 UTC
I have been using wine for bridgebase for a few years. In that time there have been many crashes and regressions. The current version, wine-1.0-rc5, works well on FreeBSD and Debian for bridgebase.
I’ve actually used it for flash9 sites in FreeBSD and it seems to work well. Java still doesn’t work. The only time my laptop overheated was using flash9 in windows-opera with wine. Does not get nearly as hot while rebuilding world + watching linux-flash7.
I toyed around with older versions of wine in 2005/2006 on FreeBSD 5 in order to play some older “Windows” games, worked without problems. It’s good to see something new still working (rc5 on FreeBSD 7). The amount of “hand crafted operation” you had to put into wine in order to configure it in a proper manner has been shrinked very much, so it’s no big deal to run *.exe via wine today. Great work!
(I don’t have much need for tools like wine, but I’m sure more and more users will want to switch to Linux / UNIX when the means of running their old applications is becoming more and more comfortable.)
Why don’t you use BSD’s native Java, if I may ask?
I’ve been watching this for a while, watching the list of rc bugs shrink. The page is down now for me, but right before the RC5 came out they had an announcement where they stated the rc bug list was down to zero. I was pretty amazed, but then I saw there was a list of bugs deferred to 1.01, some to 1.2 etc.
But digging a little deeper and looking at the bug reports, 3 of the 4 (IIRC) bugs that had been “deferred to 1.01” actually got fixed after all before RC5. I thought that was pretty cool. “We’re going to defer this: too much work, not enough time. *one day later* Stuff it, here’s the fix”
Nice work!
Wine is actually what brought me to Linux. I only owned a Windows 98 SE license, and I aquired a program that required Windows 2000 Pro to install. Since I didn’t have the time or the money to buy and install Win2K, I figured I would try Wine on Linux. It didn’t work, but I more or less stuck with Linux anyway. Now today, my most critical application is only available for Windows, and it runs fairly well on Wine. If it weren’t for Wine, I absolutely would not use Linux on my desktop.
They’ve not only helped people save their applications, but they’ve stretched the thinking about version numbers.
I’ve yet to be able to use it for anything but applications like Picasa for Linux, but eventually that will change.
The one thing I’ve noticed is that the documentation on using it is rather sparse. The information available is mostly about how it works and how to build it.
In any case, congratulations to them.
Can’t think of any reverse engineering effort that was anywhere near as ambitious.
Anyone know what 1.0 means? Like do they officially have a certain version of win32 feature complete?
I think Wine has always been about supporting Windows software, rather than about supporting a particular version of the win32 api.
On the site it seems to say that 1.0 must run:
Photoshop CS2 tryout
Microsoft Powerpoint Viewer 97 and 2003
Microsoft Word Viewer 97 and 2003
Microsoft Excel Viewer 97 and 2003
Which does not initially seem very ambitious, but I guess if they run perfectly then a lot of other software should work too.
The Wine 1.0 release criteria is here:
http://wiki.winehq.org/WineReleaseCriteria
I do have a lot of respect for their work and whenever i might encounter an Wine hacker I’ll surely buy them a beer or an club mate, but i am kinda disappointed by the Wine project, as after 15 years of development they didn’t even approached full Windows 95 compatibility, which was what i had hoped for 1.0.
Completely wipes away any hope for me that they will ever approach an level of compatibility where the majority of Windows apps would work. So far only one Windows app i ever tried with Wine worked (a rather trivial app from an technical point of view) otherwise even the “platinum” list apps i tried wouldn’t work, which usually was because the platinum listed ones where tested with cracked copies… the originals didn’t work because some fu***** copy protection.
They test with demos, and unofficially with cracked versions as well. I always NoCD crack my legal purchases even in XP. Copy protection is retarded.
With this method I only had problems with games unpopular or unreleased in the US. The CD support emulation is not very good because it fails to fool even the simplest copy protections.
I had a Japanese game fail to start because Wine wasn’t emulating two simple APIs properly. A windows debugger(ollydbg) revealed it was simply reading drive type and label with standard WinAPI. Nothing that replacing a jz by a jne cannot solve but anyways it should work. I didn’t file a bug because there wasn’t any demo available or developers to use.
But Wine’s main enemies are x64, .NET and X. If more and more programs start to use wpf and .NET technology properly, Wine will suffer.
True, but i do have hope that .Net apps will become more Mono-runable as Win32API looses significance on Windows due to maturing of .Net.
We will see how things will turn out.
Won’t help. The .NET API’s on Windows are pretty limited, so virtually any non-trivial application will be accessing the Win32 API at some point, or at the very least some native COM component. Windows.Forms is particularly bad for this – there’s so much stuff that simply can’t be done without calling some native API or another.
Running .NET on Wine, or possibly some future version of Mono might help. Mono doesn’t support COM interop though, since it’s a Windows-only feature, and has no plans to. That limits it’s use for running apps targetted at Microsoft’s .NET runtime.
The copy-protected games that use Steam works. Even though some people didn’t like Steam years ago, most people now enjoy the service, whereas nobody ever enjoyed the copy protection – so it’s a big plus for gaming.
If you want to try games without hassle, use playonlinux. Easy as pie, and you get FAR more than 1 game to run
And most non-game apps I try works easily. It’s become a surprise when something doesn’t work, when it was the other way around a few years ago.
I gave up on Windows games a few months ago. I didn’t find them to be enjoyable even on Windows anymore because having issues was seemingly becoming standard. Games that are unplayable until the first patches, Copy protection issues etc.
Even less than fiddling around with windows to get a game running i feel compelled to fiddle with api simulators to get some ancient games running or getting almost recent games running in mutilated modes (Like HL2).
Also, what point is there at all having those solutions for games when you usually have to buy a game to find out if it may or may not run? Even if it runs on other peoples machines you can never be sure because wine might have issues doing the same for you if you don’t have identical hardware.
Nah, i just don’t want to spend that kind of time getting a game to run.
I would be compelled to spend that time to get apps to run, if i use those apps a lot. Unfortunately i almost got no apps to run with wine at all, which might be because those where 3D apps which seem to be badly supported on Wine anyway. Those that i got to run had so much issues that they where essentially useless.
Well, i switched to Mac, rebought some apps, found some alternatives and do not feel compelled to fiddle anymore.
Now i use Linux on my Laptop for Java development and my Mac for development, graphics, film editing and Music and am rather happy with that setup.
….and some said it couldn’t be done. Good job, guys.
Now if ReactOS could only hit beta.
Hmm… I can’t remember the reasoning behind calling WINE “not an emulator”, and I’m too busy just now to look for information. Anyone have better memory than I do? What makes WINE not an emulator according to the project team? It looks very much like a Windows emulator to me..
Doesn’t that stem from the fact that it was never meant to run on another architecture other than x86? It’s basically a set of runtime libraries (and development kit) meant to be substitutes for the official Windows bits and pieces, not Windows and not an x86 virtual machine running Windows.
The Windows binaries run natively on the processor, with WINE providing all the infrastructure and libraries they need. This is why you can’t run WINE on a non-x86 processor. If you did, you would need an emulator.
Wine doesn’t try to emulate an x86 processor running Windows … for the most part, it merely runs the x86 binary code directly in memory (under the Linux kernel & scheduler, not the NT kernel) and it also intercepts any calls that the running binary-Windows-executable tries to make to the operating system. Since the Windows binary executable will make the assumption that the underlying OS accepts calls according to the win32api, the Wine executable program takes the intercepted call, parses the parameters passed with that call, and translates it all into an equivalent call to the Linux kernel. The Wine executable does the same thing with return parameters “on the way back”.
Wine doesn’t emulate Windows … rather Wine provides an environment for a Windows executable to load and run under the Linux kernel, and it also translates back and forth between the (expected) win32api format and the (actually present) Linux kernel api.
Since Wine effectively runs x86 binary executable programs (intended for Windows), Wine itself can only be expected to be able to do that on an x86 system.
Wine won’t be of any use trying to run a Windows program under Linux on a Playstation, for example, because a Playstation is not an x86 machine.
After all, Wine is not an x86 emulator …
Edited 2008-06-18 13:57 UTC
Because wine doesn’t emulate Windows. The aim of WINE is to run programs originally written for Windows. However, it doesn’t mimick the Windows style. Buttons and windows don’t necessarily look like Windows, the API doesn’t have to do what Windows does, but it just have to do what the user or the program expect. The aim is not to emulate but to give access to a wider range of software.
It’s always difficult, trying to decide if there is enough weight and purpose in reverse engineering something to increase the pool of applications available, or stop running around trying to achieve something that ultimately might be fruitless. The number of COM and Win32 based applications around today that aren’t going to disappear or be rewritten has proved the WINE developers right. I’m just disappointed that people like Mark Shuttleworth don’t see it that way.
What I would love to see is better integration of WINE in Linux desktop programming. Being able to import a DLL into a Linux application and provide a front-end to it would be a small, but huge, win. It provides lots of people an easy way off Windows, and WINE will probably end up having better backwards compatibility than Windows!
DLLs that belong to an application are installed under Wine along with that application.
Wine is able to use system dlls from Windows, but there is no way to legitimately obtain these for Windows itself, so that wine provides its own set of reverse-engineered equivalent system dlls. There is provision in the program to tell wine not to use its own reverse-engineered dll (on the ‘Libraries’ tab of the Wine configuration dialog), but rather to use a user-supplied replacement (binary) dll file instead … if the user is able somehow to obtain such a file.
I took them 15 years.
YOU did!? That’s why! I’ve been wondering how the developers could be that slow, but seeing that it was you all a long, I now understand it all. You’ve been distracting them with news stories on OSNews for all these years.
Wine aims for application and API compatability it does not aim to be compatible with a specific version of windows eg win95/98/xp whatever. It aims to support all of directx, all of msxml, all of dcom etc, as well as support specific applications. Namely anything popular in the appdb hence why starcraft was one of the first games to run in wine. I personally have had mixed experiences with wine (I’m STILL waiting on an implementation of the Glide API on wine (which would kick ass in a lot of old games
)) Overall the experience with wine is a growing positive one. Starlancer was a game I’ve been waiting for ages to be fixed and I had the intense pleasure of closing it’s bug on the 1.0.0 release. Games are becoming more bug free and compatible overall and I’m noticing this trend on my older titles which is where I am focusing my testing efforts. A lot of people don’t know about the wine hacks tree…. I suggest you check it out it has patches that turn on games such as battlefield 2 and Command and Conquer 3. Wine has a lot of features implemented but not turned on due to suboptimal/non accepted implementations. They are actively reworking all of these things to get them in and wine 1.0.0 was just a taste of what will happen as wine settles into alternating periods of feature adding and bugfixing. Whereas before it was mainly feature add, now we start to see massive gains in both functionality and stability and it can only get better from here.
Congratulation !
Finally 1.0 and hopefully for greater things to come
I have been very interested in Wine and CrossOver Office for some time now