WWN Issue 240

This is the 240th issue of the Wine Weekly News publication. Its main goal is to jog. 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, 301 posts consumed 1104 K. There were 82 different contributors. 45 (54%) posted more than once. 43 (52%) posted last week too.

The top 5 posters of the week were:

38 posts in 144K by Mike Hearn
31 posts in 79K by Alexandre Julliard
18 posts in 48K by Robert Shearman
13 posts in 44K by Dimitrie O. Paun
12 posts in 25K by Juan Lang

News: Wine-20040914	09/11/2004	Archive
News WWN on Tuesday? Yep, this issue is late. Mea culpa. Rather than wait till Friday to do a double issue, this mini-issue will be a summary of last week's wine-devel topics. Plus, the Sept 24th issue is shaping up to be a bit larger than normal. Last week Alexandre tagged a new CVS snapshot, Wine-20040914. The following was in the announcement: Various improvements to the common controls. New ITSS dll (for HTML Help support). Many compatibility fixes in the exported headers. Replacements for the Windows standard bitmap fonts. Lots of bug fixes. Binary and source packages are available from our download page.

News: Wine-20040914

09/11/2004

Archive

News

WWN on Tuesday? Yep, this issue is late. Mea culpa. Rather than wait till Friday to do a double issue, this mini-issue will be a summary of last week's wine-devel topics. Plus, the Sept 24th issue is shaping up to be a bit larger than normal.

Last week Alexandre tagged a new CVS snapshot, Wine-20040914. The following was in the announcement:

Various improvements to the common controls.
New ITSS dll (for HTML Help support).
Many compatibility fixes in the exported headers.
Replacements for the Windows standard bitmap fonts.
Lots of bug fixes.

Binary and source packages are available from our download page.

New Fonts 09/16/2004 Archive

New Fonts	09/16/2004	Archive
Fonts In Alexandre's announcement above he mentioned fonts as a major new addition. It's a topic that hasn't been brought up on wine-devel, but there has been a lot of work done by Huw Davies on getting this added. Up until now, Wine has required that you go out and find your own TrueType fonts. Fortunately, this isn't too hard; you can even download a collection of Microsoft fonts from Sourceforge. Having that dependency is really a crutch and this new work will help alleviate it. The new work done by Huw requires FontForge to be installed in order to generate font files from "source" code. For anyone downloading and compiling Wine, this is something they probably won't have on their machine and it's a step that will probably be skipped. For folks downloading binary packages, hopefully it will be something included. Thus far we have Courier, Marlett, Sans Serif, and System fonts and you can find them in the newly added `fonts/` directory. The Marlett font is the newest addition and comes to us via TransGaming. A thread developed this week about using that font and some other general questions. Rob Shearman asked, Is there any policy for using it? E.g. a lot of the arrows and stuff in the native comctl32 are drawn using this font, so would we now be able to do this with our version of the common controls? Vincent Béron thought it would be a bad dependency, Far from everyone has fontforge installed, so unless there's a compiled version in cvs (a la configure) you might find most users don't have marlett.ttf. Huw suggested testing to see if Marlett was available, and then fall back to the existing code if it wasn't. Mike Hearn didn't like the idea of keeping two codepaths and suggested that it may be worth checking in the binaries into CVS. Alexandre didn't approve of that, however, First because binaries are a pain with CVS, second and more important because there has to be a very good reason for putting any generated file in CVS; configure qualifies, but fonts don't. The worst case is that the window controls won't look exactly right, that's not a big deal, and it can be solved by having a binary font package somewhere for download. So, things look like they'll stay as they are right now and this will become more of a packaging issue. Anyone out there got a nice collection of fonts you made and want to donate to Wine? If so, let us know .

Fonts

In Alexandre's announcement above he mentioned fonts as a major new addition. It's a topic that hasn't been brought up on wine-devel, but there has been a lot of work done by Huw Davies on getting this added. Up until now, Wine has required that you go out and find your own TrueType fonts. Fortunately, this isn't too hard; you can even download a collection of Microsoft fonts from Sourceforge. Having that dependency is really a crutch and this new work will help alleviate it.

The new work done by Huw requires FontForge to be installed in order to generate font files from "source" code. For anyone downloading and compiling Wine, this is something they probably won't have on their machine and it's a step that will probably be skipped. For folks downloading binary packages, hopefully it will be something included. Thus far we have Courier, Marlett, Sans Serif, and System fonts and you can find them in the newly added fonts/ directory. The Marlett font is the newest addition and comes to us via TransGaming. A thread developed this week about using that font and some other general questions. Rob Shearman asked, Is there any policy for using it? E.g. a lot of the arrows and stuff in the native comctl32 are drawn using this font, so would we now be able to do this with our version of the common controls?

Vincent Béron thought it would be a bad dependency, Far from everyone has fontforge installed, so unless there's a compiled version in cvs (a la configure) you might find most users don't have marlett.ttf.

Huw suggested testing to see if Marlett was available, and then fall back to the existing code if it wasn't. Mike Hearn didn't like the idea of keeping two codepaths and suggested that it may be worth checking in the binaries into CVS. Alexandre didn't approve of that, however, First because binaries are a pain with CVS, second and more important because there has to be a very good reason for putting any generated file in CVS; configure qualifies, but fonts don't. The worst case is that the window controls won't look exactly right, that's not a big deal, and it can be solved by having a binary font package somewhere for download.

So, things look like they'll stay as they are right now and this will become more of a packaging issue. Anyone out there got a nice collection of fonts you made and want to donate to Wine? If so, let us know .

DirectX 9 Roadmap	09/12/2004	Archive
DirectX We've had a bit of a lull in DirectX graphics programming. As last year's big push was wrapping up, one of the topics that came up involved creating a new library that could be shared between related parts of DirectX, in particular Direct3D. Jason Edmeades resurrected the topic this week: I've spoken with the wine-d3d people and no one is currently doing anything on directx9 support. Originally Raphael was trying to merge things into a new library, wined3d, using an interface which ddraw could also use. This has not happened, and as we stand there is no progress being made. Now, I know nothing about d3d9 support - I have started to see what would be the easiest way to implement this, and have come up with a couple of options, and am after some advice.... (My preference) d3d8 and d3d9 are very similar in lots of respects. I would like to move all the GL code into the wined3d library, effectively factorizing d3d8 and d3d9. However, this would mean extra function call overhead for dx8 and I really don't know how common they will be. Obviously d3d8 will change during such a transition I could implement d3d9 from scratch. This would have the advantage of being a standalone library and won't affect d3d8, but a disadvantage of having to fix anything twice, and probably they will get out of sync really quickly. Also, d3d8 still has parts missing, and I'd prefer a single implementation if possible. If we did this, wined3d could be deleted and a huge code duplication would be required (or 3.... Do nothing, and see if anyone else takes up the gauntlet.) Now, I am not a 3d graphics programmer - I learnt d3d8 as I implemented it (for wine) out of interest to see how things were done. I am happy to try to do the same for d3d9, and would prefer approach (1). I have a few concerns though - Mostly I haven't done enough research to know if its possible, and I may end up having a shared library with 2 implementations anyway... I haven't found any major stumbling block yet, but I haven't researched it far enough either. My other concern is if I start doing it and have to give up due to work or other pressures, I could leave a half migrated setup. I assume its relavitevly easy with cvs to back out changes if this occurs, and I hope it won't, but it is a concern. I'd appreciate thoughts before I start (especially Lionels, AJ's etc) - I'm only just getting back into wine programming again hence my interest. Quickly the conversation turned away from the technical matter at hand to whether or not Wine should be breaking big things like DirectX as things are restructured. Things like maintaining separate development branches were discussed, but nothing conclusive was decided. Lionel Ulmer thought the growing pains were worth it: Well, why could we not live with DX8 / DX9 breakage for some time ? At the time D3D was resurected, it was broken for most of the time (and probably still is :-) ). And if someone disappears from development, it's just more motivations for others to pick up the work and continue (which would be more problematic with branches as this branch, if unmaintained, could really wither away without anyone working on it). The discussion then turned back into how Wine should be stabilized. The ultimate decision on how to proceed is up to Alexandre and he stayed out of the discussion. In the past it seems the direction is to complete the major items on the to-do and then begin a period of stabilizing everything in anticipation of a 1.0 release. It's up to Alexandre whether any interfaces get broken enroute to that that goal. Alexandre has quite a good track record of not breaking things while major reorganizations are being done and that's likely to continue. A release management plan taking into account different branches hasn't been formalized yet and seems to be a bridge that will be crossed when we get there. With regard to the DirectX direction, Jason went on to begin working on a new wined3d framework to encompass common elements between different versions.

DirectX 9 Roadmap

09/12/2004

Archive

DirectX

We've had a bit of a lull in DirectX graphics programming. As last year's big push was wrapping up, one of the topics that came up involved creating a new library that could be shared between related parts of DirectX, in particular Direct3D. Jason Edmeades resurrected the topic this week:

I've spoken with the wine-d3d people and no one is currently doing anything on directx9 support. Originally Raphael was trying to merge things into a new library, wined3d, using an interface which ddraw could also use. This has not happened, and as we stand there is no progress being made.

Now, I know nothing about d3d9 support - I have started to see what would be the easiest way to implement this, and have come up with a couple of options, and am after some advice....

(My preference) d3d8 and d3d9 are very similar in lots of respects. I would like to move all the GL code into the wined3d library, effectively factorizing d3d8 and d3d9. However, this would mean extra function call overhead for dx8 and I really don't know how common they will be. Obviously d3d8 will change during such a transition
I could implement d3d9 from scratch. This would have the advantage of being a standalone library and won't affect d3d8, but a disadvantage of having to fix anything twice, and probably they will get out of sync really quickly. Also, d3d8 still has parts missing, and I'd prefer a single implementation if possible. If we did this, wined3d could be deleted and a huge code duplication would be required
(or 3.... Do nothing, and see if anyone else takes up the gauntlet.)

Now, I am not a 3d graphics programmer - I learnt d3d8 as I implemented it (for wine) out of interest to see how things were done. I am happy to try to do the same for d3d9, and would prefer approach (1). I have a few concerns though - Mostly I haven't done enough research to know if its possible, and I may end up having a shared library with 2 implementations anyway... I haven't found any major stumbling block yet, but I haven't researched it far enough either.

My other concern is if I start doing it and have to give up due to work or other pressures, I could leave a half migrated setup. I assume its relavitevly easy with cvs to back out changes if this occurs, and I hope it won't, but it is a concern.

I'd appreciate thoughts before I start (especially Lionels, AJ's etc) - I'm only just getting back into wine programming again hence my interest.

Quickly the conversation turned away from the technical matter at hand to whether or not Wine should be breaking big things like DirectX as things are restructured. Things like maintaining separate development branches were discussed, but nothing conclusive was decided. Lionel Ulmer thought the growing pains were worth it:

Well, why could we not live with DX8 / DX9 breakage for some time ? At the time D3D was resurected, it was broken for most of the time (and probably still is :-) ).

And if someone disappears from development, it's just more motivations for others to pick up the work and continue (which would be more problematic with branches as this branch, if unmaintained, could really wither away without anyone working on it).

The discussion then turned back into how Wine should be stabilized. The ultimate decision on how to proceed is up to Alexandre and he stayed out of the discussion. In the past it seems the direction is to complete the major items on the to-do and then begin a period of stabilizing everything in anticipation of a 1.0 release. It's up to Alexandre whether any interfaces get broken enroute to that that goal. Alexandre has quite a good track record of not breaking things while major reorganizations are being done and that's likely to continue. A release management plan taking into account different branches hasn't been formalized yet and seems to be a bridge that will be crossed when we get there.

With regard to the DirectX direction, Jason went on to begin working on a new wined3d framework to encompass common elements between different versions.

FreeBSD Breakage Fixed 09/09/2004 Archive

FreeBSD Breakage Fixed	09/09/2004	Archive
Ports Last week we mentioned building on FreeBSD was broken (WWN #239 ) because of a patch that that changed IPX networking in a way that was specific to Linux. Gerald Pfeifer was working with Roderick Colenbrander on a fix but the thread hadn't wrapped up by the end of the week. Roderick then dug into it and described the problem and how to go about fixing it: Currently I don't have access to the machine I use for wine stuff, so I haven't been able to create a real patch. Anyway I'll try to assist you fixing the problem as it isn't that difficult to fix. There are three places that break Wine on FreeBSD: WS2_Send WS_getsockopt WS_setsockopt First the code in ws2_send isn't relevant to FreeBSD as the ipx sockaddr structures are different in case of Linux and FreeBSD. Just add #ifdefs or whatever Alexandre likes the most. Next there are the WS_getsockopt/setsockopt functions. In the getsockopt fuction we need to retrieve the ipx packet type and we do the opposite in setsockopt. The code that you need to place in both functions looks something like this: `//getsockopt code struct ipx val; getsockopt(fd, 0, SO_DEFAULT_HEADERS, &val, sizeof(struct ipx)); opt_val = (int)val.ipx_pt; //setsockopt code struct ipx val;` (perhaps we should retrieve this one using a getsockopt call and then we set modified one) `val.ipx_pt = opt_val; setsockopt(fd, 0, SO_DEFAULT_HEADERS, &val, sizeof(struct ipx)); *opt_val = (int)val.ipx_pt;` I hope this helps. Gerald put together a patch that checked to see if `__FREEBSD__` was defined and then changed the getsockopt and setsockopt calls similar to how Roderick suggested. Alexandre didn't like checking for the platform but suggested instead to check for features on the platform. Gerald changed his patch to define `SOL_IPX` and if it wasn't available to fall back to what Roderick suggested. Ironically, shortly after that it looks like another patch was committed that broke FreeBSD in a different way.

Ports

Last week we mentioned building on FreeBSD was broken (WWN #239 ) because of a patch that that changed IPX networking in a way that was specific to Linux. Gerald Pfeifer was working with Roderick Colenbrander on a fix but the thread hadn't wrapped up by the end of the week. Roderick then dug into it and described the problem and how to go about fixing it:

Currently I don't have access to the machine I use for wine stuff, so I haven't been able to create a real patch. Anyway I'll try to assist you fixing the problem as it isn't that difficult to fix.

There are three places that break Wine on FreeBSD:

WS2_Send
WS_getsockopt
WS_setsockopt

First the code in ws2_send isn't relevant to FreeBSD as the ipx sockaddr structures are different in case of Linux and FreeBSD. Just add #ifdefs or whatever Alexandre likes the most.

Next there are the WS_getsockopt/setsockopt functions. In the getsockopt fuction we need to retrieve the ipx packet type and we do the opposite in setsockopt. The code that you need to place in both functions looks something like this:


//getsockopt code

struct ipx val;

getsockopt(fd, 0, SO_DEFAULT_HEADERS, &val, sizeof(struct ipx));

*opt_val = (int)val.ipx_pt;




//setsockopt code

struct ipx val;

val.ipx_pt = *opt_val;

setsockopt(fd, 0, SO_DEFAULT_HEADERS, &val, sizeof(struct ipx));

*opt_val = (int)val.ipx_pt;

I hope this helps.

Gerald put together a patch that checked to see if __FREEBSD__ was defined and then changed the getsockopt and setsockopt calls similar to how Roderick suggested. Alexandre didn't like checking for the platform but suggested instead to check for features on the platform. Gerald changed his patch to define SOL_IPX and if it wasn't available to fall back to what Roderick suggested.

Ironically, shortly after that it looks like another patch was committed that broke FreeBSD in a different way.

Pager Status Update	09/15/2004	Archive
Status Updates Rob Shearman, who's been doing a lot of controls work recently, rewrote the pager control . Dimi Paun asked him to document the current status of it, Cool stuff. While this is still fresh in your mind, an audit against comctrl v6.0 would be good too... :) James Hawkins asked what an audit would entail and Mike Hearn explained: Checking how complete the control is versus the latest build from Microsoft, then making a list of the missing messages, notifications and styles. It's useful because they are so complex that if an app is misbehaving due to an unimplemented callback or style etc, you can go see what it might be. Comctl 6 is the version that comes with Windows XP and is not redistributable. It's the one that implements theming. Rob submitted a patch and noted the following things remain to be implemented: TODO: Implement repetitive button press. Adjust arrow size relative to size of button. Allow border size changes. Styles: PGS_DRAGNDROP Notifications: PGN_HOTITEMCHANGE

Pager Status Update

09/15/2004

Archive

Status Updates

Rob Shearman, who's been doing a lot of controls work recently, rewrote the pager control . Dimi Paun asked him to document the current status of it, Cool stuff. While this is still fresh in your mind, an audit against comctrl v6.0 would be good too... :)

James Hawkins asked what an audit would entail and Mike Hearn explained:

Checking how complete the control is versus the latest build from Microsoft, then making a list of the missing messages, notifications and styles.

It's useful because they are so complex that if an app is misbehaving due to an unimplemented callback or style etc, you can go see what it might be.

Comctl 6 is the version that comes with Windows XP and is not redistributable. It's the one that implements theming.

Rob submitted a patch and noted the following things remain to be implemented:

TODO:

Implement repetitive button press.
Adjust arrow size relative to size of button.
Allow border size changes.
Styles:
- PGS_DRAGNDROP
Notifications:
- PGN_HOTITEMCHANGE

Spying on COM	09/10/2004	Archive
RPC / COM / OLE Saulius Krasuckas passed along a link that's probably worth making a note of: Am not sure would it be of any use for list members, but just some minutes ago I've discovered "The COM spy". Quite old stuff, but whatever: http://staff.develop.com/jasonw/comspy/default.htm Mike Hearn thought it could be a useful tool to add to someone's arsenal, This certainly looks useful, thanks! I suspect it'll need at least CoTreatAsClass to be implemented to work on Wine, but that isn't too hard (it may even be done by now, been a while since I checked).

Spying on COM

09/10/2004

Archive

RPC / COM / OLE

Saulius Krasuckas passed along a link that's probably worth making a note of:

Am not sure would it be of any use for list members, but just some minutes ago I've discovered "The COM spy". Quite old stuff, but whatever:

http://staff.develop.com/jasonw/comspy/default.htm

Mike Hearn thought it could be a useful tool to add to someone's arsenal, This certainly looks useful, thanks! I suspect it'll need at least CoTreatAsClass to be implemented to work on Wine, but that isn't too hard (it may even be done by now, been a while since I checked).

World Wine News