New Wine release.. lots of new goodies:

As always, you can find links to the source and binary distributions at the WineHQ download page. Of course, since it came out almost a week ago it's already out of date compared to CVS. To stay on the bleeding edge try downloading it from CVS (or keep reading for a thread on where to find CVS snapshots.)

There's a review of ELX BizDesk 4.0 on DesktopOS.com. If you skip to page 3 you'll find short mention of WineTools being packaged with it. That's the first time I've heard of it being shipped with a distro.

I don't directly cover a lot of patches that go into Wine. Partly because I feel if I write about what one person has accomplished I should write about what everyone has. Often large patches do generate discussion on wine-devel, so I do cover them in the context of the discussion. Last week I included Mike McCormack's status update on Microsoft Installer work (issue #231) and he mentioned there was no actual implementation of msiexec.exe to go along with it. Lest anyone out there is actually working on it you should note that Vincent Béron came up with an initial implementation:

Marcelo Duarte posted an update on the status of Wine's translation and about a new tool to help in localization efforts:

Marcelo included the output in his email for German, English, Spanish, French, Italian, and Portuguese. Perhaps not so coincidentally there were some patches for the German translations by Henning Gerhardt and Marcus Meissner that appeared this week. Ivan Leo Puoti also provided some Italian translations.

Jeroen Janssen asked, Would it be possible to have daily cvs snapshots (cvs export) of the wine HEAD tree?

It's such a good idea that we already thought of it. Um.. except we forgot to tell anyone.. or maybe we used to tell people but then we changed the website and forgot about it. Andi Mohr replied first with a link, Err... we've already been having that for a VERY long time ;-) http://lisas.de/~andi/wine_files/wine-cvs-hopefully-current.tar.bz2 (I thought that was mentioned at WineHQ? Not sure, though, especially with all those changes in the meantime...)

Jeremy Newman pointed out that WineHQ also has CVS repository available, We also tar up the entire CVS on our main ftp server here: ftp://ftp.winehq.org/pub/wine/full-cvs-2004-07-21.tar.gz

Keep in mind the link Jeremy provided is for the full CVS and is quite large.

In a different thread, Jeroen wanted to know how to go about implementing some new functionality.. or at least starting to by stubbing out an interface:

Mike McCormack confirmed the first point and clarified the second point, right... though you should only need to add an implementation of URLMON_DllRegisterServerEx to make that work, assuming that wine.inf already tries to register urlmon.dll Mike offered a tip too, It's nice to have a test program (usually built on a windows machine) to test your new interface. Make sure you get the right number of methods in the right order, with the right calling convention and arguments. You need to implement IUnknown manually. You probably want to reference another piece of code that already implements a COM interface... there's plenty in dlls/shell32 and dlls/ole32. (eg. dlls/shell32/shelllink.c)

Rob Shearman pointed out another thing that had to be done, You will need to update the corresponding urlmon.h header file too, so that it can be used by C code. You can do this by running "make idl" in the wine/include/ directory. Lionel Ulmer had a script to create a stubbed out COM interface, so maybe he could give you the script or create the interface for you. However, given the relatively small number of methods in IInternetSecurityManager it might be just as easy to create it by hand.

Jeroen wondered why that script wasn't in the tools/ directory and Lionel replied, Because it was an unmanageable Python hack that worked for me after a lot of tweakings (for DirectX and QUARTZ).

Stefan Leichter ran into a problem with out of tree builds, When i have a changed spec file for a dll in the build tree it does not get used. The spec file from the source tree is used. Can this be fixed?

Alexandre didn't see what the problem was since the spec file belonged in the source tree. Stefan described how he was trying to work:

Alexandre explained why that wouldn't work, that's not how you are supposed to use build trees. The build tree should contain only generated files, all the sources should be in the source tree. It won't work right to have sources in both places, not only because of the spec files, dependencies also won't be correct include files may not always be included from where you expect, etc.

We asked folks if they could help run Wine's automated test suite. This week Mike Hearn wondered how to go about contacting some testers, The test reports don't seem to include an email address for the reporters. I'd love to contact Nicolas Escuder or Dimitris Koukoravas to try and find out what their drive G: is and why it makes GetDiskFreeSpace fail.