World Wine News

This week, 607 posts consumed 878 K. There were 128 different contributors. 72 (56%) posted more than once. 0 (0%) posted last week too.

The top 5 posters of the week were:

1. 57 posts in 63K by julliard at winehq.org (Alexandre Julliard)
2. 41 posts in 37K by dank at kegel.com (Dan Kegel)
3. 40 posts in 29K by stefan at codeweavers.com (Stefan Dosinger)
4. 25 posts in 24K by dmitry at codeweavers.com (Dmitry Timoshkov)
5. 25 posts in 30K by rob at codeweavers.com (Robert Shearman)

Hello world! Okay sorry, I had to say it. As you may be aware your loyal WWN author Brian Vincent has been unable to write the WWN for some time now. I approached him a few weeks ago and offered my services to begin the weekly publications again. He graciously agreed and sent me lots of resources etc. to begin. And so, here I am.

A bit of shameless self promotion before I dedicate the rest of my life to providing you with quality Wine news. I'm Zach Goldberg. I work on a machine called BlueSata which is also my website and web server. I am a computer science student at the University of Pennsylvania. I have written some code for the Enlightenment (E17) project, and may perhaps in the future also send in some patches for wine. So enough about me, I'm boring. On with the wine!

wined3d: Use native shader limits instead of the maximum the driver can handle in software. This should prevent software fallbacks and it will allow for ps2.0/ps3.0 detection.
wined3d: Default to GLSL. This is safe because we now have proper ps2.0/vs2.0 detection.

It's rare for the WWN to highlight individual commits however this one by Roderick Colenbrander actually could likely have an impact on the average (gaming) wine user. This patch allows for natural detection of GLSL and in combination with the following commit , we now have the registry key "useGLSL" set to "enabled" by default. This should mean that for many of us playing games such as Elder Scrolls IV: Oblivion may no longer have to set that key explicitly!

We all know that of the many uses for wine, gaming is one of the more popular ones. But just how many actual gamers are there using wine to play their favorite games? Well, lucky for us Valve has begun to conduct surveys of the hardware and software configurations of people using their Steam system. They've even been kind enough to respond to emails and give us some data.

Valve regularly runs surveys of steam users, where they profile many different things about the hardware. They're nice enough to publish the results:

http://www.steampowered.com/status/survey.html

Some of these provide a way to detect Wine users. Everyone using the "Wine waveout" audio driver, for instance, must be a Wine user. Unfortunately, valve lumps all of these into "other" on the survey results page.

Worries about sampling bias aside (maybe Wine users are less likely to do the steam survey), if we had the raw data from Valve we could determine the actual percentage of Steam users playing through Wine.

Looking at the data we do have, we may be able to make a good guess from examining the video card driver name field. Excluding NVidia, ATI, and Intel leaves just over 4% of respondents using an "other" video driver like the Wine one. If even only a quarter of these "others" are using Wine, that still gives us 1% of the entire 10 million+ Steam user base, translating into hundreds of thousands of users.

As you can see, it's actually non-trivial to determine who uses wine simply from the drivers and such reported by the Steam survey. However we seem to have caught a lucky break with the sound driver:

More interesting is the "Video Card Driver Name":
Video Card Driver Name

nv4_disp.dll  10,269
53.43 %#####################################################
  ati2dvag.dll  5,060  26.33 %##########################
  nvd3dum.dll  2,698  14.04 %##############
  atiumdag.dll  571  2.97 %###
  ialmrnt5.dll  302  1.57 %##
  Other  319  1.66 %##

This identifies the DLL, and wine has none of them. So we'd show up in the
Other section here. Possible others in Windows space are matrox, sis and
other chips, as well as the generic vesa driver.

The best identification is the sound card name, or if Wine's display driver
shows up as winex11.drv

And as of November 24th we have the following update from Alfred Reynolds:

The numbers are now 0.13% of total reports coming from Wine users.

Some of you may be very upset at the lack of a wine 0.9.50 last week. Unfortunately many of the dev's were out stuffing themselves with turkey and hence a release last week made no sense. However, this week has come and we have 0.9.50:

    Wine 0.9.50 was released today, with the following main changes:

        * Completed I/O completion.
        * Improved user credentials management, including Mac Keychain support.
        * More Valgrinding.
        * Lots of bug fixes.

    Binary packages are in the process of being built and it may take a few
days for them to appear, but the source is available now. You can find out
more about this release in the announcement. Check out our download page for
packages for your distribution.

Kai Blin brings up the topic of planning out this summer's Google Summer of Code projects. The problem, he explains, is that projects were not extremely well defined and communication was not as good as it could have been. All easily solvable.

Hi folks,

from what we discussed at the last WineConf, we wanted to work on our procedures for the Google Summer of Code a little. I'm sending this email in hope to start some discussion about this, so we have it out of the way until the 2008 version is announced so we can talk about proposed projects then.

The goal of Wine's SoC procedures should be to get high-quality proposals that can be completed by the student proposing the project in the time allocated for GSoC, so both scope and difficulty should be checked. I haven't been on the mentoring side of things, but my understanding from the WineConf side of things was that we had some problems getting this right the past years.

I was thinking about strongly encouraging people to post their project proposal to wine-devel prior to applying, so more developers can have a look at it and see if it's doable or not and offer suggestions.

I know some projects did an introductory quiz to figure out the student's coding skills, I'm not convinced the knowledge needed for Wine can be tested in a quiz. What do you think?

Another thing that didn't turn out too well last time is that it was really hard to figure out what was going on during the summer. I have a few ideas on how we could address this.

Lots of other projects had their student write a weekly public progress report. I think we should require the same. This will probably help keeping people updated, and might help spotting problems early.

According to the wiki page, we already require a post-mortem report on the project, however I can't remember seeing much of those this year. We should make sure those are written next time. We might think of a better name for the report, post-mortem sounds like the project is dead after the summer, we want people to keep working.

Last year, some of the students set up a public git repo on repo.or.cz. I was thinking about making that a requirement for next year. This would allow people to review work in progress.

Comments? Kai

General response is that 'organization sounds like a good idea'. Maarten Lankhorst recommended that instead of a quiz to screen students, there be a requirement that they submit small patches.

I don't like the idea of a quiz as well, what would be a better test is to get a small patch into wine, perhaps adding a testcase to the component they want to work on. It shouldn't be big, but it proves they can get code into wine.

Gavriel State of TransGaming has been hanging around on one of wine's IRC Channels (#winehackers) and in a conversation with Kai Blin actually offered code for something TransGaming has already begun to implement:

Hi all,

On #winehackers the other day, kblin asked about whether TransGaming had a Direct Play implementation. The answer is that we have something that was worked on for a while but never completed. We have had some partial success with it in the initial connection stages, but never pushed it much beyond that.

Enclosed here is a patch to today's WineHQ git tree with our dpnet implementation in the hopes that someone finds it useful. Beyond ensuring that it compiles and links, it has not been tested at all with WineHQ.

Take care,
-Gav

Hi Gav,

Thanks for getting back with that one faster than I managed to remind you about it. I hope to get around playing with it later this week, I'm currently somewhat busy writing code I'm getting paid for. :)

Hi Kai, Sorry about that - looks like I hadn't in fact updated my git tree quite properly. Also, I left out a header file I think. Try this patch instead. Take care, -Gav

Dan Kegel has written in with a bit of an update on the status of Wine 1.0

[putting on tastemaster hat]

So far, 82 bugs have been nominated to be fixed for 1.0.
I checked a bunch of them, and so far most look
reasonable.  Some even look easy or have patches, e.g.
http://bugs.winehq.org/show_bug.cgi?id=5402

http://bugs.winehq.org/show_bug.cgi?id=5884

http://bugs.winehq.org/show_bug.cgi?id=7544

http://bugs.winehq.org/show_bug.cgi?id=7571

http://bugs.winehq.org/show_bug.cgi?id=9104

http://bugs.winehq.org/show_bug.cgi?id=10147


The list looks meaty enough that it's probably worth
folks going through and seeing what they can pick off.

Stuff that's silly or too hard - just skip it for now,
we'll defer those for later.
- Dan

Forgot to mention: https://wiki.winehq.org/WineReleaseCriteria has a handy link to a bugzilla query that shows the list of 1.0 bugs.

Courtesy of some very complicated patches introduced recently (for SecureROM) Wine will no longer build properly using GCC 4.0.X. Even as somebody who studies computer science the actual thread discussing the details of these patches and why they break compilation in certain versions of GCC is extremely complicated. However, if you dare, this is the link with all the juicy details.

Attention packagers: the default version of gcc on
many distros happens to generate Wine binaries which
make some copy protection schemes unhappy.
At the moment, gcc-3.3.x, gcc-3.4.x, and gcc-4.2.x are
known to work; gcc-4.0.x is known to not work.
Please check the compiler you use when building wine
packages and make sure it's one of the good ones.

To really check, find a retail copy of Photoshop CS or CS2
(not 7 or CS3) and install from cd-rom.  If it aborts silently
near the end without offering to activate the product, you
have an unsupported compiler, and users of your packages
might run into trouble with apps protected with safedisc.

See http://bugs.winehq.org/show_bug.cgi?id=10273
 for more info.
- Dan