Wine Traffic

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

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 didn't really show off a Linux desktop. This week Jeremy Newman posted another screenshot 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.

DirectX 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 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 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 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

Translated into English:

War games: Yes, it's true, Wine can run the new DOOM3

Several days ago I installed Mandrake 9.2 and was very impressed with Wine. This little program really does wonders. So I said to myself "it can run small Windows apps, but there is no way it can run Doom 3".

I did this:


cd /mnt/win_f/Doom3

and wrote "wine Doom3.exe", and what did my eyes see?

Yes, it is Doom3 running on my computer!!! And with pretty nice graphics Linux should not be ashamed of, to boost! Only one little detail - the in games movies won't work. It probably has something to do with Windows' Direct X.

So there you have it. I hope that it will work for you as it has for me!!!!

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 and Linux Games. 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:


Couldn't find proc address for: wglSwapIntervalEXT

Couldn't find proc address for: wglGetPixelFormatAttribivARB

Couldn't find proc address for: wglGetPixelFormatAttribfvARB

Couldn't find proc address for: wglChoosePixelFormatARB

Couldn't find proc address for: wglCreatePbufferARB

Couldn't find proc address for: wglGetPbufferDCARB

Couldn't find proc address for: wglReleasePbufferDCARB

Couldn't find proc address for: wglDestroyPbufferARB

Couldn't find proc address for: wglQueryPbufferARB

Couldn't find proc address for: wglBindTexImageARB

Couldn't find proc address for: wglReleaseTexImageARB

Couldn't find proc address for: wglSetPbufferAttribARB

GL_ARB_texture_non_power_of_two not found

GL_ATI_fragment_shader not found	(this is expected, I have a nvidia card)

Cg not available.

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 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.

IO Architecture

To followup on the USB support mentioned above (and discussed last week in WWN #234), 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


%USB\VID_046D&PID_040f.DeviceDesc%=Model.PageScan_USB,USB\VID_046D&PID_040f
 

USB\VID_046D&PID_040f.DeviceDesc="Storm Technology - Logitech PageScan USB"

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.

DirectX Multimedia 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

75% of old code (1.5 times as fast)

16 bit -O3

50% of old code (twice as fast)

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

Configuration

Last week we described a problem where people couldn't access a fake windows drive (WWN issue #234). 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:


Warning: the specified Windows directory L"C:\\Windows" is not accessible.


Warning: the specified System directory L"C:\\Windows\\System" is not accessible.

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


lrwxrwxrwx 1 julian users 28 10. Aug 18:50 c: -> ../%HOME%/.wine/fake_windows

lrwxrwxrwx 1 julian users  9 10. Aug 18:50 y: -> ../%HOME%

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:

ln -s ../fake_windows c: ln -s /home/julian y:

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.

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.

I connect from Machine M1 using ssh -X (or -Y) run a wine app all is very well.
I connect from another Machine M2 using ssh -X using the same user. The second instance fails with:
Needless to say that if I exit the Wine application on M1 than M2 will run with out any problems.

[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.