Wine versions and Debian

[Lennart Sorensen]

On Mon, Sep 13, 2010 at 05:17:49PM -0400, Christopher Browne wrote:
> It was never a big deal when people were on IA-32; consider the mix of:
> a) IA-32 architecture,
> b) Windows code, compiled on and for IA-32,
> c) Linux kernel and libraries, running on IA-32,
> d) WINE, compiled on and for IA-32
> 
> With IA-32 everywhere, everything matches, so there's no issue getting
> it all to work.
> 
> When you change some of those layers to run x86-64, things get
> somewhat hairier.  Not *alway* hairy - I had an appalling moment a few
> years ago when I realized someone had taken PostgreSQL + Slony-I
> compiles done on a RHAS (Red Hat Advanced Server) IA-32 system, and
> installed them in a "looking somewhat production-y" fashion, on an HP
> Opteron box running SuSE/x86-64.
> 
> I was more than just nominally amazed that, despite two layers of
> mistakes (e.g. - wrong architecture, as well as wrong distribution),
> it had all worked with a sufficient lack of flaws that nobody had had
> reason to even notice the mistake.
> 
> Sometimes the mismatch "just gets handled."  Someone had to do some
> amount of work to get that to be the case.  But, as in my "appalling
> moment," sometimes it's mighty transparent.

SuSE I believe has biarch support similar to redhat.  So 32bit programs
should work fine on a 64bit x86 system.

> (The other characteristic case is with IBM AIX.  On AIX, you can mix
> 32 and 64 bit binaries with quite a lot of impunity.  Sometimes there
> are *spectacularly weird* memory management issues that come up.  But
> quite often,  you can even run 32 bit binaries, and seemingly mostly
> have access to 64-bit-flavoured services.  IBM put a lot of work into
> this stuff.  They've got a group that deeply understands this sort of
> thing.  I don't want ever to...)

AIX had to put work into it since they run a 64bit kernel, with a 32bit
user space, except for a few applications where 64bit is worth using.
x86 is one of the few if not only architecture where 64bit is almost
always better than 32bit.  On other architectures you just gain more
memory space (great for databases and such) but loose performance due
to larger pointers which take more cache space and more memory bandwidth.

Debian on powerpc has 32 and 64bit kernel options, but user space
is 32bit.  Only a few applications get compiled for 64bit in the cases
where it makes sense.  If the program has no need for a 64bit address
space, then it does not make sense.  It just makes things slower.
sparc is the same way.  mips is as well.

x86_64 is better than 32bit because AMD did a number of things:
- They doubled the number of registers (this really helps performance in
  most cases).
- They scrapped x87 in favour of SSE for floating point.  Technically it
  still supports it, but AMD recommended avoiding x87, and both Linux and
  Windows explicitly forbid x87 use in 64bit code, so that issue has been
  taken care of.  Future x86_64 processors may choose not to support x87
  at all if they want, although that means they also give up 32bit support
  altogether (which very well could happen some day).
- They added some useful new instructions.

Other architectures have generally just made the address space bigger.
Without new or improved instructions or increased register count, you
don't gain anything from 64bit other than address space.  mips is actually
an unusual case in that the original 32bit mips had some design problems
(no 32bit direct load and store for example) which hurt performance in
some cases.  When they did 64bit they added such instructions, so 64bit
mips processors can be faster than 32bit.  However the 64bit overhead
still hurts so they ended up defining a new 32bit ABI that uses the
new instructions added on 64bit mips processors, but use 32bit address
space still.  So all the benefits of the new instructions without the
overhead of the 64bit addresses.  Linux supports all 3 on 64bit mips
systems.  The old ABI is o32, the new ones are n64 and n32 (which is n64
minus the 64bit code bloat).

Alpha and itanium are the only ones I can think of that have only ever
had 64bit.  ARM is of course only 32bit (although they are going to
add PAE to allow 40bit physical memory, but still with 32bit limits
on applications).  I can't believe they think that is a good idea,
but I guess it is a quick fix.

> It appears that in the case of WINE, one or another of those
> interactions that I noted above aren't quite so transparent :-(.

You may simply not have touched the wine 1.2 win64 capabilities at all.

-- 
Len Sorensen
--
The Toronto Linux Users Group.      Meetings: http://gtalug.org/
TLUG requests: Linux topics, No HTML, wrap text below 80 columns
How to UNSUBSCRIBE: http://gtalug.org/wiki/Mailing_lists