Wine Traffic #149 For 20�Dec�2002

By Brian Vincent

Table Of Contents


This is the 149th release of the Wine's kernel cousin publication. It's main goal is to distribute widely what's going on around Wine (the Un*x windows emulator).

Mailing List Stats For This Week

We looked at 267 posts in 940K.

There were 67 different contributors. 41 posted more than once. 36 posted last week too.

The top posters of the week were:

1. News: Wine-20021219

14�Dec�2002�-�22�Dec�2002 (1 post) Archive Link: "News"

Topics: News

People: Alexandre Julliard,�,�Ove K�ven,�Lionel Ulmer,�News

Appearing now on a ftp server near you - Wine-20021219. Looks like with the flurry of activity lately the release cycle is about 3 weeks instead of 4. Alexandre noted the following:

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

Sorry for the slightly thinner issue this week. The reason is twofold, for one I found a lot of the threads boring and I figured you would too. The other reason is that I've just been busy at work. (At least I did get out skiing a little though.) Development is rolling along nicely though. Lots of Direct3D work is pouring in from Lionel Ulmer, Ove K�ven is having fun creating IDL and getting rid of headers, and bugfixes appear daily. Interesting factoid - more patches (in MB) have been submitted over the last 4 months than the previous year before that.

2. Implementation of wineboot

17�Dec�2002�-�22�Dec�2002 (7 posts) Archive Link: "Re: wineboot - Andy's version"

Topics: Patches, Utilities

People: Shachar Shemesh,�Andreas Mohr,�Matthew Davison,�Alexandre Julliard,�Francois Gouget,�

Shachar Shemesh posted an initial implementation of "wineboot". He explained that Andi Mohr did the actual implementation:

If anyone did not understand, my previous post was with Andy's implementation of wineboot. This post is with the changes to the rest of Wine to make wineboot fit in better.

Explained within the patch, wineboot " is a Winelib application that's executed by Wine on startup of the first wine process of a particular user." In particular it handles things like:

Matthew Davison had some stuff to add too, " I have some work to the RunOnceEx section of wineboot, once (and if) Andy's version is commited will send a patch."

A few days later the patch still hadn't been commited and Shachar asked what exactly was wrong with it. Alexandre explained, " I was hoping you would clean it up, not simply resubmit Andi's stuff. As discussed with Andi already, this thing is much too complex and over-engineered. It has to be a simple application that doesn't require user interaction or a dozen configuration parameters. "

Shachar felt if that was the case then perhaps a redesign was needed:

As this is the way you feel about the current wineboot, I think I'll go a completely new route. Please let me know your thoughts about the new proposed process.

In windows, some of the boot operations are done by the core "windows". These include wininit processing, win.ini, rename registry keys, and the services (can probably wait with these, however). Other things are performed by explorer when it first starts. These include the run and runonce keys.

What I'm thinking is incorporating the first group into the wine code itself (I'm thinking the server startup, synchroniously done). For the second group, create a wineboot program, and have a single option saying whether the wineserver should run it on startup or not.

Francois Gouget didn't like that idea though and thought the existing concept of a standalone app was the correct approach:

It is my understanding that if you put these in the wine server you will not be able to use the Windows APIs. This will make it unnecessarily complex to handle the move and renames since the paths will be windows paths.

Putting this code in a standalone utility will allow you to use the Windows API and then calling it from the Wine server (if that is the way we go) is just a fork away. It also makes the 'when is it called' more flexible which can come in handy.

3. Compile Time Comparisons / Tips

16�Dec�2002�-�19�Dec�2002 (11 posts) Archive Link: "How long does it take *you* to build wine?"

Topics: Build Process

People: Dan Kegel,�Michael Stefaniuc,�Tony Lambregts,�Joerg Mayer,�,�Bill Medland,�Alberto Massari,�Martin Fuchs

Dan Kegel (probably while waiting on a compile) wrote to wine-devel:

I got tired of waiting for wine to build, and started looking for ways to speed it up.

I have three systems handy: a dual 650MHz PIII, a 750MHz PIII laptop, and a 1.1 GHz Celeron with shared memory video (i.e. dog slow). To see if a parallel compile would help, I installed Red Hat 8.0 on all systems, and installed the RPM for distcc from

I then timed how long it took to do a 'make' after 'make clean' in a recent copy of the wine tree.

It does look like distributing the load helps a tiny bit, but it's not clear it's a big win over just building on the dual 650MHz machine. The fastest build I've seen so far is 19 minutes. I'm pretty sure I'm not doing things optimally yet.

So how long does it take *you* to do a clean build (just the 'make' part after 'make depend', say) of Wine-20021125?

I'll save you the time of reading the various reports and summarize it like this:

who time machine specs
Drew Ogle 6min 50sec dual 1800+ MP
Dan Kegel 8 min dual 1.2GHz P4 Xeon, make -j2
Dan Kegel 17min 21sec dual 650MHz PIII, 7200RPM disks, make -j2
Martin Fuchs 18min 2sec 1.8 GHz P4
P. Christeas 18min 30sec Athlon XP 1800, 256 MB DDR RAM
Dan Kegel 30 min 750MHz PIII laptop
Michael Stefaniuc about 30 min athlon 900, 512 MB RAM
Alberto Massari 41 min 32 sec Pentium III-M 600MHz, 256MB RAM, Mandrake 9, gcc 3.2
Joerg Mayer 47min 41sec athlon 550, 192MB RAM, gcc 3.2
Bill Medland 47 min Celeron 450, 128MB, RedHat 7.3
Tony Lambregts under 3 hours 300mhz Pentium, 96MB RAM
Alberto Massari 4+ hours Pentium 133, 64 MB

Some folks had suggestions for speeding up the process. First, Dan Kegel tried using distcc ( to distribute the compilation across a couple machines. He noted some speed ups, but nothing too astounding. Michael Stefaniuc highly recommended using ccache ( . While it would speed up the initial compilation, it made subsequent ones dramatically faster:

On a athlon 900 with 512 MB RAM it takes about 30 minutes for a full build, but only for the first run. On the second run it takes about 3-4 minutes :). Ok, i'm using ccache and it realy paid out during my -DSTRICT work. The cache hit rate had varied between 30% and 80%, depending what i've done. You get 30% - 40% hitrate for normal updates from cvs without doing a "make clean".

4. To Do List Updated

19�Dec�2002�-�20�Dec�2002 (6 posts) Archive Link: "Wine 0.9 TODO v0.7"

Topics: Status Updates

People: Dimitrie Paun,�,�Ender

Dimi Paun announced more revisions to the to-do list he created:

The next version of the 0.9 TODO is way past due, so I've decided to release it today:


Check it out, it's fun! :)

The new tasks added were:

5. COM Conformance Test Suite

18�Dec�2002 (1 post) Archive Link: "COM conformance test suite?"

Topics: Testing

People: Dan Kegel,�

Dan Kegel had an idea that generated no replies, at least none to the list:

Now that the Wine regression tests are starting to shape up, and people are starting to be able to run Visual Basic apps, maybe it's time for us to start thinking about getting ahold of the COM conformance test suite the Open Group did as a companion for their ActiveX standard definition.

The Open Group was willing to discuss this, but last time I checked, they wanted to know what was in it for them. (Well, they're not the Free Group, after all.) In particular, they thought it might take them a bit of work to separate the conformance test suite out from their "reference implementation" of ActiveX for Unix.

For those who haven't seen it yet, the Open Group's ActiveX spec ( ( ) is perhaps the only document defining Win32 API calls in a standards-body-like-way. (The Tru64 Unix doc, ( contains some related material. Might be worth archiving this before it goes offline as HP discontinues Tru64 Unix.)

The Open Group spec only covers a little bit of Win32, but it sure looks like a useful bit. The #include files it seems to define are:

which is a fair chunk.

6. Running Cygwin Apps Under Wine

17�Dec�2002�-�18�Dec�2002 (6 posts) Archive Link: "running cygwin apps(gcc etc.) under wine"

People: Chris Morgan,�Dmitry Timoshkov,�

Chris Morgan ran into a problem running apps compiled under Cygwin with Wine:

Trying to run my work related code build process under wine results in some failures with cygwin's gcc. Even with a simple hello world.c file and 'gcc -o test test.c' I get:

Any ideas why this is occuring? Is this due to issues with pthreads?

Dmitry Timoshkov explained, " Very likely this is due to the implementation of 'fork' in cygwin." That prompted Chris to ask, " Ahh, very cool. Is there anything we can do to keep cygwin from replacing wines/libc's fork with its own and presumably fix this problem?" .

Dmitry didn't think so, " I'm afraid it's impossible to replace cygwin's fork by an one from libc. Cygwin makes some assumptions about "environment" where it runs and accordingly patches virtual memory of a newly created process to mimic fork behaviour."

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.