World Wine News

• Bug fixes only, we are in code freeze.

I think we've gotten it about right. There has been a lot of infrastructure work that hasn't been all that user visible that means that Wine is far more robust and capable than it ever used to be.

Arguably, we should wait until the DIB Engine is done, so maybe we're even a few months early *grin*.

The interesting side note is that releasing a 1.0 is going to create a new burden for Wine - backwards compatibility. Historically, Wine developers have been free to make 'correct' changes, even if they broken many applications. With 1.0, I think we will be honor bound to constrain that, if only on a stable 1.X branch.

If I look back on my time with Wine (about 10 years now), this is the most exciting Wine has ever been. When I first started, the only thing you could *always* run was Solitaire. Other things could be made to work, but it took a lot of effort.

Contrast that with today when, with few exceptions, it's reasonable to hope that *any* application will work. And, in practice, a substantial fraction of applications do install and run. (I don't know what that number is; I don't have a good way to quantify it). The WineHQ ratings page suggests it's close to 75% run at least as bronze: http://appdb.winehq.org/browse_by_rating.php (I think that page over inflates things, but I think that 50% is not a bad rough estimate for applications that install and at least start to work).

The DIB Engine is the big one. Huw is hard at work on that, but it will have to be a post 1.0 thing.

Beyond that, we need to get .NET taken care of, and GdiPlus needs some love.

On the Mac side, the only really radical transformation will come from a Quartz driver - eliminating the use of X11 altogether.

That's a big, scary job, with a lot of testing requirements, so I don't think it's going to be particularly soon.

Other than that, I actually think the shift to 1.0 is going to be more trans formative than people realize. For example, having make test fail for most people is interesting when we're in alpha mode. But if we're shipping a release product I think it's nonsense, and we have to fix it. The work that Dan is doing with Valgrind is another such subtle, but important, change. If we can get oprofile and maybe some cxtest work into the mix, I think the whole approach for Wine can change.

I guess the short, user visible way of saying that, is that with Wine 1.0 I would hope that Wine would become less 'variable'; fewer occurrences of regressions from release to release. And that will be a big deal.

Well, what's beautiful about being open source is that we don't have to choose; if anyone has a passion for a given area, they can make it happen.

I think the core goal remains the same: get just about all application level (i.e. not hardware related) applications to install and run.

Yes, Wine is too ambitious, and what's worse, it's under appreciated. We're just like Rodney Dangerfield - we get no respect.

You show someone Wine running MS Office - which is a technological miracle, and the results of the incredible hard work of a small band of dedicated people - and they ho-hum, because it's something they see every day.

As far as keeping up, I'm not sure. I think so, but only because we're not so much keeping up with MS as we're keeping up with the ISVs.

In theory, at some point, all new apps will be 'in the cloud', and then Wine will become an interesting retro technology, right?

I would want Wine to have simpler debugging tools. That is, when application X fails, I want a simple way to go learn why. We can fix failures quickly when we understand them; all of our energy goes into understanding the failures, though. That alone, I think, would double our rate of progress.

For Linux, I want it to have 10x market share. Then the demand for Wine would be 10x greater...

Let me tap my heels together, and wish that:
When they hired David Cutler of Vax/VMS fame to write Windows NT that they had also gotten the same magic pixie dust that went into VMS documentation so that Windows had the same level of quality documentation that VMS had.

Gosh, I don't know; doesn't SuSE already bundle it, and it's trivial to get in Ubuntu, right?

I think the key for the distros is that they really want to emphasize native Linux programs, and I think that's healthy. If you can run a native Linux application, you really should, imho.

So providing Wine as an option lets them provide it, but still stick with the message that their distro is all you really need.

I don't have strong feelings on the matter. I like that the LGPL v3 tightens up the enforcement process (has specific mechanisms and timing); I think that's all good. But again, I don't feel strongly on it.

Good question. Actually, I don't know what Alexandre is planning here. Are we going to have a stable branch? Hmm. I don't really know!

Ah, I have a long list. But this is more of a question I muse on, which is: If I had a big bucket of money, what would I do?

And the reality is that a big bucket of money wouldn't solve the biggest problem - having talented Wine developers. It might help, but good Wine developers are very rare, and I don't know that we can force them into existence.

But there are a lot of things I *could* do that would help Wine:

I want make test to work perfectly on every machine. I want a perfect cxtest run for every freely downloadable .exe file on the net, and run against every single patch, so no patch goes in if it makes a regression. I want valgrind and oprofile also run routinely, and any bad results caught immediately.

I think it is good the way it has worked out now.

That doing more releases might have worked we see with CrossOver Office, which did releases regulary. However this would have required all developers agreeing on doing so, which would have been more difficult in earlier times.

Also, we have only two years ago or so reached the point where we could admit Wine to be "BETA" quality, so earlier releases would likely have been disappointing to users which later would have shied away even more.

The good thing with 1.0 is now that we have a chance to convince people that Wine is working and useful, and that further versions are not "broken" but will improve.

I would say that they should just try the program they fancy, or a program they run Windows for.

A friend of mine for instance tries all the MMORPG games he plays under Windows also under Wine, and I have to go and try to fix them (not always successful) before he goes playing the next one.

If they do not have any program the usually use, what about a fun Windows game. Today for instance I found that the Webcomic makers from Penny Arcade did a Game ... I downloaded it, installed it and played it under Wine, without any hacks necessary. It stuttered a bit and I usually do not like this realtime hack and slay, but it worked, out of the box! (http://www.playgreenhouse.com/ ) (And they have a Linux port too, I know ;)

.NET integration is one major thing which we need to implement. I see this with my Tax program that previously even had a Wine based Linux version but now no longer does since it is a mix between Win32 and .NET code.

Win64 is slowly coming and we will need to take that up too.

Don't forget Corel, but that was quite some years ago ;)

The group I belong to is probably the Distribution makers, working for Novell/SUSE. We are not driving Wine in any kind of direction, except perhaps just taking care of good integration into the distributions themselves.

We do not want to go all the way down to Windows kernel driver emulation. DOS support is not really necessary in my eyes, but Win31 support is. And yes, legacy applications are important too.

I do not think that we are too ambitious. Also regressions come and go, but the number of fixed bugs is higher than the number of regressions. And by adding more testcases we are making sure that regressions become less seldom and are easier to track down.

As for areas of improvement, people do things that they are interested in ... See the games support: People were interested in Games, started hacking and improving on it and so it gained momentum.

Or developers get paid to do stuff, like the CodeWeavers work on DCOM/RPC or Googles work across the tree for specific targeted applications.

Magically add .NET support. :)

Get rid of the stupid patents and royalty setups that hinder Multimedia Codec adoption.

Less Virus/Worm/Trojan/Zombie problems, which would help the whole internet.

Novell/SUSE bundles it in the community product (SUSE Linux / openSUSE) for over 10 years now, which will of course continue.

We also shipped CrossOver Office with a enterprise desktop distribution 4 years ago, but newer ones did not include.

For Enterprise products, yes there is a problem of lawsuits which might make most of the distributors afraid I guess. Also Distributors will point out that the native software they have is ready for all uses, and without a direct use for Wine it will be difficult to explain the costs.

Also up to now Wine was not really "supportable" in the way that people could call the distributor and get bugs fixed. This would have required contracts with companies like CodeWeavers and would have made the products more expensive.

I see no need to change the license and have not thought about it further.

It was however necessary to change from X11 to LGPL to avoid more than just the one major fork we had and so not to hinder development.

There will be process changes, but mostly for the 1.0 stable tree I guess. I can't really predict how Alexandre will do that.

The unstable tree likely will continue to be handled as before.

See above ... .Net support, even better games support, all Win32 applications running ... :)

I just wrote up an idea related to release management for post-1.0 wine releases. It's online at https://wiki.winehq.org/TimeBasedReleases Essentially, the idea is to release in March and September, in time for the April and October releases of Ubuntu.

For instance, following this strategy, we might plan to release wine-1.2.0 in September 2008 or March 2009.

The alternative is to propose a set of criteria that wine-1.2 needs to meet, and working until they are met, which is what we did for wine-0.9 and wine-1.0 (I think; it's kind of hard to tell).

I look forward to discussing this idea... perhaps we shouldn't bother to until after 1.0 is released, but I wanted to get it out early so the discussion can begin in time for us to move on it if we want to. - Dan

I don't think we should schedule our release schedule around Ubuntu's. Just because it's very popular (and possibly our most widely used target), doesn't mean we need to revolve around it. I'd say let's look at the 1.2 buglist (along with the 1.0's we can't fix), set a goal to get 1/2 of those fixed, test our 'supported' apps for regressions, and release then.

Also might consider waiting until 1.0's hit for a month or so and see what the biggest complaints are, and focus on fixing those for 1.2.

I'm against September, as it means we'll go into code freeze _again_ just before Summer of Code finishes.

While I agree that bi-annual releases sound like a good thing, I'm opposed to forcing it just to make Ubuntu's 8.10 schedule with 1.2.

Also, I'm not really sure what this'll mean in terms of features and bug fixes. We certainly don't want to keep people hanging without fixes for bugs for half a year.

We also don't want to slow down development more than needed.

Now, as you state on the wiki page, a bi-weekly release schedule is good for early adopters and developers, as it's centered on "Get my new cool feature in!" rather than on "Will this break Photoshop?". But, and I see you mention that yourself, "Will this break Photoshop?" is a really hard question to answer, especially for developers who don't own photoshop.

Bi-annual releases are good for people who already have their apps working, as prior to a release we probably should make sure nothing breaks. But as fixing new bugs sometimes is a bit hit-and-miss, only being able to try for the wider public once every six months isn't too great.

So assuming we manage to get wine test failures down to 0 during this code freeze, I'm happy to make sure none of my patches breaks anything there. If I can get a similar website for the apps we really don't want to regress, I'll of course try the same for that. But before we don't have that, I don't think it's a good idea.

Cheers,
Kai

Hello everyone,

My name is Dylan Smith, and I will be working on implementing tables in rich edit controls as a Google Summer of Code project. Any remaining time I have will also be focused on rich edit controls for this summer.

Forgive me for taking so long to introduce myself on the developers mailing list. I ended up going straight for the code as soon as my exams finished. I just finished my last year of Software Engineering at Carleton University which is located in Ottawa, Canada. I will be returning to Carleton University for my Masters after the summer.

I am thrilled that I am getting this opportunity to work on Wine for the summer.

Happy coding to you all,
Dylan

Hi, we are students from Department of computer science at Aalborg university. During this semester we were working on project on static analysis using the Coccinelle tool (http://www.emn.fr/x-info/coccinelle/) and Flawfinder (http://en.wikipedia.org/wiki/Flawfinder). We decided to search for bugs in Wine source code.

Our aim was to find as many bugs in Wine source code as possible but on the other hand to find real and dangerous ones. We solved some of the Janitorial projects and beside that we searched for common bugs.

We decided to deal with 2 of Janitorial Projects: Ignored return values and Memory leaks. Beside that searched for memory allocation without NULL checking. Then we ran some more scripts searching for not unlocking memory objects after locking them and searching for untested file descriptors. We also ran two tests looking for not dangerous problems: searching for unused variables and searching for pointers comparison to 0 instead of NULL.

All the test were run on Wine 0.9.57 version.

Inhttp://www.cs.aau.dk/~tomecek/scripts.tar.gz we present the list of the most obvious bugs in 'diff' format and Coccinelle 'cocci' scripts in Semantic Patch Language (SmPL) used for bug searching.

* Ignored return variables
We found 115 function callings without checking the returned value which we considered to be possibly dangerous. In many cases we think that the behaviour could be dangerous but we need some information about the code.

In 'ignored_return_values.diff' we present some examples of code where the returned value should not be ignored but it is so.

* Unused variables
This was one of the Janitorial Projects. This issue is not dangerous but it helps to clean the code and make it more readable. All of the variables could be removed using \textit{diff} file. We found 18 matches and all of them were true positives.

Beside that we find some possible security bug with 'Flawfinder'. Here is the output:

wine-0.9.57/programs/taskmgr/perfdata.c:292: [4] (access)
ImpersonateLoggedOnUser:
If this call fails, the program could fail to drop heightened privileges. Make sure the return value is checked, and do not continue if a failure is reported.

* NULL comparison
Sometimes developers use comparison of pointers to zero instead of NULL. This is not critical bug but the \textit{gcc} compiler warns against such using.

In this case we were able to change all the zero comparison to NULL variant using Coccinelle. We found 176 matches and all of them were corrected automatically.

* Memory allocation
Using both functions for memory allocation - 'malloc' and 'HeapAlloc' - requires NULL checking of the returned value to be sure that the allocation was done correctly. We matched 598 possible bugs.

In 'memAlloc.diff' we send to you 10 examples of bugs we have found.

* Memory leaks
This searching was part of one of the Janitorial Projects. We were looking for memory allocations where the pointer to the allocated memory is lost or forgotten without freeing the memory.

We matched 13 of them as true positives.

In 'memLeaks.diff' we send to you 5 examples of most obvious problems.

* Object locking
We were searching for locking object with 'GlobalLock()' without 'GlobalUnLock()' for unlocking. If the object was locked then it has to be unlocked to prevent deadlocks when some process or thread is waiting for unlocking of this object. We have 2 true positives.

* Descriptors
In this test we were looking for unchecked descriptors returned by fopen(), fdopen(), freopen(), open(), creat() and pipe() or for wrong check of this descriptors. fopen(), fdopen() and freopen() functions return in the case of failure 0 but the rest of these functions return -1. Sometimes programmers use it in wrong way and sometimes they do not check it anyway.

We matched 3 wrong usings.

If you are interested in our work or if you want the full list of bugs we found let us know.

Regards,
Bertrand Dechoux,
Youenn Corre,
Jaroslav Tomecek