WineHQ

World Wine News

All the news that fits, we print.

05/26/2006
by Brian Vincent
Issue: 314

XML source
More Issues...

This is the 314th issue of the Wine Weekly News publication. Its main goal is to be inspired . 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, 141 posts consumed 300 K. There were 76 different contributors. 26 (34%) posted more than once. 37 (48%) posted last week too.

The top 5 posters of the week were:

  1. 9 posts in 11K by julliard at winehq.org (Alexandre Julliard)
  2. 7 posts in 13K by tom at dbservice.com (Tomas Carnecky)
  3. 6 posts in 13K by ivg2 at cornell.edu (Ivan Gyurdiev)
  4. 5 posts in 7K by rob at codeweavers.com (Robert Shearman)
  5. 5 posts in 8K by dmitry at codeweavers.com (Dmitry Timoshkov)

News: Picasa, Wine 0.9.14, LJ Article Archive
News

The biggest news of the week is the port of Google's Picasa to Linux. We're actually going to cover that in the next section below since there's a fair amount of news.

Alexandre released Wine 0.9.14 this past week. There's a ton of patches in it, but a lot of the work is more behind the scenes than other releases we've seen recently. Noted changes:

  • Better MS/RPC compatibility.
  • Many fixes to Direct3D shaders.
  • Several improvements to the header control.

We're seeing a ton of development going on with DirectX, particularly Direct3D. You might remember that about a year and a half ago Oliver Stieber began contributing some large patches to get Direct3D 9 working. After that, work began to port Direct3D 8 to the new library, wined3d, used by D3D9. Since then, work has branched out into many areas. We've picked up some new developers along the way, which is great.

I mentioned the following on wine-devel about a recent Linux Journal article:

I just saw the May issue of Linux Journal and it has an article titled Running Sound Applications Under Wine . It's written by Dave Phillips and it's pretty good. Things seemed to work about as well as you'd expect, well, maybe even better than a lot of you would expect. Programs installed ok, audio configuration seemed pretty easy, etc. I actually think it's great that Wine isn't the focus of the article; he spends most of the time talking about applications. I guess that means all the magic was successfully hidden. I half expected the article to complain about broken things, but there was hardly a mention of it at all. At the end he did list about 4 applications that have issues, including one named "Finale" that didn't install.

Dave did mention he'd like to see the JACK audio driver working: "Hopefully, Wine's JACK driver will work again by the time this article is printed. JACK is the present and future of Linux audio, and it would be a definite Good Thing for the Wine Project. A virtual ASIO driver might be a helpful addition as well."

All in all, it's a wonderful article written by one of the top Linux sound gurus.

[Oops. I just noticed there's a glaring mistake in it. He said he tested with Wine 0.9.6 and then has a paragraph discussing ~/.wine/config . I think it's a remnant of an old installation.]

Finally, Uwe Bonnes, Stefan Maunz, and Marcus Meissner attended Linuxtag in Wiesbaden a few weeks ago. Marcus provided a picture showing Stefan on the left and Uwe next to him. Check out the nice Wine poster on the wall behind them.


Picasa Port to Linux Archive
Ports

Several months ago we reported that CodeWeavers was contracted to port some Google apps to Linux (see WWN #306 for details.) That news came out the last week in February. Here we are less than 3 months later and Picasa is running. So let's take a look at some of the details. You might have missed some of this if you only read things like Slashdot or wine-devel.

First, one of the most interesting revelations came from Linux Today and Chris DiBona's description of the port. Chris revealed that Google Earth is slated to be the next app ported. From that report:

Picasa, founded in 2001, was purchased by Google in July of 2004, and the photo management tool has seen some extensive use, albeit from Windows users. DiBona indicated that Google made a public commitment to begin porting two applications to Linux about a year ago. The other application in this project is Google Earth. Picasa for Linux was announced first simply because it was finished first.

When asked if the additions to WINE would bootstrap Google Earth's porting progress, DiBona answered in the negative, explaining that Google Earth relied on Qt and GL libraries and code, so additional WINE support would not help. No timeline for that application's release was revealed at this time.

Interestingly, Google Earth is suffering from an OpenGL and Wine windowing problem that's a showstopper for a ton of other programs. It's a regression in Wine that dates back about a year ago to when window management code was modified to perform better. There should be some nice collateral damage from fixing that bug. You might be able to get a sneak preview of Google Earth on Linux if you start tracking CVS. This seems like the type of bug only Alexandre can fix, so if you see him mucking around with window management and/or OpenGL, you might want to try installing the Windows verson of Google Earth to see if it runs.

Now, back in February I conjectured that Google would probably provide a copy of Wine to run Picasa with and that it would be a straight up Windows app rather than a traditional Winelib port. That proved to be the case and you can expect the same for Google Earth. Even more important, Google Earth and Picasa will likely be able to share the same version of Wine libraries, so we may see a collection of desktop apps appearing for Linux similar to the Google Pack available for Windows.

Okay, back to the news about Picasa. If you're unfamiliar with this program it's an image archive/management tool. Besides just storing pictures and making them searchable, there's a lot of features like mail integration, photo manipulation, and the ability to import pictures from devices like digital cameras. It's very well done and has a very well designed interface.

Dan Kegel broke the news on wine-devel about the port. His email is below. Of note is that CodeWeavers contributed 225 patches back to Wine to get Picasa working. Actually, the count of 225 dates to April 18th, and there's been more patches since then. From the announcements made, it sounded like these patches were developed in the dark and we're about to be patch bombed into Wine. That's not the case. CodeWeavers employees openly contributed these patches as they were developed over the past few months. That's the Right Way to do development, and it's great there was an open line of communication from the beginning.

Google's Picasa on Linux page describes some of the features of the port. Slashdot covered the story with a post by Chris and included some positive comments, Picasa for Linux uses Wine internally; this shows a bit in the interface, but it works even better than we had hoped. ... Thanks to our pals at CodeWeavers who did much of the heavy lifting, and to Marcus Meissner, whose libgphoto support patch was a welcome surprise."

Speaking of Marcus' patch, we covered that in two recent issues: #311 and #313 . Apparently Google and CodeWeavers made an assumption up front that digital cameras all could be accessed like a typical USB storage device. It seems that most can, and as a result, we have Alexandre's patches from a few weeks ago to add HAL event support to Wine. USB devices will be noticed and have drive letters assigned to them automatically. Well, Marcus' patch utilizes the traditional TWAIN interfaces to link the TWAIN APIs to libgphoto. In turn, libghoto can access cameras. This makes image acquisition a lot more like Windows but integrated with native Linux code. Unbeknownst to Marcus, his code came at a critical time.

Dan Kegel's mail to wine-devel provides an inside perspective on the port:

Google has indeed been working on Picasa, and it's finally available for download at

For the curious, here are a few tidbits about how it came to be.

When Google wanted to port Picasa to Linux, they faced a problem: the Picasa team was busy working on new projects, and having them also do a native port would have taken a while. As an experiment, Google decided to give Wine a try. A quick look showed that much of Picasa already worked, but key features were missing: the IWebBrowser API, SSL, scanner/camera support, removable media notification (so you can insert a flash drive and have Windows notice it right away), and change notification (so Windows can notify apps when new files are created), among others. Fortunately, Wine was already halfway to having an implementation of IWebBrowser thanks to Jacek Caban's Summer of Code 2005 project. And all that other stuff couldn't be *that* hard, right? :-) So Google engaged CodeWeavers to add those features and fix any other bugs. This resulted in tons of improvements to Wine (see the list at code.google.com/wine.html ), all of which are now in the public tree at winehq.org.

Many people assume that when porting a Windows app to Linux using Wine, the best thing to do is link Winelib into the application to create a native Linux application. Not so! It's just as effective, and a heck of a lot easier, to run the same binary on both Windows and Wine. So that's what the Picasa team did. Picasa for Linux uses slightly different text messages, but the .exe file is identical for both Windows and Linux.

Toward the very end, everything was looking great except that the initial assumption that most cameras emulate storage devices turned out to be wrong. Fortunately, Marcus Meissner just happened to decide to implement libgphoto support; his patch appeared at the perfect moment, and now Picasa supports both common flavors of cameras.

Two features left out of the Linux version were CD-ROM burning (the driver Picasa uses is hard to support under Wine) and movie playback (Wine doesn't have the necessary codecs). Both are potentially fixable in a future version, but were beyond the scope of this first port.

One interesting challenge when shipping commercial apps for Linux is packaging -- do you choose RPM or Debian packages, or do you use a WIndows-style installer? The Picasa for Linux team chose all three, in hopes of pleasing everybody. (Let's see how well *that* works :-) The Windows-style installer was implemented using the open-source Loki installer, and a few patches were contributed back for that, too.

The Picasa for Linux team had a blast. It's not often you get to pour resources into a vital open source project to help ship a commercial application! We hope we get to do it again sometime soon, and we hope the results are good enough to encourage other companies to give Wine a try.

Thanks to the Wine community for a very capable platform!

This could be really interesting. It's been quite a few years since a company has ported their app with Wine. Back then, the traditional thinking was the code needed to be moved from Windows to Linux and completely recompiled with Winelib. Well, that approach doesn't really offer any performance advantages and about the only benefit is you have the ability to link against native Linux libraries. Linking against native libraries would allow for better integration, except no one ever bothered to go that far. Google's approach is much more pragmatic. By shipping a known, self-contained version of Wine they can ensure future regressions don't slip in that break Picasa. At 24MB for the entire download (9MB of Picasa, 12MB of Wine, and 3MB for a Gecko engine) it's conceivable other companies would be interested in doing the same.

There ya have it. Go download it .


DirectDraw Patch Archive
DirectX Status Updates

As I mentioned, there's a lot happening in the world of Direct3D and DirectDraw. Stefan Dösinger dropped an email to wine-devel to give an update of the work he's doing: moving Wine's 2D DirectDraw code over to wined3d and OpenGL rendering. It then facilitates moving Direct3D 7 and earlier versions of D3D to wined3d. He wrote:

Merging the code into WineD3D is done now, so the last thing is to merge the new ddraw code. I have uploaded a new diff to http://stud4.tuwien.ac.at/~e0526822/ , with some updated screenshots. The diff is against wine git from May, 26th, 12 am (yep, the site has an older date). It should apply to much older versions too, but it won't work because a few crucial patches were applied in the last 2 days. 2 games are missing in my game list, Anarchy Online and Worms 2 are also known to work.

Ok, what to do now? The patch fixes quite a few games, but with all bigger changes there are problems. I know some games which worked before that are broken now (Tibia, Z-Ball, Battlezone 2 and Swat 3). Battlezone 2 and Swat 3 have fogging issues, I have to talk to Lionel Ulmer about that, and BZ2 also needs tripple buffering. Tibia does some Blt Voodoo which doesn't work in OpenGL yet, z-ball is similar. It's likely that there are other breakages too. Another issue is that wined3d still has a hard dependency on OpenGL, and that means that my DirectDraw lib cannot do 2D rendering without libGL.so. It doesn't need hardware acceleration, only the lib has to be available. Roderic is working on that.

So what can we do?

  • Wait with the merge until WineD3D does lazy linking to libGL
  • Wait with the merge until all games that worked before work now (gonna take some time)
  • Merge it now and fix the regressions as they occur. This would have the advantage that the code is in and it will only improve from that point, and it's easier for users to test. The drawback is that some users might complain that their games are broken :-|. On the other had, lots of others are waiting for this to get their games working.

What is missing except of fixing regressions? Mostly performance improvements:

  1. Make all ddraw games working with the OpenGL renderer
  2. More intelligent texture upload: I have some hacks for that in my tree (Swat 3!, Half-Life 2 maybe?)
  3. The same for render targets(System shock 2, swat 3, Prince of persia 3D)
  4. Try to write an OpenGL gdi driver which handles TextOut and friends directly in OpenGL (Age of Empires, Settlers 3 combined with 1)
  5. Rendering fixes: Fog and color keying (Pop3D, Battlezone 2, Swat 3)
  6. Better OpenGL state management, this the lack of that takes performance down.
  7. Multi-threaded D3D (Need for speed 3, Empire Earth, many others)

All this will happen in wined3d, and the improvements aren't limited to D3D7 games. They don't have to be done in that order.

If you're on wine-users, please CC me, I'm not yet subscribed there.


Patch Submission Ideas Archive
Patches

This thread actually came up last month while I was traveling and I'm just playing catchup here. Mike McCormack described how to use GIT with an IMAP folder for submitting patches:

As of the recently released GIT 1.3.0, sending patches via an IMAP folder with GIT just got easier.

If everything is set up right, you should be able to run the following command:

    git-format-patch --attach --stdout --keep origin | git-imap-send

This requires some configuration in ~/.git/config :

    [core]
      name = "Mike McCormack"
      email = "mike at codeweavers.com"
    [imap]
      Folder = "INBOX.Drafts"
      Tunnel = "ssh -q usr at svr /usr/bin/imapd ./Maildir 2> /dev/null"
    [format]
      headers = "To: wine-patches <wine-patches at winehq.org>\n"

Using Mozilla, you can just click on the "Edit Draft:" in the message, check/edit the message and then click send.

Alexandre has said that he doesn't mind if the subject line contains the ChangeLog entry.

No more missing patches, missing ChangeLog entries, or patches generated from the wrong directory.

I think James Hawkins has written a program similar to git-imap-send that works with GMail...

Alexandre replied that this was a good method and that subject lines that contain the ChangeLog entry make things easier for him.


MSI Problem Archive
MSI

Mike McCormack and Aric Stewart have done most of the work in Wine to support the Microsoft Installer file format and APIs. The framework they've put in place works well, but there's a need for others to pick up where they've left off. For example, MSI has a concept of actions , which might consist of copying or deleting files. Well, the most commonly used actions have been implemented, but it's known there are others that need to be fleshed out. Mike has mentioned before that MSI is rather nice in that's a relatively contained bit of code, so someone wanting to jump into Wine development might like starting there.

This week EA Durbin described in-depth an MSI problem of a different kind that's in need of some attention:

Currently the MSI Installer is working backwards, In the file files.c it reads the files from the msi package and iterates through them and queries the Media table in order by LastSequence. The sort order for the media table should be DiskId according to MSDN. Just changing the sort order won't work unless the msi installer is revamped to work the right way. The code is written wrong for this. Currently it's using LIST_FOR_EACH_ENTRY in the Install Files function for the files and then trying to ready the media per file using the sequence number of the file in the query on the media table using the file sequence as last sequence and returning the results ordered by LastSequence.

It should first be reading the Media table and sorting by DiskId. The installer then iterates through each row returned by the query from the media table and then for each file in the file table that falls within that disk id it should ready the media. Currently wine is doing it backwards which ends up trying to ready the wrong media if the last sequence.

It needs to read the media table, then starting with DiskId 1, iterate through all of disk Id 1 and read from the file table order by sequence until it reaches the last sequence as indicated in the media table for the working DiskId, then it jumps to the next DiskId 2, 3, and so on. The lastsequence of the working DiskId should always be greater than that of the last sequence of the previous DiskId, if not the results should be skipped, currently it is trying to read from DiskIds that have zero as the LastSequence but 22 as the DiskId. Zero indicates the first entry in the media table (if you're in DiskId 1). as you increment through the DiskId's the LastSequence should increment as well, if it doesn't you skip that install media.

This is what causes the cabinet bugs in bugs #4533 and #5139.

A quick fix, but not the solution would be to change the query so it doesn't return the results from the media table if the LastSequence is 0 and the DiskId is greater than 1.

The solution would be to rewrite the installer to do things the right way querying the Media table first, and then installing the files in order from the media table.

If someone could help me work on this it would be much appreciated as I'm kind of rusty in C, I'm a perl monger by trade and not very familiar with wine's msi innerworkings.

As you'll see in MSDN the file and media table sequence and LastSequence correspond with one another. Each has checks upon the other to determine the proper install order.

Mike thought that analysis was correct, but mentioned he wouldn't have time to work on it.


Font Issue Archive
Fonts

On a different note, Troy Rollo found a problem in Wine's font handling:

The attached sample program demonstrates a bug in font handling that can lead to corrupted fonts. Compile with "winegcc -g sysfont.c -lgdi32 -lcomdlg32". Run the resulting a.out, and you will see the letter "C" in the top left corner of the window, rendered in the system font. Click anywhere in the client area of the window and the letter will change its shape, even though it is still using the stock SYSTEM_FONT.

The left click action creates a device context for the default printer and immediately deletes it. As part of the deletion of that device context, DeleteDC selects the stock SYSTEM_FONT into the device context. Since printer device contexts insist on scalable fonts, the existing (bitmapped) GDI font for the system font is unable to serve, so a new one is created, which ends up being based on the Tahoma (TrueType) font. On the next paint loop, when the test program calls SetFont it is the new, scalable font (based on Tahoma) that is found.

The Tahoma font has different glyph codes to the System font, such that 'C' is glyph code 36 in the System font and 38 in Tahoma. Accordingly, x11drv identifies the glyph as not having been uploaded (it has uploaded glyph 36 before), and uploads it as glyph 38 based on its outline in Tahoma.

The problem gets worse later on because some glyphs in the glyphset have been uploaded according to their "System" font positions (or in this case, the same character has been uploaded in its position in both fonts). Rendering a character that uses the other glyph code results in the wrong character. You can get a mix of Tahoma and System characters appearing on the screen with the System characters displaying the shape of the wrong character.

Every fix I look at seems like a horrible hack. Perhaps find_in_cache should only return bitmap fonts if the device can use them. If the caller then finds there is no bitmap font that matches it can then look for scalable fonts in the cache.

Three hours later, Huw Davies had a 5 line patch that fixed it.


All Kernel Cousin issues and summaries are copyright their original authors, and distributed under the terms of the
GNU General Public License, version 2.0.