This is the 176th release of the Wine Weekly News publication. It's main goal is to inform you of what's going on around Wine (the Un*x windows emulator).
This issue the Wine Weekly News is actually quite significant. A little over two years ago I took over the Wine Weekly News from Eric Pouech. The first year was pretty rough, I can honestly say I was clueless and had no idea what I was writing in those first few issues. So now we're at the point where Eric wrote 88 issues and I've written 88 issues. Some things have changed, others haven't. If everything stays on track we'll hit another milestone around the New Year - the 200th issue. Many thanks to the Wine community for supporting this little newletter, and a huge thank you to anyone who's gotten involved because they read something here.
This week I published the eigth interview in WineHQ's ongoing series. Martin Wilck answered questions about Winsock, free software development, and lots of other topics.
Mike Hearn posted a patch that enabled apps that
embed
themselves into the system tray (taskbar) to do the same
when used in Gnome 2.2+ or KDE 3.1+. Sylvain Petreolle tried it
out and commented,
I'm testing your patch with various programs.
Seems to work way cool.
Mike replied with more details on the patch:
There's a screenshot of it in action here:
http://theoretic.com/mike/RhymBox1.png
for those who are curious. It looks as you might expect :) More interesting is the app I'm working on - it's a DHTML application written mostly for Internet Explorer.
If the tray icon doesn't appear to dock, try running whatever you're testing it with again. I *think* there is a bug in the gnome tray applet that causes it to sometimes reject docks or misallocate tray sizes (it can do this with native programs too).
Marcelo Duarte sent in some patches for Portuguese localization. He explained the additions:
I intend to perhaps keep the support the Portuguese language and to other tasks. Please, in any modifications to the resources, it would like to be informed to translate them, because I can be the support to Brazilian Portuguese language in the Wine.
TODO: A documentation/readme.pt_br to be more brazilian localized and resources from dlls/*.
Alexandre, the portuguese of Brazil is slightly different of Portugal, but ALL files *Pt.rc that I encountered is brazilian portuguese (because "File" is translated to "Arquivo" in Brazil and to "Ficheiro" in Portugal, etc). The questions are: I need to separate them? Which is the correct behavior?
Changelog:
- localization to the Portuguese of Brazil of "programs/*";
- separation of some resources that only existed in English, with support also to the Portuguese;
- lesser adjustments in menus;
- recriation of the file progman/Pt.rc and creation of others;
- change in #include "windows.h" for #include <windows.h> in some files.
Eric Pouech explained one way to separate the differences between
the Portuguese of Brazil versus Portugal,
Since there are differences, and if you're ready to support those
different, then we can always create two sets of resources for
portugese: one for portugese from Portugal, another one for brasilian
portugese. Note, that windows consider Brasilian portugese to be the
default sublang for all portugese:s (which seems to me a bit ackward,
but South America is likely closer to Redmond than Lusitania...)
Marcelo didn't think he could support the other translation,
I can support only Portuguese of Brazil, despite I know the difference
between some words, but not all, as well as I know that I would not be the
person more indicated to support any another language. But I can separate
the files to facilitate for somebody of Portugal that is made use to make
this now or future. I also have little free time, but I want to always
contribute that it will be able or to find necessary.
Tom Wickline went through and began updating the Wine Status pages. If you've ever looked at the status pages you may have noticed the column for "Documentation status". Generally that status has been "Nonexistent". That hasn't bothered a lot of developers because the necessary documentation, such as function definitions, has been available via MSDN. This time around Tom modified the DLL's status page to include links to the relevant docs.
There was a bit of discussion concerning the wintab32 DLL. Rob North and Aric Stewart's recent work hasn't been committed yet, so bumping up the status on it is a but premature. Tom also posted a Changelog detailing the differences and point out specific changes in estimated amount of completion.
Eric Pouech dropped a short note to the list:
http://msdn.microsoft.com/msdnmag/issues/03/06/WindowsServer2003/default.aspx
well, not too many surprises here (most of the new APIs already existed in XP)
Windows 2003 serves as the focus of the article, but it's an excellent introduction to Windows in general. The summary:
There's a lot to say about Windows Server 2003. First of all, it's the first operating system with built-in .NET Framework support, and it's the first 64-bit OS from Microsoft. But wait, there's more! There are lots of new features and APIs in this version as well. For instance, Windows Server 2003 features Hot Add Memory and a number of other arcane new tidbits. There are new APIs for handling threads, directories, and files, and new features like the low fragmentation heap for managing memory and system information. There's vectored exception handling and new UI APIs as well.
The author mentions several undocumented API's and data structures. It'll likely be a while, if ever, before programs exploit the new capabilities. Some of these features debuted in Windows XP and are only now making their way into Wine.
Shachar Shemesh submitted a bidi patch with changes to the includes that looked like this:
-#include "winnls.h"
+#include <winnls.h>
Alexandre didn't like that,
Local includes can be included with <> too, there's no reason to make
a distinction. And some of the headers in include/ are actually
internal, like gdi.h (actually I would argue that bidi definitions
should go there). The fact is that all our source files use "" for
both internal and exported headers, and we are not going to change all
of them. Changing only a few here and there creates a lot more
confusion than it solves.
Shachar felt the distinction could be useful,
Alexandre, I only partially agree. I think the current situation, where
"" and <> behave the same, is an undesireable one. We want to be able to
tell packagers to grab the entire /include directory with no fear
(libwine-devel.rpm anyone?). We don't want it to hold directories not
available for the standard windows. In order to enforce this
distinction, we need to remove the "-I." from the compilation options.
The last stage, of changing "" to <> can then happen slowly.
Alexandre didn't buy that argument:
I don't think it's a useful distinction to make in the source; IMO the current situation is just as useful, since it lets you distinguish between system headers and Wine headers. In a Winelib app, it makes sense to use <>, since a #include <winbase.h> and a #include <stdio.h> mean the same thing, they both include system headers from /usr/include. In the Wine source it's very different, a #include <winbase.h> will *not* include the system header from /usr/include, it will include the local header from the current source tree. That's an important distinction too, and one that we would lose by changing all includes to <>.
Both options make sense, and they both convey (different) useful information, so you can't say one is better than the other. And it doesn't make sense to change all the source files if the end result is not a clear improvement, which it isn't in that case.
A couple people pointed out that the Wine janitorial page had an item on it to change includes to use the <> method. The thread died without a clear answer on that.