[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [dank@alumni.caltech.edu: ABI for Linux for i386 (was: Re: What's a Window???)]


I've just discussed this with Ralf Flaxa (chief of sample implementation LSB)
who is coincidently sitting in the office right beside mine :)

> robert w hall wrote on comp.emulators.ms-windows.wine:
> > aj writes:-
> > 
> > I think the problem is that they changed the value of USER_CS and
> > USER_DS (the selectors used when running in 32-bit mode). We use these
> > to switch from 16 to 32-bit code, and their value is hardcoded in the
> > relay code at compile-time.
> > 
> > So it will work as long as you also compile on a win4lin-patched
> > kernel. But if you compile when running a normal kernel and run on the
> > patched one, or the other way around, it will break.
> > 
> > --
> > Alexandre Julliard
> Eeek.  Does the LSB say anything about binary interoperability
> (I think it does) and if so, can it mandate values like those
> selectors?  If not, we may have serious problems down the road
> in installing Wine executables as binary packages.

First, there will not be serious problems, since we can work 
around that problem in WINE.

In fact, the problem was already addressed in a patch two days ago:

|Modified files:
|        if1632         : builtin.c relay.c
|        include        : builtin16.h
|        tools/winebuild: build.h main.c relay.c spec16.c
|Log message:
|        Patch flat cs of 16-bit entry points if current %cs is different from
|        compiled value, and retrieve flat ds from a global variable. This
|        should avoid problems with win4lin kernels.

So there should be no more action required on part of the WINE team ;)

On the other hand:

I am not sure how much programs rely on the x86 segment register values
at startup, and if there is a ABI specification clearly stating values for
This (research the relevant standards etc.) is again more of an issue for
the LSB team.

Ciao, Marcus

Reply to: