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).
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)
- DLL linking now done through import libraries.
- A couple of new tools to make Winelib easier to use.
- Many Direct3D improvements.
- Improved Windows compatibility of the regression tests.
- Lots of bug fixes.
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.
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:
- wininit.ini processing
- registry RenameFiles entries
- RunServices* / RunOnce* / Run registry keys
- win.ini Load= / Run= entries
- StartUp folder processing
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.
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 http://distcc.samba.org.
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".
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:
http://www.dssd.ca/wine/Wine-0.9-TODO-0.7.html
ChangeLog
- Bill finished moving CVS docu from User Guide to Devel Guide (B3)
- Alexandre implemented import libraries (D3), finished winebuild (D4)
- I fixed header location (mostly done by Alexandre :)) (E9)
- Status update from Jaco (C2), and Ender (E7)
- Brand new Introduction
- New tasks added (D5, D6, D7)
Check it out, it's fun! :)
The new tasks added were:
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 ( http://www.opengroup.org/onlinepubs/009899899/ ) is perhaps the only document defining Win32 API calls in a standards-body-like-way. (The Tru64 Unix doc, http://www.tru64unix.compaq.com/com/documentation/building/ 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:
#include <comcat.h>
#include <oaidl.h>
#include <objbase.h>
#include <objidl.h>
#include <ocidl.h>
#include <ole2.h>
#include <oleauto.h>
#include <olectl.h>
#include <oleidl.h>
#include <unknwn.h>
#include <urlmon.h>
#include <winerror.h>
#include <winnls.h>
#include <winreg.h>which is a fair chunk.
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:
ed. some lines deleted
8125556 [main] gcc -134958416 sync_with_child: child 134970152(0xE0) died before initialization with status code 0x1
8127752 [main] gcc -134958416 sync_with_child: *** child state waiting for longjmp
gcc: vfork: Resource temporarily unavailableAny 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.