Wine Traffic Brian Vincent

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 www.winehq.org
News Huw Davies Mike McCormack Rob Shearman Daniel Remenak News cvs

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)

  • Joystick force feedback support.
  • Beginnings of Win64 support.
  • Many MSI fixes and cleanups.
  • Font linking support.
  • Several OLE fixes.
  • Some fixes for MacOS/x86.
  • Lots of bug fixes.

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:

  • We can credit Daniel Remenak working a Google Summer of Code project for the force feedback (see WWN #285 for details.)
  • The Win64 support is being tackled by Alexandre as is the MacOS/x86 fixes. Both seem to involve some low-level changes.
  • The MSI fixes come courtesy of Mike McCormack and it looks like support for MSI transforms are in the initial stages. A transform is a way to take a standard MSI installer package and modify aspects of the installation separately from the MSI file.
  • Font linking was tackled by Huw Davies. I think it refers to a method to output strings containing characters from a variety of character sets.
  • The OLE fixes are part of the larger DCOM project that's been going on for over a year. Rob Shearman contributed about a dozen and a half patches for that.

Project Management Microsoft

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:

Folks,

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.

Web/HTML Status Updates Microsoft Dimi 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: http://wiki.winehq.org/MozillaIntegration 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: http://www.winehq.org/pipermail/wine-patches/2005-August/020059.html 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:

  • More functionality of MSHTML: there are leaks in its functionality. Although I don't think edit mode is something we should really care, there are things like refresh or stop.
  • WebBrowser control implementation - when we have its true implementation, MSHTML will become truly useful and in most apps HTML pages should work out of box.

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.

Project Management Ivan 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.

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.

Fonts CodeWeavers Krzysztof Foltman WineHQ Apple

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

    Add a Wine specific flag to GetRasterizeCaps that reports whether freetype's patented hinter is enabled. This will be used by winex11 to check whether it should honour the gasp table settings.

fonts: ignore the gasp table when we have no hinter

    Ignore the gasp table when we have no hinter.
Fixes

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.

  • I upgraded to Wine 20050930 and restarted Notes.
  • Notes crashed and complained about usp10 missing some entry points
  • I ran wineprefixcreate (Note that you cannot go back to Wine 20050725 after you do this, so back up you .wine tree before running this)
  • Ran winecfg and set usp10 to Windows Only
  • Restarted Notes
  • Notes seemed to work until I tried to save an attachment, then it crashed
  • Triaged the crash to a change on 8/15/2005 at 9:51CDT. The patch at this time, changes the default version from WIN98 to NT2K
  • Ran winecfg and set the default version to Win98
  • Restated Notes and the application works and saving attachments works

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: http://bugs.winehq.org/show_bug.cgi?id=2863

Debugging cvs

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:

  • we need to recompile 2. in order to make the test to take place (or at least to have its binary image). Actually, to do a full testing, we should have binaries images of 2. compiled by different compilers (winelib app with gcc & stabs, EXE with mingw & stabs, EXE with msvc & PDB...) so that we can also stress the dbghelp's support for the various debugging formats (stabs, PDB...)
  • I ran the harness both on Wine and Windows (with native dbghelp) (that's the good news), but there are some critic discrepencies, like first like number of a function being different (is it on first open brace or on first instruction ?), so the test is still not simply portable

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

Documentation Microsoft

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 undocumented.ntinternals.net, 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.