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 #295 For 21 Oct 2005

By Brian Vincent

Table Of Contents


This is the 295th issue of the Wine Weekly News publication. Its main goal is to throw boomerangs. 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 159 posts in 225K.

There were 53 different contributors. 33 posted more than once. 32 posted last week too.

The top posters of the week were:

1. News: Newsforge Article

(1 post) Archive Link: "News"

Topics: News

People: NewsforgeJeremy WhiteNews

Newsforge picked up on the pending beta release of Wine with an article titled, Wine will go beta next week. Quite a few quotes from Alexandre and Jeremy White were included. From the article:

"Wine has historically had a very frustrating history because it has been alpha software," White said. "This is really hard work. We're replicating the work of a billion-dollar company. The reason we're saying it's alpha is because we believe we still have fundamental changes to make on the way the internals work."

Noting that it has not always been easy to install software with Wine's alpha releases over the last decade, White said that once you got something working it has never meant it would continue to do so, or do so properly. There may have been display glitches or things not functioning properly, if a program even worked with Wine at all.

2. Beta Plans: Tuesday

 Archive Link:


People: Alexandre JulliardDimi PaunVicnent BeronKrzysztof FoltmanRobert Lunnon

We've been in a freeze now for about three weeks. Lots of bugfix commits have made it in, but many of the larger changes that normally would go in the tree have been put to the side. So when is the beta going to get released? Alexandre sent a short email this week about it:

I think we are in good shape for the release; the current plan is to release on Tuesday. So if you have bugs that you feel must be fixed for 0.9 (and that can be fixed with minimal changes), now is the time to speak up...

Tuesday means October 25th.

A few people spoke up with changes they thought should go in. Robert Lunnon mentioned he had some Solaris x86 patches laying around that could go in. Krzysztof Foltman wanted to know why a toolbar bugfix hadn't gone in, especially since he had test cases demonstrating it was a bugfix. Dimi Paun wanted to know the status of Fedora and Red Hat builds:

We really need binary builds for Fedora for this release. It would be a pitty to fail to provide binary .rpms for this one, while we have constantly provided them for all the alpha releases for more then one (two?) years now.

Vincent Béron seems to be building packages again and said:

20050930 is on sf for all but CentOS 4 (haven't had time to update my CentOS 4 installation yet). The download page on winehq hasn't been updated yet because it's a mess when all RH-distros are not ready at the same time.

I won't be home this week-end, so it'll go to Monday night at the earliest.

3. Systray Support, part #697

(10 posts) Archive Link: "XEmbed Systray Support"

Topics: Integration

People: James LiggettAlexandre JulliardAndreas MohrMike HearnJames HawkinsRob Shearman

For years people have been trying to get systray support into Wine. Mike Hearn originally came up with a patch that was further hacked on by Rob Shearman. James Liggett has most recently taken up the cause that implements XEmbed system tray support for non-KDE desktops. Apps with the cute, little Windows taskbar icons can really benefit from this. James wanted to know what was going on with the most recent version of the patch he sent in a few weeks ago.

James Hawkins explained the feature freeze was probably preventing it from getting in. James L. thought it was something worth going in, " I wasn't sure that this would be affected by the freeze, since this functionality is on the task list for 0.9. I thought I would try to get it in since it's a major usability problem for anyone who uses anything other than KDE. "

There was some discussion then whether that patch should get in or not. Alexandre then explained it would not get in, " I'm afraid it's too big a change to get in at this point. Besides, there are still problems with that patch."

Andi Mohr felt it really should be considered:

I guess I have to disagree here. Proper systray support is a VERY user-visible element, as such Wine should do everything humanly possible to try to get it included in a pretty well-working way before 0.9 ships.

But then I don't know what's involved here in getting this patch done in a good way, I'm just stating that I think that it's really important. (this stuff has been missing for far too long anyway - and I've been unsuccessfully submitting some systray patches some time ago, too)

Some people would also say that it'd be a *really* lame 0.9 release if Wine wasn't even able to properly dock a tiny icon within pre-existing and properly working desktop mechanisms...

James L. explained part of the problem, " Well, its not exactly a picnic ;-) The original patch had some stack problems, which I believe I've fixed. Also, each desktop implements this standard differently, so a lot of weird disparities can occur. It works with some odd quirks in GNOME (sometimes icons won't dock, other times the Wine-Systray window shows up for no reason at all) I'm not sure why this is, but it has been suggested that this is a bug in their notification area applet, and I have to agree. The patch works great, as I've said previously, in XFce and IceWM. "

4. OpenGL & Child Window Breakage

(14 posts) Archive Link: "bug 2398: OpenGL, child windows, and wine"

Topics: Graphics

People: Dan KegelLionel UlmerHuw DaviesOliver Stieber

Dan Kegel brought up a whole class of applications that have been broken with Wine since the window management rewrite:

The change back in January or so to no longer give each window its own x window seems to have caused an upheaval in the opengl world. The first app to report a problem was Lightwave 3D:

followed by

I've taken the liberty of marking the latter four bugs as duplicates of 2398, reopening 2398, and targeting it to be fixed for Wine 1.0.

Willie Sippel's comment,, seems to point the way to a fix; he suggests using the new GL_EXT_framebuffer_object OpenGL extension. I checked around a bit, and it appears to be at least partly supported by the latest NVidia and ATI drivers. Sun's starting to use it in Java, too; see

A workaround is probably also possible without that OpenGL extension, but it would probably run slower.

I'm tempted to say skip the workaround, at least for the first pass, and just implement the real fix using the opengl extension. As Sippel said, people who use apps like Lightwave (and maybe Quake3 Radiant :-) tend to have the latest 3d hardware and drivers anyway.

What do other people think? Has anybody started looking at fixing this yet?

Lionel Ulmer thought the way forward should be to, " First code what works on all cards / drivers (that would be pbuffers which are pretty much supported on all cards that I know of) and then only code the 'fast path' if any."

Lionel and Oliver Stieber then made some comments about work apparently being done by Huw Davies in this area. Rather than using pbuffers it relies on rendering to a GLX pixmap. Here's a reference on pbuffers and GLX Pixmaps you might want to peruse. While pbuffers may be hardware accelerated, GLX Pixmaps aren't. Anyway, a patch from Huw added, "an x11drv escape that returns a glx drawable" . Huw explained what the intention of that was:

It's going to be used to enable OpenGL to draw on dibsections (ie PFD_DRAW_TO_BITMAP). The deal is that while you can use a Window as a glx drawable you can't use a Pixmap, so the old drawable Escape wasn't sufficient. There are some more bits to come, but they'll have to wait until after 0.9.

That made sense to Lionel and he thought of a workaround:

I think once this is in, I will try (for fun) to see if I can get a hacked version of wgl.c together which uses DIB for the 'in window' rendering part. It would only handle 'back buffer' rendering (i.e. the DIB flushing would be done on the swap buffer call) but it could be a temporary solution waiting for a real OpenGL guru (i.e. not me) to fix using funky extensions :-)

Huw then came up with a something to play with:

Ok, here's a patch for fun.

It has one really nasty hack that needs to be sorted out - that's how to keep the dib section pixmap and bits in sync during opengl calls. We probably need to bracket all opengl calls with the equivalent of x11drv's X11DRV_{Lock,Unlock}DIBSection, presumably exposed by another x11drv escape. For now I just coerce the dib section into the correct state whenever opengl.dll asks for a glx drawable. This will work fine unless somebody starts fiddling with the bits of the dibsection, in which case the thing will just go out of sync. If anybody has any ideas on this then please let me know.

So, the short version of it is there might not be a great solution on the horizon. Maybe Huw's work will pay off for a workaround. OpenGL gurus apply within.

5. Automatically Downloading ActiveX

(12 posts) Archive Link: "Downloading Mozilla ActiveX"

Topics: Web/HTML

People: Vitaliy MargolenMarcelo DuarteVincent BeronJonathan ErnstWineHQ

Vitaliy Margolen wanted to know if the process to download and install the Mozilla ActiveX control could be improved:

At present Wine asks the use it he/she wants to download and install Mozilla ActiveX. But it doesn't work and doesn't tell the user that it didn't work. This is not right. We either should say that download/install failed, or don't show this message in the first place, unless we fix it.

I would consider this as a major inconvenience for users that is not acceptable for 0.9 release.

One of the possible solutions was to download it from SF. But that required some html scraping. That what I thought so too.

Attached is the script that SuSE uses to download core fonts from in an automated fashion. Could we adapt that script and use it? Or program that logic into Wine to do the same?

Marcelo Duarte pointed out:

If you edit the registry and add:

The download functions normally.

I pointed out that should probably get added to wine.inf, but Vincent Béron thought another problem was hiding:

That doesn't solve the capacity problem (which was a real one the last time this discussion occured, and is the reason why the address is not in wine.inf).

Newman wasn't very fond of hosting it on winehq either. Sourceforge looked like the best place regarding capacity, but the automatic download part is a problem with it (unless we put it on our webspace over there, but I'm not sure if it'd be Ok with their TOS).

Jonathan Ernst thought a script on WineHQ could solve the problem, " A simple solution would be to link to a simple php script (or perl or whatever) on WineHQ server that randomly selects a mirror (we can then use all mirrors on sourceforge,, one hosted on winehq, etc.) This would address the capacity problem. "

In fact, Jonathan went ahead and created the PHP script for WineHQ. Alexandre then committed a patch to wine.inf that looks at this script to find a place to download the ActiveX control from.







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.