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

Wine Traffic #293 For 7 Oct 2005

By Brian Vincent

Table Of Contents


This is the 293rd issue of the Wine Weekly News publication. Its main goal is to attempt to do remote support using using a tin can and string. 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

Mailing List Stats For This Week

We looked at 308 posts in 503K.

There were 76 different contributors. 47 posted more than once. 34 posted last week too.

The top posters of the week were:

1. News: Wine-20050930

(1 post) Archive Link: "News"

Topics: News

People: Alexandre JulliardHuw DaviesMike McCormackRob ShearmanDaniel RemenakNewscvs

Last month we mentioned you might never have a chance to experience Wine as alpha software again. Fortunately, you still can. Alexandre released another CVS snapshot last week and noted the following additions:

WHAT'S NEW with Wine-20050930: (see ChangeLog for details)

You might notice we really haven't discussed many of those items in past WWN issues, so you might be surprised to see them. Well, most of those changes haven't really generated any discussion on wine-devel. For a quick run-down on those items:

2. Stabilizing for Wine 0.9 Release

(3 posts) Archive Link: "Release plans"

Topics: Project Management

People: Alexandre JulliardMicrosoft

That's right, Wine really is going to see a beta release Real Soon Now. We've been talking about it forever but it's taken till now for everything to come together. Now it boils down to testing, bug fixing, and generally making Wine usable for the masses. The beta release will still have boatloads of bugs, but the significance will be the core architecture is complete and configuration works out of the box. Alexandre dropped a note asking for assistance from the community and outlining the short-term plans:


I just released 20050930, this should be considered the pre-0.9 release, so please give it some good testing. In particular, please test the things that new users will encounter first, like the automatic .wine creation and winecfg.

Even if you normally build from source, please for once try the binary package for your distro and check if you spot anything the packager is doing wrong.

Bugzilla has had a good cleanup lately (thanks guys!) and most of the irrelevant bugs have been closed, so please have a look at the remaining ones to see if there's anything you know how to fix.

We also still need many documentation updates, so please consider helping with that.

If you have scripts that handle releases, now is the time to ensure they can cope with a version number not in the YYYYMMDD format...

If all goes well, and if the documentation is updated by then, the real 0.9 should be released in a couple of weeks. In the meantime we should consider ourselves in a code freeze, so please don't submit new features or large changes, only small bug fixes will be allowed in.

Thanks everybody for your help, it has been a long trip but we are getting there...

Then a strange thing happened: people actually began focusing on testing and bug fixing. There was a very noticeable change in postings to wine-devel and a lot of people began looking at parts of Wine they don't normally play with. For instance, few, if any, developers use the wineinstall script. Even fewer download and use the binaries.

So let's be realistic for a moment. Have you ever used CrossOver Office? If so, you'll understand the potential of Wine. CrossOver performs much better than a stock Wine installation. Very little of that is due to hacks in CrossOver but rather that it gets a lot of testing before releases. So we know it's possible to stabilize Wine, we just haven't thrown any resources (i.e. you) at it. If you have some time this weekend, follow Alexandre's suggestions to hammer on our packages and configuration.

There's some good apps out there to test. Google's Picasa is known to work pretty well. Microsoft's free Word Viewer also performs pretty good. Having said that, most apps still have glitches and breakages to some degree.

3. Summer of Code Update: MSHTML

(1 post) Archive Link: "MSHTML SoC project summary"

Topics: Web/HTML, Status Updates

People: Jacek CabanMicrosoftDimi Paun

If you've been playing with Wine over the past several weeks you might have noticed something strange.. web pages now get displayed. The work you're seeing is the result of Jacek Caban's MSHTML implementation. We've covered it a lot in past issues (see WWN #268, #271, #276, #281, and #285). Jacek wrote in to give a status update on what still needs to be tackled:

As Dimi suggested, I'm writing here a summary of my SoC project. I was working on MSHTML implementation. More about what is MSHTML is on the wiki: so I won't rewrite it here.

MSHTML generally works as HTML is displayed, but there is still a bit to do. The thing that blocks correct implementation is loading pages from stream. It prevents correct implementation of functions like stop or refresh. What I mean here is that the function Load gets IMoniker interface that should be used to load the page, but the current implementation just gets URL by GetDisplayName and lets Gecko load the page. Not only it is a hack, it limits the functionality so that only protocols supported by Gecko may be used - which definitely is not what we want. Among others HTML Help, because of this, can't work with current implementation, as it uses mk protocol. There is some code that allowed us to implement it correctly, but presently it's disabled. I gave more info about this in comment to the patch: Before I'll enable it again in CVS, I'd like to have a better URLMoniker implementation (most apps use it to pass IMoniker to the Load function but the current Load implementation hides bugs in it). First thing that needs to be done with URLMoniker is to switch it to use the pluggable protocol. That means rewriting most of URLMoniker, but, first of all, these protocols have to be correctly implemented. I have almost finished http implementation, so there remain https and ftp. That's what I'm going to work on in the nearest future, however now it can't go to the CVS before 0.9 release (correct me if I'm wrong). Other things that have to be done are:

Dimi Paun asked Jacek to update the wiki page to include a to do list. Jacek created some new pages for that, including MsHtml and UrlMon. Dimi also wanted to know what the problem was with shdocvw, the Microsoft shell doc object and control library. Jacek described what was going on with it:

Builtin MSHTML works fine with shdocvw. urlmon is a bit worse. It currently fails after BindToStorage call. I didn't try to get it working with current implementation as it's really just a hack and my tests show that it's very buggy. Switching to use pluggable protocol means rewriting it and I hope to get it working then.

shdocvw currently uses the Mozilla ActiveX control implementation of WebBrowser control. Some apps work fine with it, so we need to have them working with our own implementation before we can get rid of Mozilla ActiveX in shdocvw (and have only Gecko depended MSHTML). Meantime we can develop the WebBrowser version that is used when Mozilla ActiveX control is not available (it's just a stub now) to use MSHTML.

4. Thinking Toward Future Releases

(4 posts) Archive Link: "Release schedule after release?"

Topics: Project Management

People: Holly BostickAlexandre JulliardIvan Leo Puoti

People really began thinking this week about what the future roadmap for Wine needs to look like. Holly Bostick asked:

So how will one "Get Wine" after the release? Will there continue to be monthly public betas? Or will the release schedule change? Will the binary policy change? Meaning that the public betas (if they still exist) will not be available in distribution repositories, but Wine will now maintain its own stable and unstable trees, and only releases will be available to the distro repositories? Will there be different policies or levels of availability for different distros (maybe a Knoppix user will be able to get the unstable beta builds from Sid contrib, but a SuSE user won't)?

Alexandre replied, " Apart from the version numbering, it won't change much. There will still be regular CVS snapshots (I'm hoping to do them more frequently than in the past, but don't hold me to that ;-), and binary packages built from these snapshots. I have no plans to create stable/unstable branches, at least not until we reach 1.0."

Ivan Leo Puoti wanted to know how that would work for freezing the tree for bugfixes only and how it would open back up. Alexandre pointed out that process was in already in effect:

It's really a progressive process that has been going on for some time now. As code matures I'm getting increasingly reluctant to accept large changes to it, that's why I insist on small patches and test cases for changes to areas like the wineserver, or the messaging code; while for dlls that are still pretty much in prototype stage almost anything can get in. So as we progress towards 1.0, more and more code will get in a "frozen" state.

At some point we'll have to decide that some features need to be postponed until after 1.0, but I don't think we are quite there yet. At this point I don't see anything that is currently being worked on that would be unacceptable for 0.9.x.

5. QA & Bug Triaging

(10 posts) Archive Link: "Organizing more Wine bug triage"

People: Dan Kegel

If you hang around any free software project for a while you'll hear developers talk about all of the non-coding work that needs to be done to keep a project moving. Wine is certainly no exception. As Alexandre mentioned in the above release plans, we need a fair amount of documentation written. Besides that, we also need folks to do QA work and bug triaging.

Now, when most people think of QA and sifting through bug reports their eyes begin to glaze over. Well, Wine is a little more interesting than most projects in this regard. Triaging bug reports means you get to install lots of different software and play with it. Dan Kegel took some time to put together a web page about how you or anyone else can report bugs or help make existing bug reports clearer:

Wine's bugzilla has 375 unconfirmed bugs reported since the beginning of the year. A fair number of these are worth fixing, but don't have good recipes for how to reproduce them. I think it's time to make a concerted effort to recruit more Wine users to help triage bug reports, so wine developers can spend less time sorting through poor bug reports.

As a first stab, I've created a web page,

describing bug triage and giving easy steps for people who are interested in helping.

Quite a few people had good suggestions to improve the page. Dan is keeping a running list of bug stats and this week showed:

It's interesting to see how many bugs are in each stage of the bug lifecycle. Here are the counts as of various dates, and links to click on to get the current count:

It's even more interesting to see where the action is. Here are the bugs which have been updated in the last 7 days. It's worth browsing through the comments for a few of these.

6. Font Issue (Fixed)

(15 posts) Archive Link: "Stop-ship 0.9 problem"

Topics: Fonts

People: Mike HearnDmitry TimoshkovLionel UlmerHuw DavesHuw DaviesCodeWeaversKrzysztof FoltmanWineHQApple

Huw Davies developed a new patch within the CrossOver tree that changed the way fonts get displayed. Basically it enabled hinting within of fonts within Wine. Now, that's sort of a problem since Apple holds patents on that process (the Freetype website has a good description of the problem.) CodeWeavers can get away with it in CrossOver Office since they've licensed the technology from Apple. Within Wine it just causes problems unless you've compiled Freetype yourself and enabled hinting, which practically no one does. Mike Hearn explained the issue:

There is a serious problem with Wine 0.9 as-is, namely that we now respect Windows antialiasing settings.

If you have a patented bytecode hinter enabled FreeType, things look OK:

but if you don't (like 99% of Linux users):

Needless to say we can't ship 0.9 when it'll look like that for most users.

The attached patch fixes the issue by providing an override for antialiasing. FreeType AA makes the fonts look good again at small sizes.

A better long term solution suggested by Krzysztof Foltman might be to make bitmapped copies of a hinted Tahoma at small sizes, for instance.

Dmitry Timoshkov disagreed:

I'd argue that it's not a Wine problem/bug at all, we can do nothing to improve hinting support in FreeType. And crippling Crossover (by making it differ with WineHQ for no good reason) because of that is not a way to go IMO.

In any case if a Wine user wants to see correctly displayed TrueType fonts with correct document layout (as it depends on the rendered glyph metrics) he/she has to use patented FreeType. And that's for sure the problem of a Linux distro vendor who must take care of it.

Insert a short debate here about who's problem it is. Segue to a dream sequence where Apple grants licenses to open source projects and allows for redistribution for use within the project. Fade back to reality.

Lionel Ulmer felt we should have our cake and eat it too:

The only problem I see is with people having a self-compiled FreeType library with hinting enabled. Why cripple their configuration too by default ?

Is there no way to detect at compile / run-time what kind of FreeType library we link with ? Or, at the very least, let this be configurable in winecfg (or in the registry) as it does not seem to be the case with Mike's patch.

Huw Davies agreed, " We need to determine this at runtime really. I have come up with a way, but it's a bit of a hack - I've asked on the freetype list for a better solution. Once I have that I'll add a Wine specific bit to the flags returned by GetRasterizerCaps, x11drv can query this and take the appropriate action."

Huw then put two small patches together to fix the problem:

fonts: GetRasterizerCaps hinter enabled flag

fonts: ignore the gasp table when we have no hinter

7. Lotus Notes 6.51 on Wine 20050930

(2 posts) Archive Link: "Lotus Notes 6.51 on Wine 20050930 - Got it working"

Topics: Fixes

People: Kevin DeKorte

Kevin DeKorte had some notes on what it took to get Lotus Notes 6.51 running with the latest release of Wine:

Here are a couple of notes on making Lotus Notes 6.51 work on Wine 20050930

The previous version of Wine that worked properly was 20050725.

Triaging the version change was a lot of work to find out that I just needed to change the default version. Took me nearly a day to find it.

If I switch back the version to default, the crash happens everytime. I believe a file selection dialog is being loaded and there is a problem with that dialog in NT2K mode and it causes a crash.

The other thing that is odd is that the layout of the screen between WIN98 mode and NT2k mode is slightly different in 20050930, mainly on the widget that lists the messages.

Tracebacks are documented here:

8. Test Harness for winedbg

(1 post) Archive Link: "FYI: winedbg testing"

Topics: Debugging

People: Eric Pouechcvs

Since Wine deals with bizarre things not normally found on Linux platforms, such as PE vs. ELF files and different debugging formats, we've developed our own debugger. It has hooks into gcc, but it does a lot of stuff on its own. Eric Pouech has been the driving force behind it for quite a few years and this week he announced some new work he's done with it:

For those of you who might be interested, I wrote a test harness for winedbg.

It still doesn't cover all of the commands of winedbg, but it's very good starting point for catching some errors (and regressions). Basic features are tested (starting winedbg, step & cont, break points & watch points, global and local var access, expression & types handling)

Unfortunately, it's not ready yet for CVS inclusion. Anyway, if some of you want to do some real winedbg hacking, get back to me, we'll see how to share it in the most appropriate way.

In the details, the harness is made of:

  1. an extension of regular wine's test harness: it just allows the test program to control a child through the command line (input & output)
  2. a program to behave as a debuggee
  3. the testing tool itself (a regular wine test app, based on component 1.), which launches winedbg on 2. and sends commands to winedbg and checks the results

The reasons why this can't be included yet in cvs are:

For the rest of the story, while running the test on Windows & native dbghelp, lots of misimplementation of builtin dbghelp (and therefore winedbg) appeared. I did fix lots of them, and I'll submit them from now on.

The set of patch I've just sent to wine-patches are what is required to make the winedbg test pass on Wine, get ready now for the rest of the patches to make dbghelp (and winedbg) in sync with native dbghelp

9. Undocumented API Reference

(1 post) Archive Link: "undocumented APIs"

Topics: Documentation

People: Ivan Leo PuotiMicrosoft

Microsoft has undocumented API's? Nooooo.. not Microsoft.

Of course they have undocumented API's. For the most part, they're used internally between different components of Windows. However, the interfaces are exposed and it's not unheard of for programs (especially those created by Microsoft) to use those functions. Ivan Leo Puoti passed along a good resource for anyone interested in this stuff:

Hello, I would like to make a general appeal to not write wine code based on the docs at, because they're often misleading, incomplete or simply wrong, and do more harm than good. Please refer to "Windows NT/2000 Native API Reference" by Gray Nebbett, to the reactos team, or to me (I've got the book) instead, and always write tests for undocumented functions.







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 All pages on this site are copyright their original authors, and distributed under the terms of the GNU General Public License version 2.0.