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

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 a 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 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 world 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.]

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

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

http://labs.google.com/

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!

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

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

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 wont work unless the msi installer is revamped to work the right way. The code is written wrong for this. Currently its 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 order by LastSequence.

It should first be reading the Media table first 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 DiskId's that have zero as the LastSequence but 22 as the DiskId. Zero indicates the first entry in the media table(if your in DiskId 1). as you increment through the DiskId's the LastSequence should increment as well, if it doesnt 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.

• http://msdn.microsoft.com/library/en-us/msi/setup/ ordering_file_sequence_numbers_in_a_cabinet_file_table_and_media_table.asp
• http://msdn.microsoft.com/library/en-us/msi/setup/file_table.asp?frame=true

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.

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.