WWN Issue 295

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 www.winehq.org

This week, 159 posts consumed 225 K. There were 53 different contributors. 33 (62%) posted more than once. 32 (60%) posted last week too.

The top 5 posters of the week were:

14 posts in 26K by oliver_stieber at yahoo.co.uk (Oliver Stieber)
12 posts in 14K by daniel.r.kegel at gmail.com (Dan Kegel)
9 posts in 9K by wine at troy.rollo.name (Troy Rollo)
6 posts in 6K by brian.vincent at gmail.com (Brian Vincent)
6 posts in 5K by wine-devel at kievinfo.com (Vitaliy Margolen)

News: NewsForge Article	Archive
News 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.

Beta Plans: Tuesday	Archive
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 than 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 in Monday night at the earliest.

Beta Plans: Tuesday

Systray Support, part #697	Archive
Integration 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.

Archive

Integration

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.

OpenGL & Child Window Breakage	Archive
Graphics 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: http://bugs.winehq.org/show_bug.cgi?id=2398 followed by http://bugs.winehq.org/show_bug.cgi?id=2908 WeatherScope (free) http://bugs.winehq.org/show_bug.cgi?id=3083 Google Earth (free) http://bugs.winehq.org/show_bug.cgi?id=3400 Quake3 Radiant http://bugs.winehq.org/show_bug.cgi?id=3583 Moray 3.5 (free) 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, http://bugs.winehq.org/show_bug.cgi?id=2398#c41 , 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 http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6255507 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 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.

OpenGL & Child Window Breakage

Archive

Graphics

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:

http://bugs.winehq.org/show_bug.cgi?id=2398

followed by

http://bugs.winehq.org/show_bug.cgi?id=2908 WeatherScope (free)
http://bugs.winehq.org/show_bug.cgi?id=3083 Google Earth (free)
http://bugs.winehq.org/show_bug.cgi?id=3400 Quake3 Radiant
http://bugs.winehq.org/show_bug.cgi?id=3583 Moray 3.5 (free)

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, http://bugs.winehq.org/show_bug.cgi?id=2398#c41 , 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

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6255507

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

Automatically Downloading ActiveX Archive

Automatically Downloading ActiveX	Archive
Web/HTML Vitaliy Margolen wanted to know if the process to download and install the Mozilla ActiveX control could be improved: At present Wine asks the user if 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 sf.net 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: `[Software\\Wine\\shdocvw] 1089668326 "MozillaUrl"="http://www.iol.ie/~locka/mozilla/MozillaControl16.exe"` 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 occurred, 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, http://www.iol.ie/~locka/mozilla/MozillaControl16.exe, 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.

Web/HTML

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

At present Wine asks the user if 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 sf.net 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:

[Software\\Wine\\shdocvw] 1089668326 "MozillaUrl"="http://www.iol.ie/~locka/mozilla/MozillaControl16.exe"

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 occurred, 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, http://www.iol.ie/~locka/mozilla/MozillaControl16.exe, 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.

World Wine News