Wine Traffic Brian Vincent

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

News CodeWeavers Transgaming codeweavers News TransGaming

This one didn't get any press, but CodeWeavers quietly released CrossOver Plugin 1.2.1 this week. There's no new features, just a hack to try to get distros with new glibc versions (RH 9.0, etc) working. About the only reference to it you can find is in the web store.

LinuxOrbit has a review of WineX 3.0:

Transgaming's WineX 3.0 continues to push the frontier's edge outward, enabling hard core Windows gamers the option to choose Linux without leaving their beloved games behind. With the addition of Point2Play, WineX 3.0 is getting much closer to delivering an easy to use bridge from Windows to GNU/Linux systems for gaming. While Point2Play is still a little rough around the edges, it is still a step in the right direction. With very little reservation we recommend Transgaming's WineX 3.0 to anyone insterested in getting their Windows games working under GNU/Linux.

Speaking of Point2Play, TransGaming released a maintenance upgrade for it. Version 1.0.1 was released Thursday.

You might have noticed we skipped this week for interviews. There was enough stuff going on that I decided to just let things calm down for a while until the WineHQ server settles down. Look for another one next week!

Ports

Pierre d'Herbemont sent a note to wine-patches to mention some initial work getting Wine to compile on MacOS X. His initial announcement gave a short overview:

First of all I have a good news :) : Wine is able to build on Mac OS X.

We decided not to follow WineHQ cvs version for early build, in order not to be so much disturbed by others wine development and not to produce bad patches, but don't worry ;) we are (of course!) planing to send patches, I hope they would be integrated...

Pierre then went on to list some configuration issues he ran into and what appeared to be a problem with DLL's loading correctly. His patch included the following notes:

Here is a patch which mostly enables compilation on Mac OS X. The support is not full as there is still some makefiles issues on which I can't find a *clean* correction and a new issue I discovered in this cvs version related to the libwine_port and the getopt function.

ChangeLog:

  • configure.ac
    configure
    Add Mac OS X Support, including Mach-O.
    Fix PowerPC recognition
  • Make.rules.in:
    Add the LDDYLIB definition for Mach-O support.
  • libs/wine/Makefile.in,
    libs/unicode/Makefile.in:
    Add Mach-O support, add target for .dylib
  • dlls/Makedll.rules.in
    Add an entry for .dylib building
  • tools/winebuild/import.c
    tools/winebuild/spec32.c
    Mac OS X linker does not support the same syntax as linux linker, add a case for darwin
  • scheduler/process.c
    Add support for the environ of darwin.
  • scheduler/sysdeps.c
    include/winnt.h
    For darwin the TEB should be in r13, fix it.
  • loader/module.c
    Add Mach-O recognition for executable.
  • libs/port/interlocked.c
    Add r0 preservation in interlocked functions in order lwarx to be effective and change ';' into '\n'.

Pierre mentioned they were using version 20030219 of Wine and gave a link to the repository on SourceForge.

Fixes

Troy Rollo posted a small patch adjusting addressable memory that made Borland's free compiler (bcc 5.5) work. Initially it sounded like he had managed to some how compile Wine with it, but really what he was doing was using Wine to run it and create executables. Dimi asked him some questions (below in italics) and Troy responded:

Do you build on Windows?
Until now, I have developed on Windows, but I will be continuing to target Windows from Linux using Wine to support the build environment, and possibly for testing of the application itself, together with plex86 or Bochs VMs as needed for testing under the target OS.
Could we run bcc in Wine on Linux to build on Linux using bcc?
Yes, this is what I'm doing.
How far do you get? Do you actually get an executable?
Yes. It produced (among others) an executable of 9402368 bytes (not including debugging information which is in a separate file) from 948 object files (not including libraries).
Does it run?
Not only does it run, it appears to work OK in wine.
What are the steps you need to take? A concise list of instructions would be nice :) I can post it on the Fun page, so other can play with it was well.
The setup of the Borland C compiler was quite straight-forward - I copied it over from an existing Windows installation. This was necessary rather than a full install because we use modified header files, but it appears the installation from the self-extracting executable won't run, so copying over from a copy installed on native Windows is necessary.

Then I put it in the PATH, checked out the code and built using exactly the same procedure I used to use under Windows.

Memory Management

We've covered Valgrind in past issues. This week Adam Gundy wrote in with new instructions for getting it to work with Wine:

A new version of the patch to valgrind needed to support WINE has been uploaded to Sourceforge:

It should apply cleanly to current valgrind CVS.

This version of the patch will now work with an unmodified WINE CVS version. This is because it now _fully_ implements clone() support - ie it really does create system level threads.

Currently only one thread can run at a time, so there are no locking issues in the main valgrind code.

To use with WINE, you need to get a CVS checkout of valgrind, then apply the patch using:

    export CVSROOT=:pserver:anonymous@cvs.sourceforge.net:/cvsroot/valgrind
    cvs login
    cvs co valgrind
    patch -p0 < valgrind-wine.patch.13

then build and install valgrind:

    autogen.sh
    ./configure
    make install

Get a CVS checkout of WINE by following the instructions at:

then configure (for debugging) and build:

    CFLAGS=-g ./configure
    make depend && make install

now you can start looking for bugs in WINE, and bugs in your own (debug) Windows code. Copy any DLLs/EXEs to somewhere WINE can get to them, plus copy any .PDB files that go with them into the same directory.

Run WINE under valgrind using eg:

    valgrind --num-callers=30 --workaround-gcc296-bugs=yes wine notepad.exe

or even:

    valgrind --num-callers=30 --workaround-gcc296-bugs=yes --gdb-attach=yes wine notepad.exe

enjoy.

Project Management CodeWeavers

A new WineHQ server was installed this week by Jeremy Newman from CodeWeavers. Last week the server was dealt a crushing blow from CrossOver Office downloads, Wine downloads, etc. The WineHQ server does everything - CVS, mailing lists, web site, ftp site, etc. I asked Jeremy what the new specs on the server were and he replied:

  • 4U Rackmount
  • Dual Athlon MP 2000
  • 2 GB of DDR 2100 ECC Registered RAM
  • 36 GB Ultra 160 SCSI HDD

We are planning on switching the server over to RAID very soon. (the hardware is already purchased), so when that happens, we will have the system on RAID Level 1 Dual Ultra 160 36 GB drives.

There was a little downtime last week as it was put in place, but for an unplanned upgrade it appeared pretty smooth. Some people experienced problems with the new sendmail, but most of those seem ironed out now.

Utilities

Dimi Paun announced some utilities others might find useful:

As I've reported earlier on the list, cvsup compiled for glibc 2.x (x < 3) systems does not work on the new glibc2.3 systems, such as RedHat 9, or Mandrake 9.1, due to the threading changes.

I've been looking all over the net for a precompiled binary of cvsup that works on these new systems, as cvsup is written in Modula 3, which is a bitch to setup.

Finally I gave up and did the work myself. I've created a complete binary package which can be download from:

    [ed. note: link removed, see below]

Note that the binaries are not small as they are statically linked, but they should work on all glibc2.3 system.

The archive contains the following files:

  • cvsup-glibc2.3/bin/cvpasswd
  • cvsup-glibc2.3/bin/cvsup
  • cvsup-glibc2.3/sbin/cvsupd
  • cvsup-glibc2.3/man/man1/cvpasswd.1
  • cvsup-glibc2.3/man/man1/cvsup.1
  • cvsup-glibc2.3/man/man8/cvsupd.8

Simply copy them to the /usr/local prefix. They are compiled to go to /usr/local, they may work even if copied in /usr, but I haven't tried that.

Enjoy!

Jeremy Newman ran into the same thing:

I noticed this to when I tried getting cvsup to run on the new server. (which is using glibc 2.3). I also had to build it myself.

As WineHQ does use cvsup and cvsupd as an option for getting the WIne tree, we should add a note about this on the using CVS page on the site.

Also, I will mirror your file in the winehq ftp site.

BTW, I built mine using the ezm3 version of modula-3 which was fairly simple to build.

Dimi uploaded his package to the SourceForge repository and listed them under Support Files.