WWN Issue 221

This is the 221st issue of the Wine Weekly News publication. Its main goal is to travel! 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, 204 posts consumed 1125 K. There were 66 different contributors. 34 (51%) posted more than once. 43 (65%) posted last week too.

The top 5 posters of the week were:

17 posts in 48K by Dimitrie O. Paun
14 posts in 39K by Dmitry Timoshkov
13 posts in 31K by Alexandre Julliard
12 posts in 29K by Jakob Eriksson
11 posts in 34K by Ferenc Wagner

News: Return of the Interviews	04/24/2004	Archive
News I'm going to be in on vacation next week, so there won't be an issue of the Wine Weekly News. I'll be in Costa Rica staying as far away from computers as I can. But I couldn't leave you folks without something to read. So we're kicking off another season of interviews with Wine developers. Last year we did a dozen interviews that are now archived on the Wine Who's Who page. So in lieu of news next week we'll be publishing an interview. Jeremy Newman will probably post the interview next Thursday or Friday, look for the news on WineHQ . Next week this link will be active and should take you there. I should also note that the process is rather arbitrary. There's definitely some developers who have been around a while that we haven't interviewed yet. Likewise, there's some people I met at WineConf that have been up to some interesting things. People keep talking about this guy named Alexandre Julliard and asking when we'll interview him. I suppose at some point this summer we'll look him up and fire off some questions.

News: Return of the Interviews

04/24/2004

Archive

News

I'm going to be in on vacation next week, so there won't be an issue of the Wine Weekly News. I'll be in Costa Rica staying as far away from computers as I can.

But I couldn't leave you folks without something to read. So we're kicking off another season of interviews with Wine developers. Last year we did a dozen interviews that are now archived on the Wine Who's Who page. So in lieu of news next week we'll be publishing an interview. Jeremy Newman will probably post the interview next Thursday or Friday, look for the news on WineHQ . Next week this link will be active and should take you there.

I should also note that the process is rather arbitrary. There's definitely some developers who have been around a while that we haven't interviewed yet. Likewise, there's some people I met at WineConf that have been up to some interesting things. People keep talking about this guy named Alexandre Julliard and asking when we'll interview him. I suppose at some point this summer we'll look him up and fire off some questions.

Window Management Ideas	04/24/2004	Archive
Window Management Window Management remains an issue for Wine. It's on the to-do list for revamping but that work is likely months away unless someone jumps in or we clone Alexandre. Mike Hearn tried to spark a discussion with some ideas: The latest WM problems caused by Metacity preventing windows from being moved offscreen prompted to raise the issue of having a Wine specific extension to the NETWM (EWMH) protocol into which we can easily add whatever semantics we need to map win32 windowing to X windowing more easily. The idea would be that we have a new property/set of properties we can mark windows with, _NET_WM_WINDOWS_EMULATION for instance, and standards compliant window managers will take note and not do things that break us. Short of actually doing all our own window management, this is probably the best way to fix the obscure bugs caused by different interpretations WMs have of what various hints mean. The current NETWM border hints are semantic not presentational, so we cannot rely on particular intepretations. The MWM hints are even worse - they are apparently undocumented, and most modern WM authors consider them deprecated. Thanks to their undocumentedness, WMs vary in their interpretation of these too: http://bugs.kde.org/show_bug.cgi?id=73294 So, I'd like to start gathering ideas on what sort of things we'd like to have in the NETWM spec, seeing as how many WMs conform to it these days. First up is a way to ensure the WM doesn't attempt to keep the window onscreen of course :) Other things we probably want are related to border styles, an absolutely crystal-clear no-wriggling-possible equivalent to PPosition as apparently the wording of the ICCCM allows WM authors to ignore this if they want. We might also want to look at where we use unmanaged windows and see if we can replace them with the use of managed windows+hints. We can probably hack around the lack of these things for now, but being able to use these hints where possible will probably keep a lot of us from going grey-haired early :) David Hammerton thought it was a good idea, Just wanted to chime in here and remind you of our discussion on IRC just then. I think this is a great idea and I sure do have a lot to say on this topic (in terms of what I'd like to see in the spec) - but I won't be able to go over it for at least a week (probably longer). I'm sure some of my colleagues have a lot to say on this topic, too. That was the extent of the discussion.

Window Management Ideas

04/24/2004

Archive

Window Management

Window Management remains an issue for Wine. It's on the to-do list for revamping but that work is likely months away unless someone jumps in or we clone Alexandre. Mike Hearn tried to spark a discussion with some ideas:

The latest WM problems caused by Metacity preventing windows from being moved offscreen prompted to raise the issue of having a Wine specific extension to the NETWM (EWMH) protocol into which we can easily add whatever semantics we need to map win32 windowing to X windowing more easily.

The idea would be that we have a new property/set of properties we can mark windows with, _NET_WM_WINDOWS_EMULATION for instance, and standards compliant window managers will take note and not do things that break us.

Short of actually doing all our own window management, this is probably the best way to fix the obscure bugs caused by different interpretations WMs have of what various hints mean. The current NETWM border hints are semantic not presentational, so we cannot rely on particular intepretations. The MWM hints are even worse - they are apparently undocumented, and most modern WM authors consider them deprecated. Thanks to their undocumentedness, WMs vary in their interpretation of these too:

http://bugs.kde.org/show_bug.cgi?id=73294

So, I'd like to start gathering ideas on what sort of things we'd like to have in the NETWM spec, seeing as how many WMs conform to it these days.

First up is a way to ensure the WM doesn't attempt to keep the window onscreen of course :) Other things we probably want are related to border styles, an absolutely crystal-clear no-wriggling-possible equivalent to PPosition as apparently the wording of the ICCCM allows WM authors to ignore this if they want. We might also want to look at where we use unmanaged windows and see if we can replace them with the use of managed windows+hints.

We can probably hack around the lack of these things for now, but being able to use these hints where possible will probably keep a lot of us from going grey-haired early :)

David Hammerton thought it was a good idea, Just wanted to chime in here and remind you of our discussion on IRC just then. I think this is a great idea and I sure do have a lot to say on this topic (in terms of what I'd like to see in the spec) - but I won't be able to go over it for at least a week (probably longer). I'm sure some of my colleagues have a lot to say on this topic, too.

That was the extent of the discussion.

More Filesystem Work 04/25/2004 Archive

More Filesystem Work	04/25/2004	Archive
Filesystems Brett Holcomb ran into a filesystem problem and wondered if someone had any idea what was wrong: I installed from CVS today and when I start wine I get the error below. This happens even with the standard config file that it creates. I've checked both my and the config file and can't find any errors. I'm including the c drive part of the config file. Any ideas why this is telling me this? Error: `Invalid path L"c:\\Windows" for L"windows" directory: does not exist. Perhaps you have not properly edited your Wine configuration file (/home/brett/.wine-cvs/config)` Alexandre then mentioned the recent filesystem changes have made the Path directive of the config file obsolete, Path entries from the config file are no longer used. Check the contents of your ~/.wine/dosdevices directory.

Filesystems

Brett Holcomb ran into a filesystem problem and wondered if someone had any idea what was wrong:

I installed from CVS today and when I start wine I get the error below. This happens even with the standard config file that it creates. I've checked both my and the config file and can't find any errors. I'm including the c drive part of the config file.

Any ideas why this is telling me this?

Error:


Invalid path L"c:\\Windows" for L"windows" directory: does not exist.
Perhaps you have not properly edited your Wine configuration file
(/home/brett/.wine-cvs/config)

Alexandre then mentioned the recent filesystem changes have made the Path directive of the config file obsolete, Path entries from the config file are no longer used. Check the contents of your ~/.wine/dosdevices directory.

When Stubs Are FIXME's	04/28/2004	Archive
Creating Stubs If you've stumbled around in Wine for a while you've probably seen all the stubbed out functions. These are placeholders for parts of the Win32 API that haven't been implemented yet. Sometimes the functionality isn't utilized enough to justify development and an application can fail gracefully if it isn't implemented. Other times the API is so obtuse no one has had a chance to develop it. However, when we speak of creating a stubbed out function it often refers to an empty implementation of it that doesn't return a useful value. William Lahti submitted his first patch this week and asked a very valid question about such behavior: I have implemented the SetCalendarInfoA and SetCalendarInfoW API functions in dlls/kernel/time.c. I am aware that you generally do not like it when more than 1 thing is changed, but SetCalendarInfoA is not much more than a call to SetCalendarInfoW. I am also curious as to why both functions were listed as stdcalls rather than stubs when they were both stubs in the source file. Vincent Béron had a good explanation of it: There are two levels of stubs: "real stubs", and dummy functions. stub is used in a spec file when there's no implementation whatsoever of a given function, not even a dummy one. If an app tries to use that function, it results in a segmentation fault (and usually a crash to the debugger). In the case of SetCalendarInfo{A,W}, some dummy function existed, so they were callable by an app without it crashing (hence the stdcall declaration). Of course it wouldn't actually do much, that's what your implementation is for. The "stub" in the FIXME is to remind people that some function is not really there, although it's been called. The line is difficult to draw between the two types of stub: some apps will crash with a real stub and need a dummy one, some other ones will crash with a dummy one and will route around real stubs. Usually it's done on a case by case basis.

When Stubs Are FIXME's

04/28/2004

Archive

Creating Stubs

If you've stumbled around in Wine for a while you've probably seen all the stubbed out functions. These are placeholders for parts of the Win32 API that haven't been implemented yet. Sometimes the functionality isn't utilized enough to justify development and an application can fail gracefully if it isn't implemented. Other times the API is so obtuse no one has had a chance to develop it. However, when we speak of creating a stubbed out function it often refers to an empty implementation of it that doesn't return a useful value. William Lahti submitted his first patch this week and asked a very valid question about such behavior:

I have implemented the SetCalendarInfoA and SetCalendarInfoW API functions in dlls/kernel/time.c. I am aware that you generally do not like it when more than 1 thing is changed, but SetCalendarInfoA is not much more than a call to SetCalendarInfoW. I am also curious as to why both functions were listed as stdcalls rather than stubs when they were both stubs in the source file.

Vincent Béron had a good explanation of it:

There are two levels of stubs: "real stubs", and dummy functions.

stub is used in a spec file when there's no implementation whatsoever of a given function, not even a dummy one. If an app tries to use that function, it results in a segmentation fault (and usually a crash to the debugger).

In the case of SetCalendarInfo{A,W}, some dummy function existed, so they were callable by an app without it crashing (hence the stdcall declaration). Of course it wouldn't actually do much, that's what your implementation is for. The "stub" in the FIXME is to remind people that some function is not really there, although it's been called.

The line is difficult to draw between the two types of stub: some apps will crash with a real stub and need a dummy one, some other ones will crash with a dummy one and will route around real stubs. Usually it's done on a case by case basis.

Compiler Alignment Differences

04/26/2004

Archive

Testing

Hans Leidekker tracked down a bug that seemed to be compiler dependent:

kernel/tests/generated.c currently shows one failure when the executable is compiled with MinGW. Investigation shows that MinGW and GCC differ when it comes to alignment of doubles (i.e. a 64 bit wide type).

I have constructed the test below that shows the difference between MinGW and GCC. My question is, could someone compile this with MSVC >= 6, run it, and report the outcome here?

Dmitry Timoshkov did and Hans put together a table of the results:

	MSVC	MinGW	GCC
Alignment of __int64:	8	8	8
Size of __int64:	8	8	8

Alignment of large_int:	8	8	4
Size of large_int:	8	8	8

Alignment of container1:	8	8	4
Size of container1:	16	16	12

Alignment of container2:	8	8	4
Size of container2:	16	16	12

Alignment of container3:	8	8	4
Size of container3:	8	8	8

Clearly GCC is the odd one out. When a double is embedded in a structure GCC does not adjust the alignment of the structure to the size of a double.

So, should we add -malign-double to the compiler flags?

Alexandre had a different idea, No, that would break Unix compatibility. We have to explicitly pad the structures that need it.

After going back over the original generated test, Hans realized another problem might be lurking. Some things don't get defined that need to.

World Wine News