Wine Traffic #217 For 2�Apr�2004

By Brian Vincent

Table Of Contents

Introduction

This is the 217th issue of the Wine Weekly News publication. Its main goal is to take apart electronic things not meant to be taken apart. 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 199 posts in 678K.

There were 66 different contributors. 34 posted more than once. 23 posted last week too.

The top posters of the week were:

1. News: Onebase Linux & Wine, WineTools Update

27�Mar�2004�-�2�Apr�2004 (1 post) Archive Link: "News"

Topics: News

People: Onebase,�Frank Hendrickson,�,�News

Earlier this week we posted a news item about Onebase Linux (http://www.onebase-linux.org) and its new support for Wine. Onebase is a new community-driven distribution. It features an entirely new package management system, part of which includes the ability to interact with Wine and Win32 programs. They've put together a gallery (http://www.ibiblio.org/onebase/onebase-linux.org/wineapps/) of applications that can be downloaded and installed using custom ".owm" installation scripts. These scripts vary in complexity and at the most basic level just download and run an application installer. At the other end of the spectrum it's possible to tell the script to manually extract cab files and use native DLL's (using Wine AppDefaults in the config file.) From their about (http://www.ibiblio.org/onebase/onebase-linux.org/About/aboutol.html) page:

Onebase provides fine integration of WINE software for easier and trouble-free installation and execution of Win32 applications through the "Onebase WINe support".

This support consists of the olm-wine master program and individual preconfiguration scripts for error-prone Win32 apps called .owm. These scripts with the olm-wine automate all the tasks and also dynamically notifies you of missing .dlls

Also an exclusive gallery of well-known tested Win applications has been provided to give you postive outcomes. It comes with the following features

The original link to that news story was provided by Frank's Corner (http://www.frankscorner.org) .

Which, by the way, Frank released version 2.1.0 of his WineTools (http://franksworld.net/winetools.html) configuration program. It provides support for the following:

Changes:

2. CVS to Arch Gateway

1�Apr�2004 (5 posts) Archive Link: "ANNOUNCE: CVS to arch gateway"

Topics: Project Management

People: Mike Hearn,�Alexandre Julliard,�

A few weeks ago (in issue #215 (?issue=215) ) we alluded to setting up arch (http://www.gnu.org/software/gnu-arch/) for revision control. Mike Hearn has done all the work and now a CVS to arch gateway has been set up. All commits are still done by Alexandre into CVS. It's too soon to tell if arch will be adopted, but this is a good first step:

I'm pleased to announce the public availability of a gateway from WineHQ CVS to the GNU arch version control system.

It marks the beginning of an experiment not just in new forms of source control, but in new ways for the Wine project to be organized and function. Nobody knows if it will catch on, but a few of us (me, dimi and alexandre) have been discussing trying out arch for some time. Carpe dium!

For those who already know arch, here are the details:

archive coordinates:

It is synchronised with CVS on the hour, every hour and a cacherev is generated once a week. There are a couple of useful scripts in the root directory, branch and merge which are described in the README.ARCH file.

It is mirrored here:

For your convenience, and for people who have never used arch before, here is an adapted form of the README file. It's available in pseudo-HTML here:

README.ARCH
Mike Hearn <mike_at_navi.cx>

GNU arch is a distributed source control system. Unlike CVS, arch trees can be branched and branched again with no write access to the original archive. It has a variety of other interesting features - for instance, it uses atomic commits and can operate using a variety of network protocols. For more information see

The rest of this readme is going to take the form of a tutorial on how to use arch with Wine. We'll start with the really basic tasks that even non-developers may wish to use, and work up to advanced usage (branching and merging). It will not answer every question you have, for that use the wine-devel mailing list for discussion :)

Tracking Wine development

You might not be reading this file from an actual arch project tree, so let's start with how to get a copy of the gateway tree. First of all you need to install "tla", the reference implementation of arch. You can get it from the gnuarch.org website, but a simpler way is to use the prebuilt binary available here:

Download, chmod +x, copy to /usr/local/bin and you're set. The binary should work on any Linux distro. Yes, it's large, the arch build system contains local copies of various libraries.

Now it's installed, run the following command:

Once it's registered succesfully (you get a message when that happens), you can run the following command to check out the tree:

This will place a copy of the gateway tree into the winehq/ directory. "winehq" is a good name to use, because you may later wish to download other branches or even make your own, but there will only ever be one WineHQ tree - the one controlled by Alexandre Julliard.

Yes, I know mike@winehq.org isn't a valid email address, it doesn't matter, the email is only for namespacing and identification reasons :)

The checkout will take a long time even on a fast link: the Wine sources are 10mb.

Once downloaded, updating the tree is easy:

So, now you have an arch project tree, what can you do? Arch has a lot of interesting commands, try "tla changelog | less" and "tla missing -s".

Have fun!

Simple development

The easiest way to use arch for development is the same way we use CVS: by making changes in a tree, generating a diff from those changes, then emailing in the patch. Let's see how that works.

First of all, we make a change to the tree. Then we use:

to get a patch. In fact, this will generate a lot of extra stuff that you don't really need - feel free to remove it, but it's not required; patch can strip out garbage from patches automatically.

You can get diffs for individual files with "tla file-diffs".

Be warned! These commands work against the last revision you updated to, they do *not* work against the latest version in the remote archive like CVS does. So you probably want to update first.

However, unlike people just tracking the tree, you DO NOT want to use update! What update does, roughly speaking, is reverse changes made to the tree, apply the missing patches in turn, then reapply the changes. If there are any conflicts they appear in patch style .rej and .orig files.

There is a better way. Arch has a very interesting and powerful command called "star-merge". Star-merge allows you to merge your tree with another tree (subject to certain rules), in a Just Works(tm) fashion. It will deal with repeated merges, and it works if the person you are merging from previously merged with you.

To make this simpler, I've written a script that figures out what you branched from (if anything), and then merges from it. In effect, this is like "cvs update".

This operation can be quite slow (because it involves constructing multiple trees and comparing etc), but it is generic and will work both with the gateway tree and branches - and it gives 3-way merge inline conflict markers too.

If you want to do it faster, and you don't mind having patch style .rej files generated in the case of conflicts, try:

which simply downloads and applies each patch in turn. "tla update" does work too, why not try them all to see which you prefer?

More advanced development

So, here comes the interesting part. Now we've covered the basics, it's time to find out how to make our own branches and commit to them.

You need to do a bit of setup. Firstly, you need to tell arch who you are:

You have to use an ID of this form, arch won't accept others. Now you need to create your own archive.

An archive is a rough equivalent of a CVS repository with one key, fundamental difference: an archive is a personal thing which can contain trees from many different projects. Typically a person has only one archive, though there's nothing to stop you having more. Archives are just directories and files, no special server software is required to run one. You just need some web space.

The basic workflow with arch goes something like this:

  1. Write patch
  2. Commit to branch
  3. Upload to a mirror of your archive

Your actual archive is usually kept locally, which means you can work and commit offline. You then mirror the archive on a remote machine so others can access it. If people want to work on your tree, they branch it, set up their own archive and then you pull from that. In other words, only you have write access to your own archive.

So, you need to create a directory to hold your archive, like this:

The named directory should not exist, but its parents should. An archive name must have the form of an email address followed by two dashes followed by a name. I've named it after the year of creation which is pretty common, but it can be called anything.

Now, to speed things up, you probably want to create a revision library. This is basically a cache (using hard links to be space efficient) of revisions. You probably want it. Make one like this:

OK. Now you just need some web space. Arch can write to web space using ftp, sftp (ssh), or WebDAV. You probably want sftp. If you don't have any web space you can use talk to me and I'll put you in touch with people who can give you some space specifically for hosting archive mirrors.

For now, don't bother with a remote mirror. Just play with a local copy, that way you can delete things if you make a mistake (you can delete a branch with rm -rf inside the archive, nothing will break).

Let's say you wish to branch the WineHQ tree, and start work on the winecfg program. The simplest way to do this is to create a directory somewhere that you will keep all your wine trees in. I use /source/wine/arch. Then do this:

The branch script is in the root of the gateway tree, and is written by me. It's designed to let you rapidly branch a given Wine tree. It works by "tagging" the new tree in arch, then duplicating the current tree using hard links before finally forcing the duplicate tree to the new branch.

WARNING! WARNING! WARNING! WARNING! WARNING! WARNING! WARNING! WARNING!

If you use the branch script you MUST use an editor that breaks hard links. emacs does by default, vim does if you :set bkc=no (though be warned, this will interfere with some programs that invoke vim like crontab -e). zile does not.

If you want to use an editor that does not break hard links you must remove the -l option from cp in the branch script so a real duplicate is made. This uses more disk space and is slower to copy, but is safer.

The result is a new directory called winecfg/ created as a sibling of the current directory. You can now commit to this tree however often you like. Running merge will update the branch from the tree you branched from (in this example, the gateway tree).

You can branch from that tree again, and so on. Other people can branch from your tree in the same way! Feeling giddy with power yet? No? Good. Remember that patches which aren't in the mainline tree aren't reaching 99.9% of the users - being able to branch is useful but don't use it as an excuse to not get patches upstreamed!

The new branch is put in the default archive and the name is derived from the current, for instance running branch in mike@winehq.org--wine/wine--mainline--0.9 with the parameter "winecfg" produces a branch with the name mike@navi.cx--2004/wine--winecfg--0.9

Now you need to publish a mirror:

and update it when you have done some commits

which actually uploads the changes. If you are always connected, you can run the first make-archive command (back when you created your archive) with a remote location straight away, but doing it locally then mirroring is more common.

Finally, tell people the URL of your archive so they can register it and grab your tree. That's it!

Oh one other thing to mention is that hard linking trees together like the merge script does is sort of experimental with Wine. I've tried it and not seen any big issues as long as you use an editor that breaks hard links, but if you spot wierdness related to that let me know.

Have fun! If you have any questions ask them on the wine-devel mailing list.

3. Possible Execshield / Prelink Solution

26�Mar�2004 (1 post) Archive Link: "Call for kernel patch testing"

Topics: Architecture

People: Mike Hearn,�

Do you like to compile your own kernels? Do you like trying out new patches to see what breaks? If so, we could use your assistance..

Problems caused by Execshield and Prelinking still plague Wine development. Thus far no good solutions have appeared. Alexandre is pretty tired of constantly working around problems caused by other projects. Mike Hearn explained the problem faced by Wine interacting with newer kernels:

Basically, we need to reserve address space. There are two ways to do that, the first is using my preloader (which is nearly turned into patch form to see us through the intermediate time), and the second is by using a linker script to define a new ELF section of the right size and location.

Because of a bug in the binfmt_elf module of the kernel, the linker script approach doesn't work. The kernel ignores the protection flags on the ELF section and doesn't make them restrictive enough - in other words, we will have the same problem that Alexandre's BSS hack had way back in the day.

But a solution might be on the horizon! A kernel patch seems to solve all of the problems. Mike asked for help testing it:

As part of the ongoing efforts to work nicely with execshield/prelink, the following kernel patch was developed (not by me I hasten to add):

However it needs testing so the kernel guys can be sure it'll not break stuff. If you are the type who runs their own kernel, please apply this patch and let us know the results! Everything should be fine, it's just a bugfix for the edge cases, but the elf loader is security critical so it needs widespread usage before it can be upstreamed.

4. Winelib Apps Redirecting stdout

25�Mar�2004 (8 posts) Archive Link: "redirecting stdout with WineLib"

Topics: Winelib

People: Ferenc Wagner,�Alexandre Julliard,�

Ferenc Wagner ran into a problem with Winetest, " Hacking away on winetest I encountered the following problem: under Windows and Wine (running cross compiled binaries) it's possible to redirect the stdout of a child process with CreateProcess using STARTF_USESTDHANDLES. However, if I CreateProcess an .exe.so from the WineLib version, the redirection is ignored. The create_process function in process.c acts on this option in both cases, but I didn't investigate further. Does anybody have an idea why this happens? "

Alexnadre gave a brief explanation of what could and couldn't be redirected, " The Windows std handles get redirected but not the Unix ones, so if the Winelib app is using Unix stdio functions the redirection won't have any effect."

Feri wondered what might need to be done to support it, " Unfortunately this is exactly what the ok() and trace() macros do in the tests. In the light of this I'm surprised that the cross compiled binaries work under Wine. Is there a fundamental reason that it can't work under WineLib, or is it a simple lack of code? If the latter, what is missing? "

Alexandre said, " Cross-compiled binaries use msvcrt so they don't have that problem. What's missing is to allow reading/writing to a Windows console through a Unix fd; it's not exactly trivial to do. "

5. Source Code Visualization

28�Mar�2004�-�31�Mar�2004 (6 posts) Archive Link: "Source code visualization tools?"

Topics: Utilities

People: Joel Konkle-Parker,�Martin Fuchs,�Joshua Walker,�Blake Leverett,�Mike Hearn,�

Joel Konkle-Parker wanted to know if there was a good way to graphically show the layout of a program:

Is there such a thing as a source code visualization tool that makes a "map" of a program's source? Kind of like:

I'm basically looking for something that will help me "see" how a program is laid out so that I can start working on it.

Lots of different solutions were given. Martin Fuchs had the first suggestion, " Try out Doxygen: http://www.stack.nl/~dimitri/doxygen/ (http://www.stack.nl/~dimitri/doxygen/) It's a very nice source code documentation tool and can also display call graphs."

Joshua Walker knew of another tool:

You are looking for "Source Navigator" It's here...

It's pretty cool if you want to follow what goes where. All the pretty arrows too. (It's horazontal along the top of the screen, not vertical) You can follow functions, stucts, header files. I used it when I was a programmer...

Blake Leverett thought emacs worked pretty good for just browsing through code: " I was looking for a similar thing a while back. One great tool for navigating the wine source is the etags program. In the wine source directory, type 'make etags'. This makes a file called TAGS. Then, start emacs, and type alt-x visit-tags-table, and load the tags file. You can navigate the source by function. See the tags manpage and the emacs manpage for the tags section for details."

It wasn't clear if Joel had meant to use one of these tools with Wine or not. If so, Mike Hearn wasn't sure how use useful it would be. Instead, he offered a quick overview of how things related to each other:

I don't think an automatic tool would be very good at this with Wine. It's a ridiculously complicated codebase, not through choice mind you, that's just the way Windows is.

Really at some point we should provide better high level developer documentation like this - I remember finding it confusing too.

Basically, the most important code is all in the dlls/ directory. The other directories are either supporting code (for booting the emulator, unicode tables etc) or are holdovers from the old code layout (windows/) and is being slowly moved into the dlls/ directories. The code in windows/ is a part of USER, basically.

Knowing the windows architecture helps. Basically in NT based systems you get:

Is that what you meant? Best way to learn the source is by reading it, and then asking about the parts you don't understand basically.

6. Testing Games

29�Mar�2004 (29 posts) Archive Link: "Game support"

Topics: Testing

People: James Perry,�Mike Hearn,�,�Lionel Ulmer

James Perry tested some games with Wine and reported on what he found:

I've been following Wine development for a while but now I think it's time to contribute something. I don't use Windows anymore (except for PowerPoint at work), but I decided it would be good to be able to play some games on Linux. So I grabbed Wine from CVS, compiled it up and tested some games, with the intention of finding where the problems were and hopefully fixing them. I have put my results on a web page at:

to avoid making this posting even longer. Note that I haven't looked in detail at most of these yet, I just tried them out once to see what would happen. I'm gradually working through the list, debugging them.

I've already submitted one patch (to solve a D3D blend mode problem that affected SonicR). I have traced a number of the other problems to specific aspects of Wine, but I'm not sure how to go about fixing them. Any advice on these points from experienced developers would be welcome

Of the 21 games he tested, 15 installers worked to some degree. Of those, 6 games worked. That gives us a 29% success rate out of the box. Mike Hearn and Lionel Ulmer offered some suggestions. Lionel pointed out that one of the games, Dungeon Keeper 2, had some workarounds that enabled it to run with Wine.

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.