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.

The source is available now. Binary packages are in the process of being built, and will appear soon at their respective download locations.

Initially Wine only supported Win16 since it started in the Windows 3.1 days, and we could probably have made a release with pretty good Win16 support sometime in 1998 or so. But of course at that point everybody wanted to run 32-bit apps, so to concentrate on Win16 support to bring it to release would probably have caused many developers to lose interest. Instead we started re-architecting things to support Win32, which in the long run was the right choice, but meant that we couldn't release anything decent for a long time.

Photoshop CS2 is clearly the flagship application here, but I think the message is to try anything they can, that's why we put all that effort into getting installers to work. At this point there's a good chance that just about any application will install and at least do something interesting.

The DIB engine is the major missing feature, I'm hoping to see this in 1.2. Some other interesting patches sitting out there are the iPod support (and more general USB devices support), and the animated cursors.

In the longer run, 64-bit support will clearly require some deep technical changes; it's fortunately not as bad as the 16->32 transition, but it's still a lot of work.

I don't think Windows drivers are all that interesting for Wine, except in a few specialized areas like USB devices or printers. General driver support would really have to go into the Linux kernel to be useful, and while that's certainly feasible it would be a separate project.

On the Mac OS front we clearly need a quartz graphics driver, it would make the user experience a lot nicer. Doing it right is a pretty major task though, so I don't know when it's going to happen.

I think there will come a point where the current Win31 support will have to be killed; it could be replaced by a cleaner architecture that is really independent from the 32-bit codebase instead of being intermingled with it, so that it doesn't get in the way of 32-bit changes and doesn't get broken all the time. The difficulty will be to find someone to do the work, working on new features is a lot more interesting...

So far we have been able to keep up, and I don't expect that to change. We are of course always lagging a bit behind, but I don't see the gap increasing, on the contrary. Besides, all the complexity is a major headache for Microsoft too, they are finding it increasingly difficult to make significant changes.

More regression tests...

I'd like to have proper desktop standards, implemented correctly by the various desktop environments. We are slowly getting there, but it's taking much longer than it should.

I wouldn't know where to start, there are so many things that would have to be fixed...

I doubt that they will bundle Wine, since they are all scared of Microsoft. It's all FUD, there's no rational reason to be afraid, but even if the likelihood of a lawsuit is very small, the infinite resources that Microsoft could put into it is enough to discourage them.

I don't think there's any problem for Wine either in LGPL2 or LGPL3, so there's not a lot of motivation for switching. I imagine that the switch will happen eventually when the need arises to share code with LGPL3 projects.

I'm hoping we can make stable releases a bit more frequently than once every 15 years...

Also we'll hopefully be able to put in place the system for keeping track of contributions that we've been working on with the SFLC; but that's mostly a paperwork issue, it won't change fundamentally our way of working.

Some of the obvious major features are the DIB engine, Win64, .NET support, the quartz driver, etc. But what really takes time is to track down and fix all the nasty little incompatibilities that break applications that would otherwise be quite happy with our existing feature set. That's where magically adding developers would really help.

The Ubuntu "popcon" package is installed when a user opts to share anonymous usage data during the install process (or within the synaptic package manager).

Analyzing the data ( http://popcon.ubuntu.com/ ), we can see the following for Wine:

wine 215262 installed 41731 use regularly 156710 don't use

compare this with dpkg, which every Ubuntu system has:

dpkg 576989 installed 151098 use regularly 411213 don't use

Doing some division, this means that a rather high 37% of Ubuntu users have Wine installed, and 10% of all Ubuntu users actually make use of Wine. 7% use Wine "frequently", however popcon defines that.

Combine this with other estimates of Ubuntu's user base (about 8 million last I heard), and you have approximately 800,000 Wine users.

This data is slightly biased - it doesn't include most Wubi users who installed Ubuntu from within Windows, since they aren't given any installation questions. I believe, though can't prove, that this means we are under-representing Wine users, as it seems reasonable that Wubi installs would be more likely to have Windows applications to run and thus need Wine.

Thanks, Scott Ritchie

Indeed. If Ubuntu still represents the ~30% marketshare it had in 2007 when they did the dekstoplinux.com survey ( http://www.desktoplinux.com/cgi-bin/survey/survey.cgi?view=archive&id=0813200712407 ), and if users of other distributions are just as likely to use Wine as Ubuntu users, then we can estimate there are about 2.6 million Wine users out there.

Wow! Of course, this estimate is too high if Ubuntu has grown substantially in marketshare since the 2007 survey, but even if Ubuntu has climbed to 40% that's still 2 million Wine users out there.

Way back five years ago, we all compared notes on how long it took to build Wine on our systems. http://www.winehq.org/wwn/149#Compile%20Time%20Comparisons%20/%20Tips

Today I measured it on a new computer (with a spiffy new Intel dual core e7200 processor with 2GB of RAM, http://kegel.com/new-computer-2008.html ).

Result: ... it takes me a bit longer today on this machine (11 minutes) to build as it did then on a dual cpu hot rod (8 minutes). I guess Moore's Law isn't quite keeping up with Wine's code growth :-)

[Make] Details are on buried that page, but it's "-j3" for the dual core / dual CPU systems.

I found a nice graph of Wine's codebase size over time: http://www.ohloh.net/projects/wine/analyses/latest Looks like it's just about exactly doubled since that last measurement in late 2002.

I suppose my e7200 is a budget performance system; a dual Xeon back then was pretty special. Probably have to compare it to something heftier today?

Hi Dan, it's 31 minutes on AMD Athlon(tm) 64 Processor 3700+, 2GB RAM. Cheers Vit

I used to compiled it over 30minutes... now I barely wait... 6mn26s

make -j5, Q6600 @ 2.4GHz gcc version also matters (4.2.3 for me) A+

It's 4m55s on a 2 way dual core Xeon machine (4 cores, 2 Ghz, 4MB cache each). This is on a hot disk cache, i.e. I ran

twice and took the second measurement. Compiler is gcc 4.3.0.

for comparison I have an older 2.4 ghz quad CPU single core build box with gcc 4.1.x and Fiesty. make -j4

real 16m34.006s
user 56m54.569s
sys 3m26.561s

real 5m22.625s
user 17m16.993s
sys 1m1.336s

This is on Kubuntu 8.04 w/GCC 4.2.3. The system uses a Q6600 overclocked to 2.9Ghz, 4GB of DDR2 RAM@1066Mhz, and a 9600GT video card. I had Amarok and some other stuff going in the background, but nothing that would make a huge diff.

He he, I think I hold the record.

Wall clock  | CPU              | RAM   | gcc   | Machine
------------+------------------+-------+-------+--------------------
145m38.115s | P3 600MHz        | 192MB | 4.2.4 | Debian Laptop
------------+------------------+-------+-------+--------------------
 39m30.058s | Pentium M 1.5GHz | 768MB | 4.2.3 | Ubuntu Laptop (1)
------------+------------------+-------+-------+--------------------
 53m12.450s | Athlon XP 2600+  |   1GB | 4.2.4 | Debian Desktop (2)
            | (2.1GHz)         |       |       |
 12m34.218s |                  |       |       | 100% ccache hitrate
------------+------------------+-------+-------+--------------------
 50m58.424s | Athlon XP 1800+  |   1GB | 4.2.4 | Debian Desktop
            | (1.53GHz)        |       |       |
------------+------------------+-------+-------+--------------------
 29m30.277s | Distcc           |       |       | (3)
------------+------------------+-------+-------+--------------------

(1) This one is missing Esd, NAS, Jack and Valgrind (memcheck.h) support. However in other tests this does not seem to make much difference. It's also the only one with a different distribution and gcc version which makes comparisons tricky.

(2) This is actually my main development machine. And damn, it's slow! I hope to retire it soon but it still hurts. I guess part of the reason for it being so slow is that it's never really idle. There's always half a dozen Firefox windows around, gkrellm, xmms, a bunch of background processes like MythTV, MySQL, software RAID 1, 90% full disks, etc.

(3) This is with 1 job on the Athlon 2600+ and 2 on the Athlon 1800+.

I tried getting Wine 2002 to compile but even in my Debian 3.1 chroot and with gcc 2.95 it wouldn't. So we don't have a good point of comparison.

Hi,

I was at LinuxTag 2008, which is the largest Linux User fair in Germany.

The fair was from Wednesday to Saturday, however I was only there Saturday. Saturday was openSUSE day and we (openSUSE) had a conference track over the whole day.

One of those talks in this track was my talk on "Wine - applications and games on Linux". My talk was well received, the lecture hall was about 80% full with around 180-200 people.

My german slides are at:
http://files.opensuse.org/opensuse/en/0/08/Lt2008-wine.pdf
http://files.opensuse.org/opensuse/en/6/66/Lt2008-wine.odp
2 smaller german online journals commented on it, mostly regarding the 1.0 release part:
http://www.golem.de/0806/60100.html
http://www.oszine.de/node/9141
(There might even be a Video recording later on.)

I received totally unexpected applause on announcing that after 15 years we finally come to 1.0 release (after over 200 alphas, and 60 betas). After the talk I had 10 people around me asking questions, and one specific problem with Adobe InDesign FileOpen Dialog on a laptop brought to the openSUSE booth.

Interesting Wine related points:

- Kai Tietz of mingw64 told me that they have a GCC patch ready for gcc 4.4 which will support the Win64 calling convention attribute just like __attribute__(stdcall).

Was committed to GCC TRUNK: http://gcc.gnu.org/viewcvs?view=rev&sortby=date&revision=136311
__attribute__(ms_abi)

If we have more GCC requirements for Win64, he is willing to help.

In general he would like to have Wine as a testbed for mingw64 development (and we could use it as testbed the other way round).
http://mingw-w64.sf.net/

- Avira (Antivirus vendor)

They use Wine in house to at least get some info on Windows DLLs, using version.dll.GetFileVersionInformation.

While this works for Win32 DLLs, it stopped working/currently does not work for Win64 DLLs.

- scan.coverity.com

Talked to Coverity folks, and also to David Maxell. The application will receive an update from Coverity 2.9 to 3.2 in the next days/weeks. Not sure if it brings new features.

Also process issue: We have a large backlog of UNINSPECTED features. They suggested that in those cases we could just say "lets not look at this old cruft" and mark them somehow "PENDING" or similar. Not sure it helps us, but at least we could use "PENDING" for partially inspected issues.

- Booth or no Booth

(We had no booth this year.)

Since the question will likelay appear again, I thought about whether to have a Wine booth itself next year... Well, if we dont have at least 2 people there over the whole 4 days it does not make sense and finding those 2+ people likely is difficult.

I might be able to spare the time, but this year it was not possible due to overlapping schedule. Perhaps its also easier to have a demo-point on another larger booth (could ask openSUSE if they would have Wine there).

At least the Saturday visitors got their knowledge on Wine increased by my talk at least.

I got the feeling that people are still quite unsure what works and what not and expect clear and definitive statements from us. I pointed to the AppDB several times in those cases and tried not to make overly positive statements.

People are expectant on 1.0 and I think they are willing to be suprised.

Ciao, Marcus

Hello All, I mentioned the other day in the noise about the upcoming 1.0 and the short comings I felt it had. Others have commented quite a bit on the subject already and so I'll be pretty brief. I think the 1.0 process while its been slow has been a good even with its shortcomings. Like with everything its a learning process and hopefully we will be able to tweak the process further for 1.x releases.

On the positive side, I think that Dan has done a great job as release manager, maintaining the bug lists, working on winetest, staying on top of all the tips and tricks needed to make Valgrind really useful and maintaining winetricks. I'm also really glad that Alexandre did a lot of refinement to the winetest infrastructure, everything he has done with the Wine infrastructure leading up to this point and frankly for everything he's done for Wine for the past 15 years has been awesome. Though I will be glad when the freeze is over so we can get back to having our patches just silently ignored when he does not like something rather than him having an excuse of the code freeze. =)

One of the shortcomings I see as I stated in my email the other day, I think we really missed the target on. I think some Office versions should have been a core requirement of 1.0. Even if it was Office 97 and 2000 working in 98 mode I think we should have been able to provide a nearly perfect experience out of the box. Or nearly out of the box as it were, with a little version tweaking. Office is a core pillar of Microsoft's monopoly and not making this a priority I feel misses the point of Wine for a lot of users.

Also I think the process can be refined a bit more for subsequent releases. Some of the developers I spoke with offline were unhappy about not having a public experimental branch that was blessed to continue development in. While they could privately do development and push and pull changes with git, not having a sanctioned experimental branch, I think slowed the overall processes of development down and did not really help with bug fixes enough to be warranted. Perhaps in the future we can maintain parallel lines of development before major releases. A good example is the Samba guys, they've been working on Samba 4 for ever, but the stable branch is still being constantly improved, better, newer stuff is being back ported and development continues on both tracks.

Finally I am still not really happy with the results of Winetest. I think we should have had dozens of people that could pass all of the tests months or even years before 1.0 shipped rather than just Alexandre's system being the only one that could do a perfect test run. Maybe we should have just asked him to mirror his setup and provide a list of every package and configuration option he uses so we could base target systems on that. Also I think we should have done something to insure new Wine tests always passed on a fixed version of Windows a lot sooner. James has done a lot of work to make all of the tests pass on Windows 2003 but I think we should have done this back in 2003 and said "every new test has to pass on Windows 2003" as well as Alexandre's box before it gets merged.

As far as 1.0 goes, its not perfect but its not horrible and I think we've learned quite a bit and Wine is better now than its ever been. I expect 1.1 or 1.2 whatever number Alexandre wants to call it, will be an exponential improvement given the experience we've gained.

And lastly I'd like to announce I am starting a new Free Software company with a long term goal of providing Products and Services around Wine and ReactOS. The Bordeaux Group has today released Bordeaux for Linux which builds on the infrastructure laid out in Wine 1.0, Winetricks, IES4Linux and other tools and tries to wrap them all together in a kind of CrossOver Lite type of environment. The ultimate goal is to help refine Wine more and aide in ReactOS development to create a platform that is generic so that users wanting to migrate away from Windows will have a more broad range of choices, be it Wine on Linux and the Mac, ReactOS, or even CrossOver, PlayOnLinux,WineDoors or some other Wine package.

Some of the (limited) work we've already done we hope to be able to fold back in to Winehq. If your interested check it out http://www.bordeauxgroup.com

Thanks

-- Steven Edwards

Hi folks,

Again, congrats to everybody for the 1.0 release!

Now that I'm starting to recover from the shock of having actually shipped 1.0, here are a few notes on future development:

1) Code freeze is over, patches are accepted again. If you sent patches and they didn't get applied during code freeze, please rebase them against 1.0 and resend them.

2) Development will continue as usual in the git "master" branch. The 1.1.x development releases will be made from that branch every other Friday.

3) There is now a git "stable" branch, where only important bug fixes will be committed. The 1.0.x maintenance releases will be made from that branch whenever enough changes have accumulated to justify a release.

The process I suggest for the 1.0.1 release is as follows:

- all bugs should be fixed in the master branch first
- once a bug fix has been committed to master, the corresponding bug
report should be marked fixed, with the sha1 of the commit fixing it - the bug report should then be put into the 1.0.1 milestone.

This will allow me to periodically query for 1.0.1 bugs that are fixed in master and cherry-pick the corresponding commits into the stable branch.

--
Alexandre Julliard