WWN Issue 275

This is the 275th issue of the Wine Weekly News publication. Its main goal is to freeze. 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, 128 posts consumed 432 K. There were 47 different contributors. 24 (51%) posted more than once. 32 (68%) posted last week too.

The top 5 posters of the week were:

25 posts in 63K by Dimi Paun
12 posts in 32K by Alexandre Julliard
7 posts in 20K by Mike Hearn
7 posts in 21K by Eric Pouech
4 posts in 11K by Kees Cook

French FAQ	05/18/2005	Archive
Documentation One of the reasons for moving the documentation to SourceForge was to enable a new framework to allow for easier translations. Dimi is currently maintaining the documentation CVS and integrating some patches from Francois Gouget for internationalization. Francois is using po4a to help with this. One of the big advantages is being able to see just how much of a document has been translated or exactly how out of date it is. That framework seems to be in place now, so the actual translations can be done. Of course, it leads to the question of just how much work needs to be done on Wine's docs. For example, we know the Winelib User Guide is horribly out of date, so translating it won't help much. The Wine User Guide is in decent shape, but will soon be out of date when we remove the config file. The actual Wine Developers Guide seems to be in great shape, especially with the recent contributions by Eric Pouech. Of all the docs, the FAQ is probably holding up the best. After the massive effort a few years ago to assemble it, there hasn't been very many changes. Francois sent in a patch this week with a French translation of it done by Romuald Vieux and Yvon Benoist: I was away on vacation in the past few days which is why this got delayed a bit. But now that I'm back, here's a patch to translate the Wine FAQ to French using the new po4a/ directory. Note that the patch is pretty big : 136KB (not compressed). That's because that's how big the FAQ translation is. Once this is in I will send patches to add a translation for the Wine User Guide and the WineLib User Guide. Note that configure will need to be regenerated. Changelog: Francois Gouget <fgouget_at_codeweavers.com> Add a framework to handle the translation of Wine's documentation using po4a. Romuald VIEUX Yvon BENOIST Translate and proof-read the Wine FAQ to French. Dimi looked over the translation and the accompanying po4a framework that had been set up and remarked: OK, I've applied the patch to make your life easier, but it needs a lot of work: A. It doesn't work for me (details below) B. The po-rules need to be moved to Make.rules.in C. We need to get rid of the .posgml and sed hack Let's fix these before we put in more translations. So, in reverse order: C. We can do so by patching po4a-translate to do the replacement itself, from within perl. This should also get rid of the .posgml B. They need to be in the same format as the other rules in Make.rules.in (eg .sgml.txt) A. I think we need to check in the generated .sgml too to make it simple to use, so others don't have to go through the pain. Look: [ed note: lots of nasty perl garbage removed ]

French FAQ

05/18/2005

Archive

Documentation

One of the reasons for moving the documentation to SourceForge was to enable a new framework to allow for easier translations. Dimi is currently maintaining the documentation CVS and integrating some patches from Francois Gouget for internationalization. Francois is using po4a to help with this. One of the big advantages is being able to see just how much of a document has been translated or exactly how out of date it is. That framework seems to be in place now, so the actual translations can be done.

Of course, it leads to the question of just how much work needs to be done on Wine's docs. For example, we know the Winelib User Guide is horribly out of date, so translating it won't help much. The Wine User Guide is in decent shape, but will soon be out of date when we remove the config file. The actual Wine Developers Guide seems to be in great shape, especially with the recent contributions by Eric Pouech. Of all the docs, the FAQ is probably holding up the best. After the massive effort a few years ago to assemble it, there hasn't been very many changes. Francois sent in a patch this week with a French translation of it done by Romuald Vieux and Yvon Benoist:

I was away on vacation in the past few days which is why this got delayed a bit. But now that I'm back, here's a patch to translate the Wine FAQ to French using the new po4a/ directory. Note that the patch is pretty big : 136KB (not compressed). That's because that's how big the FAQ translation is. Once this is in I will send patches to add a translation for the Wine User Guide and the WineLib User Guide.

Note that configure will need to be regenerated.

Changelog:

Dimi looked over the translation and the accompanying po4a framework that had been set up and remarked:

OK, I've applied the patch to make your life easier, but it needs a lot of work:

Let's fix these before we put in more translations. So, in reverse order:

ed note: lots of nasty perl garbage removed

Webcams & MSN Messenger	03/18/2005	Archive
Status Updates Maarten Lankhorst has continued spending a lot of time working on webcam support and getting a lot of related patches in. The goal of this is to get MSN Messenger to run. On Wednesday he gave a pointer to a document on the wiki he's been updating: Status: Nearly complete, need testers. https://wiki.winehq.org/MSN_Messenger_webcam_support You need the native quartz dll, which gets installed with internet explorer, as the builtin quartz doesn't work properly when changing media format on initialisation. IFilterGraph Reconnect isn't implemented, and for some reason looks strangely at Robert instead of a FIXME() there's a TRACE telling it is a stub... Maarten then took a closer look at the builtin quartz DLL and found some problems with it. It appears he was able to fix them and get it to work. That might mean you can skip the Internet Explorer installation, though perhaps there's another dependency on it.

Webcams & MSN Messenger

03/18/2005

Archive

Status Updates

Maarten Lankhorst has continued spending a lot of time working on webcam support and getting a lot of related patches in. The goal of this is to get MSN Messenger to run. On Wednesday he gave a pointer to a document on the wiki he's been updating:

Status: Nearly complete, need testers.

https://wiki.winehq.org/MSN_Messenger_webcam_support

You need the native quartz dll, which gets installed with internet explorer, as the builtin quartz doesn't work properly when changing media format on initialisation. IFilterGraph Reconnect isn't implemented, and for some reason *looks strangely at Robert* instead of a FIXME() there's a TRACE telling it is a stub...

Maarten then took a closer look at the builtin quartz DLL and found some problems with it. It appears he was able to fix them and get it to work. That might mean you can skip the Internet Explorer installation, though perhaps there's another dependency on it.

Windows Problems	05/18/2005	Archive
This was a pretty slow week on the wine-devel mailing list. However, tons of patches arrived on wine-patches and Alexandre did a boatload of commits. I guess a lot of people had their heads down getting work done. One short thread about recent windowing problems did pop up. Jason Edmeades asked: Ok, I need advice on this one... I have been purely testing on windows, no wine involvement, to see what happens when I do various things. My test program doesn't do anything in the WM_PAINT handler at all. This results in the machine sitting at 100% CPU processing WM_PAINT messages. Changing the WM_PAINT process to post another user message, results in alternating message posted and WM_PAINT messages, ie normal user message processing is occurring Posting a user message inside the user message handler, results in WM_PAINT being driven, followed by looping processing the user messages - ie WM_PAINT messages are not on the message queue RedrawWindow with update now jumps straight into the message routine with a WM_PAINT, but if we do nothing in that routine, it does indeed proceed to the line after the RedrawWindow call. Wine never leaves the updatenow processing because it loops until the whole region is validated. I believe staying in the updatenow code in wine is incorrect. I think what happens is that when the message dispatch loop gets an empty queue and the window has an invalid region, then a WM_PAINT is returned. So... Can we / I please remove the loop? :-)) What other tests can I do under windows to confirm the behaviour? Alexandre had a pretty short answer, Sure you can, you just need to figure out a way to do that without breaking something else ;-) Jason wondered how to go about testing this more: Woohoo... Should be easy then! From forum updates it appears Notes, Unreal2, UT2003, UT2004, Empire Earth and MS Office 2003 for a start are all affected by this problem, and testing seems to confirm it's wrong, so I would start by changing it with a patch and see what breaks, since we have no evidence anything will as far as I know. But first I'll have a play under wine to compare my test results with my suggested patch and see what breaks... Unfortunately I can't really think of a 'test' I can add into the wine tests for this as most of the testing was under windows since wine just loops! Alexandre suggested, It only loops if the window procedure doesn't validate the window, so what you can do for instance is to have a window proc that does nothing the first 10 times around, and on the 11th call signals an error and validates the window to break the loop.

Windows Problems

05/18/2005

Archive

This was a pretty slow week on the wine-devel mailing list. However, tons of patches arrived on wine-patches and Alexandre did a boatload of commits. I guess a lot of people had their heads down getting work done. One short thread about recent windowing problems did pop up. Jason Edmeades asked:

Ok, I need advice on this one...

I have been purely testing on windows, no wine involvement, to see what happens when I do various things.

My test program doesn't do anything in the WM_PAINT handler at all. This results in the machine sitting at 100% CPU processing WM_PAINT messages.

Changing the WM_PAINT process to post another user message, results in alternating message posted and WM_PAINT messages, ie normal user message processing is occurring
Posting a user message inside the user message handler, results in WM_PAINT being driven, followed by looping processing the user messages - ie WM_PAINT messages are not on the message queue
RedrawWindow with update now jumps straight into the message routine with a WM_PAINT, but if we do nothing in that routine, it does indeed proceed to the line after the RedrawWindow call. Wine never leaves the updatenow processing because it loops until the whole region is validated.

I believe staying in the updatenow code in wine is incorrect. I think what happens is that when the message dispatch loop gets an empty queue and the window has an invalid region, then a WM_PAINT is returned.

So... Can we / I please remove the loop? :-))

What other tests can I do under windows to confirm the behaviour?

Alexandre had a pretty short answer, Sure you can, you just need to figure out a way to do that without breaking something else ;-)

Jason wondered how to go about testing this more:

Woohoo... Should be easy then!

From forum updates it appears Notes, Unreal2, UT2003, UT2004, Empire Earth and MS Office 2003 for a start are all affected by this problem, and testing seems to confirm it's wrong, so I would start by changing it with a patch and see what breaks, since we have no evidence anything will as far as I know.

But first I'll have a play under wine to compare my test results with my suggested patch and see what breaks...

Unfortunately I can't really think of a 'test' I can add into the wine tests for this as most of the testing was under windows since wine just loops!

Alexandre suggested, It only loops if the window procedure doesn't validate the window, so what you can do for instance is to have a window proc that does nothing the first 10 times around, and on the 11th call signals an error and validates the window to break the loop.

WineHQ Docs Update Needed	05/16/2005	Archive
Documentation Dimi Paun forwarded an email asking for someone to make some changes to the FAQ. I decided to do it but quickly discovered the FAQ was one of the docs that got moved to SourceForge (see WWN #274 for details.) I figured it was a good time to add an FAQ entry about how to update the FAQ as well. Now that those new entries were added, it led me to ask, has WineHQ been updated to build the FAQ/docs from SF rather than WineHQ CVS? Dimi replied, No, I haven't had time to rewrite those scripts. If someone is kind enough to help out on this one, I'd really appreciate it. I asked him where the scripts lived since it's an area most people are probably unfamiliar with. He answered: They are in the tools/ module in the WineHQ CVS: http://cvs.winehq.org/cvsweb/tools/ Namely 'make_winehq' and 'wine_release'. If you look at those scripts, you'll see make_winehq is the one responsible for updating the docs on the website. It looks like wine_release needs to run first though to create the directory referenced by make_winehq. If someone could spend some time updating those scripts we'd appreciate it.

WineHQ Docs Update Needed

05/16/2005

Archive

Documentation

Dimi Paun forwarded an email asking for someone to make some changes to the FAQ. I decided to do it but quickly discovered the FAQ was one of the docs that got moved to SourceForge (see WWN #274 for details.) I figured it was a good time to add an FAQ entry about how to update the FAQ as well. Now that those new entries were added, it led me to ask, has WineHQ been updated to build the FAQ/docs from SF rather than WineHQ CVS?

Dimi replied, No, I haven't had time to rewrite those scripts. If someone is kind enough to help out on this one, I'd really appreciate it.

I asked him where the scripts lived since it's an area most people are probably unfamiliar with. He answered:

They are in the tools/ module in the WineHQ CVS:

http://cvs.winehq.org/cvsweb/tools/

Namely 'make_winehq' and 'wine_release'.

If you look at those scripts, you'll see make_winehq is the one responsible for updating the docs on the website. It looks like wine_release needs to run first though to create the directory referenced by make_winehq. If someone could spend some time updating those scripts we'd appreciate it.

More Wiki Additions 05/18/2005 Archive

More Wiki Additions	05/18/2005	Archive
WineHQ The Wine Wiki has really taken off. Lots of people have added info over the past few weeks. A bunch of interesting docs appeared, many of which are working drafts of areas people are looking into. Check out the RecentChanges to see the activity going on. Mike Hearn posted another debugging doc and asked on wine-devel: This time, it's how to debug PE Explorer hanging when you double click on a DLL in the file open dialog (fixed in CVS). https://wiki.winehq.com/Debugging_the_PE_Explorer_file_open_dialog Newbie developers, I crave your feedback. Are these actually useful or am I wasting my time? Mike Hearn also had some tips for anyone adding to the wiki: Embedding a block of code is best done like this: `{{{ #!cplusplus if (foo) { bar; } }}}` This will give it nice syntax highlighting, a monospace font and line numbers. Unfortunately StudlyCaps as the Win32 API uses them is the same style that triggers WikiWording. To fix this surround Win32 API names like CreateWindow or IShellLink with backticks: eg `IShellLink`. This will disable WikiWording in that section and also format them with a monospace font. If you have a word that it wants to WikiWord, prefix it with a ! mark. Don't do this just because there's no page for it yet, somebody may create one in future. Also don't do it for Win32 API names, use backticks instead. But it can be useful for some things. Those Wine developers who haven't yet made a todo list, go do it! It's really informative to be able to see what people are working on (not to mention interesting) and this way we can help cut down on duplication of effort. Dimi added to the list: if you want to put your email on your page, but are afraid of spam, use the MailTo macro like so: [[MailTo(dimi AT SPAMFREE lattica DOT com)]] This will still show the address properly in the browser, and avoids email harvesting just fine. please try to provide a comment when you change a page. It takes very little effort (just a few words will do), and helps a lot when you look at RecentChanges. I'm glad people like the Wiki. It can become an amazing resource, but only if people contribute and take care of it. I think it's already on its way to being a great development resource. If you have any complaints, needs or wants, please don't hesitate to voice them -- I'd be more than happy to address them.

WineHQ

The Wine Wiki has really taken off. Lots of people have added info over the past few weeks. A bunch of interesting docs appeared, many of which are working drafts of areas people are looking into. Check out the RecentChanges to see the activity going on. Mike Hearn posted another debugging doc and asked on wine-devel:

This time, it's how to debug PE Explorer hanging when you double click on a DLL in the file open dialog (fixed in CVS).

https://wiki.winehq.com/Debugging_the_PE_Explorer_file_open_dialog

Newbie developers, I crave your feedback. Are these actually useful or am I wasting my time?

Mike Hearn also had some tips for anyone adding to the wiki:

Embedding a block of code is best done like this:
This will give it nice syntax highlighting, a monospace font and line numbers.
Unfortunately StudlyCaps as the Win32 API uses them is the same style that triggers WikiWording. To fix this surround Win32 API names like CreateWindow or IShellLink with backticks: eg `IShellLink`. This will disable WikiWording in that section and also format them with a monospace font.
If you have a word that it wants to WikiWord, prefix it with a ! mark. Don't do this just because there's no page for it yet, somebody may create one in future. Also don't do it for Win32 API names, use backticks instead. But it can be useful for some things.

Those Wine developers who haven't yet made a todo list, go do it! It's really informative to be able to see what people are working on (not to mention interesting) and this way we can help cut down on duplication of effort.

Dimi added to the list:

if you want to put your email on your page, but are afraid of spam, use the MailTo macro like so: [[MailTo(dimi AT SPAMFREE lattica DOT com)]] This will still show the address properly in the browser, and avoids email harvesting just fine.
please try to provide a comment when you change a page. It takes very little effort (just a few words will do), and helps a lot when you look at RecentChanges.

I'm glad people like the Wiki. It can become an amazing resource, but only if people contribute and take care of it. I think it's already on its way to being a great development resource.

If you have any complaints, needs or wants, please don't hesitate to voice them -- I'd be more than happy to address them.

World Wine News