Wine Traffic Brian Vincent

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

Fonts Mike Hearn Huw Davies Microsoft TransGaming cvs

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 cvs

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

  1. (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 dont know how common they will be. Obviously d3d8 will change during such a transition
  2. I could implement d3d9 from scratch. This would have the advantage of being a standalone library and wont 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
  3. (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 havent done enough research to know if its possible, and I may end up having a shared library with 2 implementations anyway... I havent found any major stumbling block yet, but I havent 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 wont, 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.

Ports Gerald Pfeifer

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.

Status Updates James Hawkins Microsoft Dimi Paun Rob Shearman

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
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:

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