Re: [dank@alumni.caltech.edu: ABI for Linux for i386 (was: Re: What's a Window???)]
Hi,
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
them.
This (research the relevant standards etc.) is again more of an issue for
the LSB team.
Ciao, Marcus
Reply to: