Kernel Traffic
Latest | Archives | People | Topics 		Wine
Latest | Archives | People | Topics 		GNUe
Latest | Archives | People | Topics
Czech
Home | News | RSS Feeds | Mailing Lists | Authors Info | Mirrors | Stalled Traffic
 

Wine Traffic #176 For 27 Jun 2003

By Brian Vincent

Table Of Contents

Introduction

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

Mailing List Stats For This Week

We looked at 122 posts in 408K.

There were 42 different contributors. 23 posted more than once. 22 posted last week too.

The top posters of the week were:

1. News: Martin Wilck Interview

21 Jun 2003 - 27 Jun 2003 (2 posts) Archive Link: "News"

Topics: News

People: Martin Wilck, , Eric Pouech, News

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.

2. Running Embedded Taskbar Apps

24 Jun 2003 (2 posts) Archive Link: "Re: XEMBED System tray support"

Topics: Integration

People: Sylvain Petreolle, Mike Hearn, 

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:

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

3. Brazilian Portuguese Localization

21 Jun 2003 - 24 Jun 2003 (10 posts) Archive Link: "Re: Localization to the Portuguese"

Topics: Internationalization

People: Marcelo Duarte, Eric Pouech, 

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:

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

4. Status Page Updates

24 Jun 2003 - 26 Jun 2003 (7 posts) Archive Link: "Wine Status DLL's #2"

Topics: Project Management

People: , Aric Stewart, Rob North

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.

5. New Windows API's

22 Jun 2003 (1 post) Archive Link: "Info on windows server 2003 (new APIs)"

Topics: Documentation

People: Eric Pouech, Microsoft, 

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.

6. Syntax for #include

25 Jun 2003 (12 posts) Archive Link: "Re: Bidi B patch"

Topics: Build Process

People: Shachar Shemesh, Alexandre Julliard, 

Shachar Shemesh submitted a bidi patch with changes to the includes that looked like this:

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.

 

 

 

 

 

 

Sharon And Joy
 

Kernel Traffic is grateful to be developed on a computer donated by Professor Greg Benson and Professor Allan Cruse in the Department of Computer Science at the University of San Francisco. This is the same department that invented FlashMob Computing. Kernel Traffic is hosted by the generous folks at kernel.org. All pages on this site are copyright their original authors, and distributed under the terms of the GNU General Public License version 2.0.