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