Wine Traffic #215 For 19�Mar�2004

By Brian Vincent

Table Of Contents

Introduction

This is the 215th issue of the Wine Weekly News publication. Its main goal is to glow in the dark. 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 (http://www.winehq.org)

Mailing List Stats For This Week

We looked at 124 posts in 465K.

There were 48 different contributors. 28 posted more than once. 28 posted last week too.

The top posters of the week were:

1. News: TransGaming Updates

13�Mar�2004�-�19�Mar�2004 (2 posts) Archive Link: "News"

Topics: News

People: Transgaming,�Gavriel State,�,�News,�TransGaming

TransGaming's March Development Status (http://www.transgaming.com/showthread.php?news=111) and Voting Report has been posted. A lot of audio work is being tackled. A new ALSA driver is being developed and latency issues in games such as Medal of Honor: Allied Assault have been fixed. The top ranked technology items in February were:

It seems a recent editorial has caused a bit of a stir with TransGaming. (We linked to it last week.) The author of that editorial wondered why development of Mac titles using WineX should be supported with dollars coming from the pockets of Linux users. Gavriel State (http://www.transgaming.com/gavstates.php) and Vikas Gupta (http://www.transgaming.com/presmsg.php) both updated their columns on TransGaming's website to address cross-platform development. Gav also went on to discuss a bit about their releasing their source code:

Another question that has come up recently is that of our original business model, which included a provision for relicensing our DirectX source code if we sustained a membership of 20,000 users or above. Unfortunately, the relicensing of the Wine project from a very open X11 style license to the LGPL threw a wrench in those plans in April 2002. We talked about those changes, and how they would affect us in a Gavriel States column that same month, and removed mention of further source code relicensing from our site at the same time.

2. Investigating Arch for Revision Control

17�Mar�2004 (5 posts) Archive Link: "Branching/version control [was Re: cards.dll]"

Topics: Project Management

People: Mike Hearn,�Dimitrie Paun,�Greg Turner,�

This topic came up on IRC so I was quite happy when Mike Hearn mentioned it on the wine-devel list as well. There has been a bit of discussion about moving from CVS to another revision control program. CVS has definitely served it's use over the years, but moving to something else may provide enough benefits to offset the change. Mike briefly summarized what he was considering:

Perhaps Wine should start considering a kernel-like approach with some developers having their own trees where some experimental patches are tried out first then percolate up to Alexandres tree?

Another thing I'd really like to see is a move to GNU arch version control - it makes distributed development and branching a *lot* easier. I talked to Alexandre a bit about this at WineConf, and he mentioned on IRC that when arch is supported by emacs he'd think about it. Well, I now see on arch-user that there is such support, and the arch tools are maturing rapidly (see zoomarch etc).

It might be worth doing an experiment on using arch for Wine development.

Maybe if I get some time this holiday I'll try reviving my program to parse CVS commit messages back into filesystem operations and begin keeping an arch archive in sync with CVS so people can try it out. The last time I tried it I found turning commit messages into FS ops reliably was a pain in the ass, but I'm better at shell scripting these days.

I already parse commit messages in realtime for CIA (our irc commits bot) so I could easily extend this and put the results on navi.

What do people think?

The emacs tool that Alexandre prefers is pcl-cvs. It's a front-end to CVS that allows many things to be performed as a single keystroke. Dimi cautioned against switching to a system people are less familiar with:

arch sure sounds interesting (except for the file naming conventions :)), but before we can consider switching we *must* have infrastructure available that's comparable to the CVS one. And here I mean:

Given that repositories are just files on FTP servers, maybe cvsup is not needed, but the patch facility we have is a must.

When all that is in place, we may consider looking into it, to see if the switch is worth the pain. Please remember that virtually everybody knows CVS, whereas almost no one knows arch, so for new (and existing developers) it's a big pain to switch. So we must have some pretty important reasons to go down this path, and "arch is a cool concept" does not qualify :)

This led Mike to put together a really nice list of things that arch could for Wine and how development could be improved. Some of the tools Dimi wanted replacements for already exist:

(and concerning cvsup...) Arch already has this built in, effectively. Arch works in a fundamentally different way to CVS - it's based on applying changesets in order rather than keeping track of HEAD and working backwards.

ie running tla get wine or whatever actually downloads the first checkin then all the patches and applies them in turn. Obviously that's too slow for most projects so you can stow cached revisions (ie tree snapshots) along the way so it only downloads the last revision then works from there. That only occurs on initial checkout of course.

Arch works with changesets natively, so you can run the relevant command with the patch ID to get this sort of output at any time.

While everyone knows CVS the subset of commands we all use is tiny, mostly because only Alexandre commits. In fact I'd guess 99% of CVS usage on wine is:

The equivalents in arch are:

There is no equivalent for file-based log/status AFAIK as arch doesn't track files individually like CVS does. The upside is that arch understands things like file renames/moves/symlinks.

OK, so why should we use arch?

Wine is a project that operates similar to the Linux kernel. There is a benign dictator, who controls CVS. We all grab CVS, hack in our own branches, separate the changes out into a patch and email it to wine-patches. Normally, if we got it right, Alexandre will check it in forming a logical changeset, and we then all run cvs update which downloads everyones changes.

This works OK but has a number of disadvantages:

No branches.
Some Wine work would be best done in parallel to the main tree. For instance, the filesystem work, the WM rewrite etc. Wines current modus operandi makes this very hard, as effectively CVS HEAD must be at least dogfoodable at all times. This also makes it hard to do R&D projects like the shared memory wineserver while keeping the results of that R&D usable.
Hard to work on locally
Not every patch we write gets checked in, this is the reality of life working on Wine. Sometimes because those patches are incomplete or wrong, sometimes because they get forgotten or missed, sometimes because Alexandre doesn't agree that the code belongs in the main Wine tree (things like the system tray patch, delayed debug tracing patch etc spring to mind).
Over time, a particular checkout of wine will accumulate debugging cruft, random unchecked in patches and so on. I already have one tree I've practically abandoned for new development because the differential got so large (11,000+ lines). It gets hard to separate out individual changes into atomic patches, especially when patches depend on each other.
Yes you could say I should never have allowed the diff to get so large, and believe me I wish it hadn't happened, but in practice people still use and apply patches like systray/debug tracing and expect me (!) to maintain them, so I need to keep them around in some form. There are also patches in there that bounced pending extra work that I never got around to and so on.
Nowadays I simply use separate checkouts of CVS to try and manage it all.
CVS is not changeset oriented.
It's really hard to easily do regression checks because the closest CVS has to this is date based rewinds. We try and slap changesets on top using patch.py, which works well, but CVS is not naturally inclined towards it. Arch lets you say "rewind to this changeset" and it'll just do it. Binary searches become a lot simpler.
Hard to get into The Zone
Sometimes, some people or teams of people will have a mad coding session and produce a ton of patches. The Direct3D work by Jason, Raphael and Christian last year is one good example. My WineCfg work was another. Unfortunately our current model makes this a total pain in the ass because the patches are against CVS not your previous work. I ended up writing some scripts to help with this, by having two trees which I applied patches to in sequence then generated a diff against. It was annoying. This is especially true if AJ bottlenecks - for instance during some of the D3D work he was on holiday.

Why does arch work better?

Arch is far from perfect, in particular it's rather quirky and has a ridiculously complex command line interface. However, it has one feature that is make or break : distributed branching/merging.

In arch you can have a tree in an archive somewhere up on the net, and others can make a branch of it in their own archive and start checking in changes. They can remerge periodically and arch will just deal with problems like multiple remerges (in both directions). The owner of the original tree can merge the branch into their own when the time is right, or cherrypick changesets and just apply them.

In other words, I could branch WineHQ, and make some changes, then you Dimi could branch *my* tree and make some changes yourself and so on.

So how might Wine development look in a post-arch world?

Here's one vision. See what you think.

Alexandre of course remains the ultimate maintainer and dictator of Wine. His tree is the canonical one which we all work from, and he does releases of his tree a la Linus.

However, let's say I engage on a particular project (make WinFoo work). Maybe I'm doing it for a customer, maybe I just want to make people in #winehq happy. I can grab WineHQ, branch it, and start committing. Along the way, I can submit each changeset back to wine-patches with a very simple script: arch will generate a whole-tree changeset with one command. When I next commit of course the diff will be reset to zero so I don't end up with bits of other patches interfering.

Alternatively, if there are a lot of patches which depend on each other, Alexandre can pull the tree directly and use archs built in merging operations to synchronise the two. I can keep on working while this is going on by the way - AJ can merge with my tree as many times as he likes, and vice-versa.

Let's say only 90% of the patches I write to make this app work get checked into WineHQ. Users who only care about this app are still happy as they can just "tla get mike_at_navi.cx--wine--winfoo" and grab a version of Wine that works for their app. The community is happy because the bulk of the patches got back to the main tree anyway.

Let's say Jason, Raphael and Christian have another D3d codefest. The best way to work on this is for one of them to branch WineHQ and start work. The others branch this subtree *again* and begin work on their own trees. The temporary D3D "maintainer" merges with the other guys work, and so nobody bottlenecks on AJ or has to stop work for a few days while the patch queue clears so they can get clean diffs easily.

The end result of that work can be then trivially merged back into WineHQ. Alexandre can review the entire patch at once to get the zeitgeist of it, while still seeing the progression of the code if he wishes. Meanwhile the huge code churn doesn't impact others working on other parts of the codebase.

It'd also make it practical for Wine to split into subprojects for really huge pieces of work. For instance, currently MikeM is hacking on MSI alone. If he had the ability to setup a separate project for it, and invite others to begin work with him, it might be easier to get people involved. Once the work has matured the project can be terminated and we go back to the central peer-reviewed model.

So, what do people think? There are tools to sync CVS and arch, I can set one up over the holidays (starting for me on saturday) so we can get a flavour of it, if there is interest.

Greg Turner uses it for other work and likes it:

I'm using it at my new job and it's pretty dope imho. There are a few downsides, some already have been mentioned (those--horrible--names, for example). Others I have noticed:

Despite the above and a few other nits, I really like it. Even those--damn--names start to get comfortable once your ring finger builds up the requisite strength & dexterity :)

Erik de Castro Lopo also had good things to say about it.

3. WineHQ AppDB Source Released

15�Mar�2004 (1 post) Archive Link: "WineHQ AppDB Source"

Topics: WineHQ

People: Jeremy Newman,�

Wine's AppDB has seen it's fair share of challenges. Over the past week some volunteers have decided to put some time into cleaning it up. To facilitate that, Jeremy Newman decided to open up the backend code that makes it all work:

I have opened up the source to the WineHQ appdb. Anyone with spare time and some PHP skills is welcome to help improve it.

The tree has not been touched in over a year. I did some work to clean it up for this import, and thats about it. I will be available to answer any questions on it.

Check it out:

If there is interest, I plan to switch the online version to auto-update from CVS like the lostwages tree does.

Patches updating it have already started to appear.

4. Win32 Packages of Wine on SF.Net

17�Mar�2004 (3 posts) Archive Link: "Win32 packages released on sourceforge"

Topics: Testing

People: Ivan Leo Murray-Smith,�

Ivan Leo Murray-Smith announced that PE builds of Wine can be found on SourceForge:

The win32 packages of wine are on sourceforge, you can get them from

or to view the win32 packages only

So if you're the type who likes to replace Windows system components, you might find it interesting to replace things like notepad and comctl32.dll with the Wine equivalents.

5. Delayed Debugging Patch Updated

13�Mar�2004�-�14�Mar�2004 (5 posts) Archive Link: "Updated debug delay patch"

Topics: News

People: Mike Hearn,�,�News

Mike Hearn updated his delayed debugging (http://www.winehq.org/hypermail/wine-patches/2004/03/0134.html) patch:

Here is the updated version of my debug delay patch, back by popular request (well, ok, one person asked for it :)

Usage is simple:

Hit f12 in any window to switch debug tracing on/off

6. Creating the Registry Without x11drv

15�Mar�2004�-�17�Mar�2004 (4 posts) Archive Link: "Rundll32 needs X"

Topics: Configuration

People: Vincent Beron,�Ove Kaaven,�,�Ove K�ven

Vincent B�ron ran into a problem with the new registry creation:

Since wine.inf is now used as the source for the default values for the registry (via rundll32), importing it absolutely needs X (whereas the older regedit method didn't when importing a .reg file). This can be a problem for people running wineinstall via ssh from a Windows box.

Is there a reason rundll32 needs user32 and cannot delayimport it?

Ove K�ven had a workaround for using the console driver, ttydrv, instead of X:

You're not going to gain anything by letting rundll32 not import user32, because it has to load all the dlls it's telling to self-register anyway, and many of them will import user32 themselves even if rundll32 don't.

In my debian packages I go the ttydrv route, with the following patch (http://www.winehq.org/hypermail/wine-devel/2004/03/0298.html) to make ddraw.dll load and self-register without crashing under ttydrv.

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