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.

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...

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'.

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.

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

http://sourceforge.net/tracker/index.php?func=detail&aid=710006&group_id=46268&atid=445588

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:

http://www.winehq.com/?page=cvs

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.

• 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.

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!

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.