Wine Traffic #227 For 18�Jun�2004

By Brian Vincent

Table Of Contents

Introduction

This is the 227th issue of the Wine Weekly News publication. Its main goal is to dig holes in the ground. 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 158 posts in 928K.

There were 53 different contributors. 23 posted more than once. 18 posted last week too.

The top posters of the week were:

1. News: Wine-20040615, Interview with Lionel Ulmer, CXO 3.0.1

12�Jun�2004�-�18�Jun�2004 (2 posts) Archive Link: "News"

Topics: News

People: Alexandre Julliard,�Jeremy White,�Codeweavers,�LinuxDevCenter.com,�CodeWeavers,�,�codeweavers,�Microsoft,�Lionel Ulmer,�News

Alexandre is back from vacation. After steamrolling through a patch backlog he put out Wine-20040615 on Tuesday:

WHAT'S NEW with Wine-20040615: (see ChangeLog (http://cvs.winehq.com/cvsweb/wine/ChangeLog?rev=1.84&content-type=text/x-cvsweb-markup) for details)

As always, head over to Wine's download page (http://www.winehq.com/site/download) to snag a copy.

We published an interview with Lionel Ulmer (http://www.winehq.com/?interview=15) this week. Lionel is one of Wine's DirectX gurus and has been involved with Wine for almost six years.

CodeWeavers announced (http://crossover.codeweavers.com/pipermail/announce/2004-June/000024.html) a bugfix release of CrossOver Office, version 3.0.1. The primary fixes are aimed at Fedora Core 2 users. Jeremy White made it clear in his announcement that this is just a minor release, " Please don't feel that you have to upgrade to this release; if everything is working well (and you're not on Fedora), sitting pat is a perfectly fine choice."

CodeWeavers and Lycoris have teamed up (http://www.codeweavers.com/site/about/general/press/?id=20040616) to offer a product that bundles CrossOver Office with the Lycrois Desktop/LX distribution. " Lycoris will also begin selling CrossOver Office as a standalone product to the public via all Lycoris wholesale and retail outlets as well as its Lycoris store."

Over at O'Reilly's LinuxDevCenter.com there's an article titled Windows Compatibility for the Linux Desktop (http://www.linuxdevcenter.com/pub/a/linux/2004/06/10/win4lin.html) . It briefly mentions both Wine and CrossOver Office as a way to run Windows applications on Linux. However, the article is very specific: it's goal is to get Microsoft Project running. The best solution they found to do that is Win4Lin. Of course that means, " you'll need a licensed copy of Windows to use" . They admit that CrossOver Office would have been a nice solution, " CodeWeavers doesn't offer support for Project. If it had, Crossover would have been a good choice: it's fast, resource-light, and inexpensive "

2. Mouse Handling

16�Jun�2004�-�17�Jun�2004 (6 posts) Archive Link: "Re: dlls/dinput/mouse.c warp handling"

Topics: DirectX, IO

People: James Dean Anderson,�Lionel Ulmer,�Max,�

James Dean Anderson posted a patch to improve mouse handling in some games:

this is a more complete version of my mouse patch in which I tried to remove this funny mouse-warping-stuff.

the mouse feels much better this way, but I am new to wine and maybe I missed something important and/or did not remove the mousewarping cleanly.

Lionel Ulmer didn't like the patch at all:

Errrm, do you understand exactly what you remove and why it was in the code ?

Basically, if you remove mouse warping, when you play games like Quake, you will only be able to turn to your right (or left :-) ) for a fixed amount... I.e. up until the point where the mouse will hit the right border of the window. I agree though that 2D games (like StarCraft or others) will feel a LOT better with a patch like that, but it's plainly wrong.

The only way to fix this is to sometimes warp the mouse back in the middle of the window (or to use DGAMouse (or to write a new X11 extension :-) )).

James admitted he didn't know what it was but asked for an explanation to help understand better:

There are several things in wine I don't know yet (eg what does GEN_EVENT do exactly / what are these critical-sections / etc.). But I think doing mouse-warping in 3 states and across different functions is much to complicated and while it works great in MaxPayne, it behaves strangely in WWIIOL.

I tried to do it in a simpler way.

Maybe I'll just try to understand wine a little deeper and post a more elaborated patch later.

Sound and joystick don't work too well in WWIIOL too (the joystick seems to send random data / I get only 1 channel of the sounds) so there's still a lot to do.

Lionel described how the mouse handling functioned:

Well this is related to the way DInput works: you have two ways to get informations from your devices, either you get an immediate picture of the device state at a given time (GetDeviceState) or you can get all the individual timestamped events that occured since last time you queried the device (GetDeviceData).

So GEN_EVENT simply queues a hardwware event into the queue that can be queried via 'GetDeviceData'.

The critical sections are here because you can have one thread queuing events (Wine's hardware event thread) while another (the game) can access the data, which means you need to protect against concurrent usage.

The warping in three states has been disabled for a long time now (it is only enabled if you #define MOUSE_HACK). It's an idea that worked once, but not anymore due to mouse event compression in some core part of Wine's input handling. The idea was that, basically, as the fact of warping the mouse WILL generate an X11 event for you, you could detect when the warp was actually done by checking when the ext mouse position corresponds to your warp position. Which would prevent some 'glitches' if you got a queued X11 event back from before the warp buf after you issued the warp command to the X11 server.

As to doing it only in the 'mouse even hook' I agree that it is cleaner that way (I missed this line when checking your patch so I thought that you removed warping completely :-) ). The only problem here is that you may have a LOT more warps done that way than in the previous way. For example, if X11 generates 10 X mouse events for each game 'frame', you will warp your mouse 10 times more with your code than with the current one (which only warped the mouse when the game actually queries the device).

But the main way to rework this would be to put the complete warping stuff in the X11 driver (as the way it's done now is fundamentally flawed for some games).

Note also that it would be much nicer to do a 'rectangle' warp instead of a 'point' wrap: do not wrap on each mouse event, but only when the mouse goes out of a centered rectangle which would be about half the size of the screen. This would have the advantage of smoother mouse movements as it would minimize a lot the number of warps.

And DGAMouse support / X11 extension writing would be the other way :-)

James thanked him for the explanation.

3. Doc Update & Critical Section Explanation

16�Jun�2004�-�17�Jun�2004 (6 posts) Archive Link: "Re: dlls/dinput/mouse.c warp handling"

Topics: Architecture

People: Mike Hearn,�

As an answer to part of James' question above, Mike Hearn described what Wine's critical section handling was all about:

I bugged Newman yesterday and because he's a total rockstar he fixed the bug in the doc generation script, so the latest developer guide is now on the net:

explains the Wine multi-threading in more detail than you probably want, however if you read the first section it may help. Basically a critical section is a mutex (or MUTual EXclusion): when one thread has entered the critical section all other threads that try to enter queue up at the entrance until the thread currently inside leaves.

This allows you to prevent multiple threads from running the same piece of code at once. It's essential for things like linked list manipulation. Because the entirety of Win32 is thread safe you will see this sort of thing all over the place.

If a thread deadlocks on a critical section (ie is queued up waiting to enter for a long time) you will see a message like this:

The ? means the critical section is unnamed. Virtually all Wine internal sections are named so you can identify them, so ? normally means the section was created by an application.

4. Nuking Wineinstall

13�Jun�2004�-�15�Jun�2004 (3 posts) Archive Link: "Do we still need wineinstall?"

Topics: Configuration

People: Mike Hearn,�Dimitrie Paun,�

Over the past few months some changes have been made behind the scenes to have Wine use some sensible default configuration values. For example, the filesystem rewrite removed the need for all the drive settings. Mike Hearn wanted to know if it was time to begin making more obvious changes to Wine's configuration:

I've been running without a config file for a while now, and have fixed various misc bugs related to that as I go - I'm sure there are some more in there, but as the config file is destined for eventual doom anyway I am wondering if we still need wineinstall at all?

Currently, it's possible to use Wine quite succesfully just by doing a standard ./configure, make, make install. When you run wine for the first time wineprefixcreate will be used to setup ~/.wine, merge the registry, create the fake windows drive and so on. The only piece you don't get is the default config file, but that doesn't seem to make much difference any more. At least, the defaults should be in the code not the config file as people never upgrade that bit anyway :)

So - do we still need it?

Dimi thought it might be time, " You have my vote to nuke it :) (getting rid of it is on the 0.9 TODO BTW) "

It still exists in the latest Wine snapshot that came out this week, but perhaps by next month Alexandre will have removed it.

5. Photoshop With No Config File

16�Jun�2004 (3 posts) Archive Link: "[PHOTOSHOP7] not installable, OS not supported, for NT4 service pack >= 6a"

Topics: Configuration, Fixes

People: Luca Capello,�Mike Hearn,�

Luca Capello followed Mike's suggestion and tried out running some applications without a config file. He reported a problem with Adobe Photoshop 7.0:

'Adobe Photoshop 7.0' can't be installed: the problem is grave, as the installation process doesn't start at all.

I can see the 'Photoshop 7' logo window, but then another window appears with this message:

And pressing OK causes nothing, I mean, I don't need to press OK to have 'wine' quitting: I can leave the message window open and continue to use the 'gnome-terminal' with no problem.

Again, with the 'fake_windows' provided by the 'WineTools' [2], I can install 'Photoshop 7.0' with all the options (included 'ImageReady'). The only problem I get is an error creating the icon set, but pressing 'OK' lets the installation process to finish cleanly.

Solutions?

Mike quickly diagnosed the problem, " This is probably because we default to using DLL linkage heuristics in the no config file case. These are frequently wrong, most people just set their config file to default to Win98. I sent a patch to create a new "auto" version to restore the old behaviour and set the default version to 98, does it help?"

Luca reported success with the patch.

6. Games Testing Update

11�Jun�2004 (1 post) Archive Link: "Game Testing Update - 20040505"

Topics: Testing

People: Mike Kost,�

Mike Kost took the time to put together some nice tests of various games with Wine. He provided links to demos and opened Bugzilla tickets (http://bugs.winehq.org) on things that didn't work:

Here a continuation of my game testing efforts. Same rules still apply in my efforts: All games tested are freely available as demos or F/OSS games on the Internet and they don't work right. I know 20040505 is showing its age, but there isn't a 200406xx yet.

Since my last report:

Austerlitz Summary

Bug #2276 is newly filed and the unhandled exception error is no longer present. There is still a screen redraw error

Full report:

Dominions II

No noticable change. Dominions II still has screen redraw errors and mouse errors.

Full report:

Remote Assault

Remote Assault has started running but has several refresh/redraw errors. There are several new 'err:ddraw' messages:

and

Full report:

7. Systray Patch Update

11�Jun�2004 (1 post) Archive Link: "Game Testing Update - 20040505"

Topics: Testing

People: Mike Hearn,�

Mike Hearn maintains a patch that allows apps to dock in the system tray. He went through and updated his patch (http://www.winehq.com/hypermail/wine-devel/2004/06/att-0270/01-systray2.patch__charset_UTF-8) and explained what was stopping it from being committed to CVS:

This version is resynced against CVS HEAD, and now does a ShowWindow in the right place (just after the embed notification not in some random WM message).

This won't be merged so I'm sending it to wine-devel not wine-patches. Getting it merged is blocking on either somebody giving me example code for [un]marshaling an HICON into a block of memory or (best fix) images being moved into the wineserver. This is on Ulrichs todo list but if anybody wants to beat him to it, go ahead, it's still some time off yet.

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.