Kernel Traffic
Latest | Archives | People | Topics
Latest | Archives | People | Topics
Latest | Archives | People | Topics
Home | News | RSS Feeds | Mailing Lists | Authors Info | Mirrors | Stalled Traffic

Wine Traffic #285 For 29 Jul 2005

By Brian Vincent

Table Of Contents


This is the 285th issue of the Wine Weekly News publication. Its main goal is to synthesize. 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

Mailing List Stats For This Week

We looked at 243 posts in 861K.

There were 76 different contributors. 45 posted more than once. 28 posted last week too.

The top posters of the week were:

1. News: Jeremy White Interview

23 Jul 2005 - 29 Jul 2005 (1 post) Archive Link: "News"

Topics: News

People: Linux MagazineJeremy WhiteNews

Linux Magazine has a good interview with CodeWeaver's Jeremy White. There's a lot of interesting stuff in there, such as Longhorn, CXTest, and DRM issues. From the interview:

LM: So, first of all, give us a little background on the Installer Challenge.

Yeah, and basically the challenge is that we're trying to take Wine to that next level, we have for the last several years, really focused on a fairly small footprint of applications, making those work well and being glad and hoping that other things would work as well, collateral damage, as I like to call it.

Now what we're doing is taking the next step, and that is taking the first step towards taking Wine to the promised land, where we want it to be, which is where it runs everything and the first step is before you can try an application, you've got to be able to install it.

What we're doing right now, is we've spent a great deal of energy over the last year, sort of a lot of unsexy, dirty, nasty, grinding work that has the very sexy, exciting work that has the result that we believe many applications will install, and we believe that those that won't install will be very easy to get install.

We're very hopeful that with this, if we can get some community participation and community help that we can go from right now, where you have a 50-50 chance having an app install, maybe a bit less than that, to you're pretty sure that your app will install.

2. MSHTML Update

28 Jul 2005 (1 post) Archive Link: "Use Gecko to render HTML"

Topics: Status Updates

People: Jacek Caban

Work continues on MSHTML for Wine. For those of you just joining us, Jacek Caban has been working for several months on implementing this DLL. Basically it's the web browser behind Internet Explorer. Jacek has put together a pretty good description of everything on the wiki under MozillaIntegration. Jacek posted a large patch this week that got it closer to being a reality and explained how it was implemented:

I've sent a patch that makes MSHTML use Gecko to render HTML. Unfortunately, it uses Windows Gecko, not Linux one. Alexandre wrote me that it's impossible to get perfect support for XEmbed container, so, although my implementation was enough for Gecko, it can't go to CVS and I should use Windows one. So, as of now, support for the Linux version went into trash and I've sent this patch. Well, I don't give up with Linux version, I have another idea, but that's not for the nearest future. One plus is that the Windows version is much simpler...

Now it's time to write about this patch. For now it can use Gecko installed with Mozilla Suite or Mozilla ActiveX Control - it could use any Gecko-based product, but we have to be able to search for it (every Gecko-based product has its own registry settings for Gecko path). I'm planning to add Firefox support, but it doesn't work yet and I have to find why. If you think there should be support for any other application, please let me know. As our shdocvw still uses Mozilla ActiveX Control, I think it should be preferred (it's the first one on the search list and it's smallest). In future, when we'll implement shdocvw on top on MSHTML and get rid of Mozilla ActiveX Control dependency, I think it will be better to have a package like wine-gecko with an installer, downloaded automatically when needed (well, not automatically in MS sense, user will be informed about it ;-) ). We need a very limited version of Gecko, so it will be just small package.

What does this patch change? You may see IE working on Gecko engine! Not much of its functionality is implemented yet, but a HTML document is displayed. Soon there will be more! To see how it works for your program, probably you will have to set shdocvw to native (and usually urlmon, maybe wininet) and mshtml as builtin.

So, instead of a native Linux component using XEmbed we've got a Windows Gecko rendering engine. Hopefully an easy way to package this will be created to make it Just Work on Linux. The end result from a user perspective will hopefully be the same. Then again.. who knows.. maybe Jacek's other idea will work out.

3. Force Feedback

28 Jul 2005 (6 posts) Archive Link: "Re: DINPUT: Detect force feedback joysticks (FF #1)"

Topics: DirectX

People: Daniel RemenakAlexandre JulliardAnssi Hannula

Daniel Remenak started working on an area no one else has tackled yet - force feedback joysticks. His third patch had a nice description of how everything works:


This patch is exactly like try 2 except that this one actually works.

Changes from try 1:

  1. Configure check has been changed from a custom compile check to an AC_CHECK_MEMBERS. I presume this is what Alexandre meant by "please use the existing macros for checking structure fields;" if not, please clarify.
  2. An additional runtime check has been added to catch the case that it is compiled on a kernel with full FF support but run on one without it. In this case, the number of simultaneous effects query will fail, and the joystick will not be reported as FF. The #ifdef is still necessary to catch the opposite case.
  3. Primary FF detection code has been moved from GetCapabilities to Acquire. Since the tests are getting more complex it's best to only run them once, and store the results for use elsewhere.

To recap, this patch basically adds three things:

  1. Configure checks for the availability of a new enough linux/input.h to support force feedback. This pretty much means any kernel 2.6 or kernel 2.4.x with the ff patchset found at Some of the structures were changed without changing the version define, so this check is necessary; although these structures are not yet used they will be in later patches, and it's best not to report that the joystick is FF unless it can actually handle FF effects.
  2. The linuxinput dinput joystick driver tries to open the device in read/write mode, and falls back to read-only (with no ff support) if it fails.
  3. The device is queried for the EV_FF capability bit and ffbits is filled with the specific supported effect types. If that all goes well, DIDC_FORCEFEEDBACK is added to the device flags.

Autoheader and Autoconf will of course need to be run after this patch is applied.

When version #1 of the patch came out, Alexandre had a question regarding the configure checks Daniel had created, " Why do you need to check the structure since you are not using it? Shouldn't you simply do a #ifdef on the ioctl code or whatever else that you use and may not be defined?"

Daniel replied that it was to work around a kernel problem:

Executive summary: In order for effects to be played, the correct ff_effect structure will need to be present; if you can't play the effects it's better not to detect the joystick as FF, because it's really not.

The structure is not used *yet*, but will be. There was an older version of force feedback code before (in some of the stock 2.4 kernels) which had some of the same features (such as the EV_FF bit), but has incompatible structures, and afaik there were never any force feedback drivers written for it. The newer interface has working iForce (logitech, guillemot, et al) and MS sidewinder drivers written for it, so that's the one I was targetting. You can see them side by side if you have linux/input.h from an unpatched late 2.4 kernel and a 2.6 kernel.

Alexandre thought that was a good start, " Well, if the structure is required for the compile that's OK; but note that you still need to check for the proper features at run-time, just because the structure was present at compile time doesn't mean the kernel supports it, since you can build on 2.6 and then run on 2.4. Also please use the existing macros for checking structure fields."

The macro comment in Daniel's patch description above references Alexandre's comment. Regarding MS Sidewinder support, Anssi Hannula had some input regarding the development:

Well, if you mean the Sidewinder Force Feedback 2, that driver seems to be only a stub. I am currently working on a new PID FF driver (which will cover that Sidewinder).

Also I'm planning some kernel internal FF interface updates and probably introducing FF interface to /dev/input/jsX also.

Daniel realized he had been mistaken, " Yes, I saw your (perhaps old) patch for adding FF support to joydev while I was doing some research before starting this project. I was under the impression that the current Sidewinder PID driver was working, though...a bit of poking at the code tells me I was pretty wrong :) I use a Wingman Force personally, so I hadn't done much looking at the PID side of things."

4. Benchmarks

26 Jul 2005 - 31 Jul 2005 (34 posts) Archive Link: "Benchmark's on the Wiki"

Topics: Testing

People: Tom WicklineMark

Tom Wickline posted some benchmarks on the wiki:

I put the Benchmark results that I posted to wine-devel back in April on the Wiki.

A long discussion then ensued about the format of the results. What you'll see if you go to the page now is the result of a bunch of changes to make it more readable. If you look at the results, you'll notice when it comes to IO Wine is generally faster than XP. That's offset by XP's faster graphics.

5. Cross-Compiling Wine

26 Jul 2005 (2 posts) Archive Link: "cross-compiling for ARM"

Topics: Ports, Build Process

People: John ConnorSteven EdwardsHans Leidekker

Isn't it great when you ask a question on mailing list and someone replies with an answer a few minutes later? Isn't it especially great when it's a slightly bizarre question that you don't expect anyone to have a detailed answer for? John Connor wanted to know about cross-compiling Wine for ARM, " Has anyone tried to cross-compile Wine for the ARM platform or is there any documentation on how to do this? "

Steven Edwards supplied a quick rundown of the steps:

I have but its been a day or two. You need two trees and to first build the Wine tools for your host platform and something like the following

then in another tree

Note there is no support for arm in Wineserver, kernel32 or ntdll so winelib won't run yet. Most everything else should compile as Winelib works on i386, PPC and SPARC. You might be able to get by stubbing the set_thread_context stuff out for simple apps.

We sort of touched on this subject last winter in WWN #263. The steps Steven covered were roughly the same as what Hans Leidekker described, namely building the tools and using the --with-wine-tools option. Ports to other architectures come up once in while, but it's a difficult undertaking. It will be interesting to see if an ARM port can get off the ground.

6. Theming Work

27 Jul 2005 - 29 Jul 2005 (5 posts) Archive Link: "Theming & code duplication"

Topics: Controls

People: Frank RichterRobert ShearmanRob Shearman

Frank Richter has been working a lot on theming. The initial patches have been going in over the past few weeks. He ran into an issue this week regarding how to go about working on controls:

somewhat recently I sent some code to wine-patches to add button theming; if you have glanced at it, despite utilizing subclassing, code was duplicated from the button code in user.

In particular, the themed button does its own state management. The reason is that upon state changes, the user32 button control does some repaints internally, ie calling the paint function directly - those can't obviously be hooked by subclassing alone. In early versions I had the themed button painted over after state-changing messages, but that causes visible flickering (since the button is first painted in "classic" style and the themed style is painted above that).

The basic problem - painting that is hard to hook into - will probably also arise on other controls.

There are some ideas and approaches to deal with the problem that came up (and the results from discussion with Kevin):

I don't like the current code duplication for theming that much, but I'm a bit unsure what else could be done. Perhaps you have some comments or suggestions, and hopefully there will be some consent of what approach would be best for Wine.

Rob Shearman suggested another approach, " You could make the code to using RedrawWindow(... RDW_UPDATENOW), assuming that the paint functions it is calling are for the whole control, not a component of the control."

Frank wasn't sure if that would be sufficient, " Occasionally it does... afaics mostly stuff like just drawing the focus rect or checkboxes only draw the mark when the state changes... but perhaps one could get away with repainting the whole control in this case, though I fear that this would cause flickering again."

Rob thought a small area around it could work, " In that case, you will have to retrieve the rectangle of the changed area and pass that rectangle to RedrawWindow."

Frank didn't think Windows worked that way, though that doesn't necessarily mean the approach wouldn't work, " Though, that would mean that paint messages are emitted to the window? IIRC last time I checked (with Spy++), there were no paint messages when e.g. the state of a checkbox changed. So using RedrawWindow() may mean a different behaviour than on native. "







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 All pages on this site are copyright their original authors, and distributed under the terms of the GNU General Public License version 2.0.