Wine Traffic #235 For 13�Aug�2004

By Brian Vincent

Table Of Contents

Introduction

This is the 235th issue of the Wine Weekly News publication. Its main goal is to read Dilbert. It also serves to inform you of what's going on around Wine. Wine is an open source implementation of the Windows API on top of X and Unix. Think of it as a Windows compatibility layer. Wine does not require Microsoft Windows, as it is a completely alternative implementation consisting of 100% Microsoft-free code, but it can optionally use native system DLLs if they are available. You can find more info at www.winehq.org (http://www.winehq.org)

Mailing List Stats For This Week

We looked at 157 posts in 562K.

There were 57 different contributors. 32 posted more than once. 23 posted last week too.

The top posters of the week were:

1. News: iTunes Screenshot

7�Aug�2004�-�13�Aug�2004 (1 post) Archive Link: "News"

Topics:

People: CodeWeavers,�,�codeweavers,�Aric Stewart,�Jeremy Newman

Last week CodeWeavers announced they had parts of iTunes working with CrossOver Office but the screenshots were somewhat lacking. The initial iTunes screenshot (http://www.codeweavers.com/images/appdb_shots/iTunes_2004020601_shot.jpg) didn't really show off a Linux desktop. This week Jeremy Newman posted another screenshot (http://www.codeweavers.com/images/appdb_shots/itunes_20040803.png) that's much prettier. Keep on reading below for some news on work Aric Stewart is doing to get USB devices working to enable full iTunes support.

2. Doom3 & Wine

6�Aug�2004�-�7�Aug�2004 (8 posts) Archive Link: "DOOM 3 misses some opengl32 wgl* and Cg functions"

Topics: DirectX

People: Shachar Shemesh,�Uwe Girlich,�Lionel Ulmer,�,�Ove K�ven,�News

Pop quiz: what's always the most anticipated game under development? Answer: the next one to be released by id Software. For those of you living in a senseless void, id Software (http://www.idsoftware.com/) happens to be responsible for thousands upon thousands of hours of lost productivity in the workplace. (Or, as I used to like to tell my boss, it was responsible for keeping me at my desk after hours.) They also happen to be ardent supporters of open source software; many of their games have been released (http://www.idsoftware.com/business/technology/techlicense.php) under GPL licensing. They also support open interfaces, such as GL rendering rather than DirectX and as such have been able to release Linux versions of their games for years. Last week saw the release of Doom 3 (http://www.doom3.com/) and the eye candy is simply marvelous. The Linux version isn't available yet, but some people have reported it's possible to run the Windows version with Wine. Shachar Shemesh translated a page describing how to run Doom3:

http://linux.israel.net/linuxgames/modules.php?name=News&file=article&sid=55 (http://linux.israel.net/linuxgames/modules.php?name=News&file=article&sid=55)

Translated into English:

There is also a screen shot there.

So, if you want me to relay any questions to the user regarding how he did it? :-)

I decided to do a bit of research into this, and found some related bits (in English) at linux-gamers.net (http://www.linux-gamers.net/modules/news/article.php?storyid=386) and Linux Games (http://www.linuxgames.com/news/feedback.php?identiferID=6790&action=flatview) . Not too surprisingly, a lot of people have been working on getting it going with Cedega (WineX). However, reports of it working with Wine are very encouraging. Uwe Girlich reported more details on what he found:

I just tested out DOOM 3 (no-cd-cracked version) with the current Wine (CVS from 1 hour ago) and found the following problems on the game console:

Are these wgl* function difficult to implement?

Almost all computer terminals in the game show static black & white noise (instead of some animated computer screen image). I suspect, that this has something to do with the missing 'Cg' support in Wine (DOOM3 cannot find cg.dll & cgGL.dll).

On the other hand, the rendering paths (r_renderer nv10, nv20, arb, and arb2) are all more or less working (besides the noise and the too bright lighting in nv10).

Lionel Ulmer recognized the calls that were failing. Some of them he wasn't sure how to map to GLX extensions, but some he did, " This is part of one of my 'todo' project: adding support for PBuffers in the WineHQ tree (I once started to study both the GLX and WGL extension set to see how it could be done). Now that I know one 'high profile' application that needs them, maybe it will motivate me more :-)"

Ove K�ven had some tips (http://www.winehq.com/hypermail/wine-devel/2004/08/0086.html) on how to implement the functionality. Apparently the missing stuff is enough to make the gameplay poor since the "computer screens" Uwe described are an integral part of the game.

3. USB Support (con't)

10�Aug�2004�-�11�Aug�2004 (3 posts) Archive Link: "Re: USB?"

Topics: IO, Architecture

People: Aric Stewart,�Rolf Kalbermatter,�

To followup on the USB support mentioned above (and discussed last week in WWN #234 (http://www.winehq.com/?issue=234#USB%20Support..%20or%20Lack%20Thereof) ), Aric Stewart came back this week with a description of the work he's doing:

Sorry for not getting back to you all faster, i was at Linux World and such.

Yup i am looking hard at the setupapi device calls and cfgmgr to try to get some usb support targeted toward the iPod. I have made some progress and am beginning to have an understand of how usb is handled in windows (Win2K is my target version) and how to try to handle it in Wine.

I do have some difficulty figuring out how Win2K is translating vendor and product ids into class and interface guids. The documentation reports that they look them up in inf files, however i am finding that not to be true. I am suspecting that some may be hardcoded in the usb support somewhere.

I am probably not anywhere close to having anything clean enough to start commiting to Wine. But if you really want to help we may be able to work together on some stuff.

With regard to finding vendor and product ID's:

Wouldn't that be something which would be put in the registry somehow for the well known IDs and for the rest I really assume the device detection routine does check for all .inf files it finds on the devices currently configured to be searched. If you look at PCI and USB inf files you will notice that the manufacturer and device ID are actually encoded in the key names which are to be added to the registry. That encoding does not always seem to be equally consistent, I've seen at least two different types, but it is obviously there.

One entry for instance for the Logitech PageScanner would be

This is partly extracted from a logiscan.inf file on my W2K system.

Aric pointed out that even if this was a rule there were definitely exceptions, " Right, that is the theory but something else must be happening also. For example with the iPod (what i am concentrating on) the vendor id is 0x05ac which somehow translates to VEN_APPLE and the product id of 0x1201 somehow translates to PROD_IPOD however i cannot find any inf file or registry key that would show that transition."

4. DSound Mixer Speedup

11�Aug�2004�-�12�Aug�2004 (2 posts) Archive Link: "Re: dsound mixer speedup"

Topics: DirectX, Multimedia

People: Robert Reif,�Joerg Mayer,�

Robert Reif posted a patch to speed up the mixer in the DirectSound code. He noted in his changelog entry there was a tradeoff, " Speed up mixing and unmixing by moving sample size and buffer wrap tests to outside the loop. The code is not as compact or pretty but it should be faster. "

Joerg Mayer wondered if moving some lines of code around really resulted in an optimization since GCC may automatically do it at compile time. Robert provided some real world statistics to back up his claim:

For both 8 and 16 bit samples (no optimization) the new code executes in about 48% of the time of the old code (twice as fast).

8 bit -O3

16 bit -O3

This is with a 32k buffer and a 1k chunk size.

5. c:\\windows is not accessible Error (con't)

11�Aug�2004�-�12�Aug�2004 (20 posts) Archive Link: "config converting problem"

Topics: Configuration

People: Henning Gerhardt,�Vincent Beron,�Mike Hearn,�

Last week we described a problem where people couldn't access a fake windows drive (WWN issue #234 (http://www.winehq.com/?issue=234#c:\\windows%20is%20not%20accessible%20Error) ). This week Henning Gerhardt wrote in with a pretty clear example of it occurring:

a friend of me would update the wine package (20030813) from his SuSE 9.0 system to the latest availabe package for this system (20040716). After the update following error message appears on each start of wine:

After my advice to get me the content of his "~/.wine/dosdevices", he send me the following output:

I think the problem is the ${HOME} variable which is not parsed / correct replaced during the convert process.

Have anyone an idea to solve this problem ? Or is it only a problem of the SuSE distribution ?

Vincent B�ron then diagnosed the problem and explained:

It's not SuSE specific. It's a problem from upgrading from a (somewhat) old to a newer Wine version.

Wine used to understand ${HOME}-style vars in config. This was then changed to %HOME%-style vars. Current Wine doesn't use config anymore for drives but uses dosdevices, which is created on the fly from config if it doesn't exist.

So the problem comes from 2 changes, with only the latter being acted on automatically.

If you want to fix it, the simplest way would be to create the following symlinks in ~/.wine/dosdevices:

Mike Hearn expressed concern this was happening, " I'm not sure what to do about this, except maybe to add back in support for ${HOME} style vars. It's clear that people are "using" (at least, installing) much older versions than we anticipated."

Vincent clarified that, " The problem comes when upgrading from an old version (still supporting ${HOME}) to a newer version (supporting either %HOME% or dosdevices). The older version, by itself, still works correctly."

Mike also suggested just blowing away ~/.wine and starting over with a clean slate. Of course, the side effect is pretty dramatic - you need to reinstall programs. A lot of discussion ensued about making upgrades to wine as transparent as possible. Not a whole lot was decided, but everyone seemed to agree that it was something that needed to be kept in mind.

In a side note, there was another discussion initiated by Adrian Willenbucher who didn't want to see Wine lose it's config file. A plan in the works for many years now is to move all the configuration into the registry. Mike Hearn pointed out that Wine's registry is in ASCII format and easily edited by your favorite text editor. The syntax itself isn't a whole lot different than the existing config file. The huge benefit is that Wine's registry reading/writing code is pretty stable now and it's worth using one set of functions for handling all that stuff. Since the registry is accessible via Win32 API's it's possible to write graphical configuration tools (such as winecfg) using Winelib.

6. Multiple X Session/Display Instances

10�Aug�2004�-�11�Aug�2004 (4 posts) Archive Link: "Different X Displays and Wine"

People: Boaz Harrosh,�Alexandre Julliard,�,�Codeweavers

Boaz Harrosh ran into a problem with a unique set up:

I'm trying to connect and run a remote X session from 2 different machines and I fail to run Wine applications.

[Q] Is it at-all possible to run Wine on 2 different $DISPLAY s, or is the X-Server a Wine-Server resource. Will using a different user help? Will using desktop mode help? Has any one been successful with letting different network users connect and run Windows Apps under wine? How did they Setup wine? How does Codeweavers do it with their Server Product?

Alexandre described a couple of different workarounds, " That's not supported at the moment. You can run apps on two different displays by using a different WINEPREFIX for each, so that they don't share the same wineserver. Using different users would work too."

Sharon And Joy

Kernel Traffic is grateful to be developed on a computer donated by Professor Greg Benson and Professor Allan Cruse in the Department of Computer Science at the University of San Francisco. This is the same department that invented FlashMob Computing. Kernel Traffic is hosted by the generous folks at kernel.org. All pages on this site are copyright their original authors, and distributed under the terms of the GNU General Public License version 2.0.