World Wine News : les nouvelles de Wine
by Brian Vincent
This is the 232nd issue of the Wine Weekly News publication. Its main goal is to assemble desks. 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, 147 posts consumed 639 K. There were 53 different contributors. 23 (43%) posted more than once. 19 (35%) posted last week too. The top 5 posters of the week were:
|
| News: Wine-20040716, ELX BizDesk 4.0 | 07/17/2004 | Archive |
|---|---|---|
|
News
New Wine release.. lots of new goodies: WHAT'S NEW with Wine-20040716: (see ChangeLog for details)
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 a short mention of WineTools being packaged with it. That's the first time I've heard of it being shipped with a distro. | ||
| MSIExec.exe Replacement | 07/18/2004 | Archive |
|---|---|---|
|
Status Updates
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: Note: Much functionnality is still absent, but it's already able to begin the installation of iTunes.msi and netfx.msi. I plan on updating this in the coming days. Changelog:
| ||
| Translating Wine | 07/21/2004 | Archive |
|---|---|---|
|
status Updates
Marcelo Duarte posted an update on the status of Wine's translation and about a new tool to help in localization efforts: I modified a tool that Vincent Béron made and thus we can have the status of the translation of some languages. Case somebody wants that I add others I inform me. We can see that some languages are well complete, as the Portuguese ;)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. | ||
| Daily CVS Snapshots | 07/22/2004 | Archive |
|---|---|---|
|
WineHQ
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. | ||
| Stubbing a COM Interface | 07/19/2004 | Archive |
|---|---|---|
|
Creating Stubs
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: It seems urlmon is missing a (stubbed) IInternetSecurityManager Interface (see also http://msdn.microsoft.com/workshop/security/szone/reference/ifaces/iinternetsecuritymanager/iinternetsecuritymanager.asp ). Since I am new to this, I was wondering how I can create a stubbed implementation. As far as I can tell I need to:
Are there any (wine) pointers on implementing a new (stubbed) COM 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 Hearn 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). | ||
| Out of Tree Builds | 07/18/2004 | Archive |
|---|---|---|
|
Build Process
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: My computer has a cvs (source) tree and the build tree. When I make changes to test something, I copy the source file to be changed for the source tree into the build tree and modify it. After this I run configure, make depend, make and make install in the build tree to get the changes into the wine binary. If a C source file or a header file exists in the build tree it is used instead of the file in the source tree. Spec files in the build tree are ignored. They are always used from the source tree. Therefore I have to edit the Makefile in the build tree to use the modified spec file, or link the dll.so file by hand. Hope my problem is explained clearer now. Do I use an undocumented feature? 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. | ||
| Contacting Testers | 07/17/2004 | Archive |
|---|---|---|
|
Testing
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. | ||
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.


