Review of wine 0.9.44 on revu.tauware.de

[Scott Ritchie]

On Sat, 2007-09-08 at 08:58 +0200, Stephan Hermann wrote:
> Moins Scott,
> 
> Scott Ritchie schrieb:
> > On Thu, 2007-09-06 at 08:35 +0200, Stephan Hermann wrote:
> >   
> >>
> >> Well, there is no problem with 32bit packages on 64bit arch.
> >> It's compiled with -m32, so we have  32bit  compilations for  amd64.
> >> Regarding -m32 compiled libs,  they are sitting normally in /usr/lib32
> >> and not in /usr/lib on amd64 releases.
> >> The current package in revu but, is installing those -m32 compiled libs
> >> to /usr/lib, which is not "correct" for this.
> >>
> >> Therefore, we have two possibilities:
> >>
> >> 1. For 64bit archs, we compile with -m32, installing the libs to
> >> /usr/lib32 and leaving the binary package names like they are on i386.
> >> With this, we are running into problems in the future, when we ship as
> >> well a  native windows64 supported version of wine on amd64
> >>     
> >
> > The hypothetical native Windows64 version of Wine must still support 32
> > bit windows applications.  There is no need for separate wine32 and
> > wine64 packages, as they would both always need to be installed together
> > - otherwise, applications will mysteriously break.
> >
> > While Linux 64 doesn't assume that 32 bit libraries are available,
> > Windows does. Wine must therefore do the same thing, for much the same
> > reason that it still has 16 bit support.
> >   
> AFAIK has Windows as well only 32bit libs on board to let 32bit windows
> apps run on windows 64, right?

I don't believe we can make this assumption.  There's almost certainly a
64 bit application out there which depends on 32 bit dlls in some way -
either directly or indirectly.  It may even be an application that's
part of Windows itself!

> Therefore, you actually have 2 separated (not in windows, right, because
> it installs everything by default) wine versions.
> One which can only run 64bit windows (the apps are really rare, true)
> and 32bit windows.
> Actually regarding this, we could ship in the wine packages the native
> versions (means 32bit windows in wine & wine-dev on ia32 and 64bit
> windows in wine & wine-dev for x86_64) and additionally when the user
> wants to run 32bit windows app, he could install wine32 support.
> The 16bit support of windows is history. It's only there for old apps
> from win 3.1/win95, I wonder when MS is removing this crap.

We couldn't have two "separate" Wine versions, as we'd still need a
single wineserver managing messages between 64 and 32 bit Windows
applications.

Admittedly, how this is going to be solved is still an open question
upstream, but there's little value in making a guess ourselves right
now.  We can always modify the packages later once it becomes
appropriate.

> 
> > You are right that Wine's 32 bit libs should go into /usr/lib32 though
> > -- that's a fairly simple change; just move the install target on the 64
> > arch.  Later, a combined 32 and 64 bit package would put the 64 bit libs
> > into /usr/lib (and the old 32 bit ones into /usr/lib32).  In the
> > meantime, there's no real change moving from /usr/lib to /usr/lib32
> > since we don't yet have any duplication and both are in the path.
> >   
> For this, you should update the package right now. So, it's clean and we
> don't have to change anything.
> Secondly, in the package itself, there is a "gcc-multilib [amd64]"
> build-dep missing, without it it can't compile in -m32 bit mode.
> 

It's how I've been spending my weekend :)

> 
> Let's get it done correctly, tbh, if we get a cool wine package for
> hardy running 32bit apps on 64bit linux, that's for Ubuntu^WCanonical
> Marketing a bit better...;)

Also interestingly, Wine 1.0 might ("should") come out some time during
Hardy's release cycle.  The idea of being so involved in something that
will become a major selling feature of Ubuntu is really exciting me.


Thanks,
Scott Ritchie