Alexandre Julliard a écrit :
Eric Pouech eric.pouech@wanadoo.fr writes:
well it depends what you want to achieve: whether you want 32 bit code to know if 16 bit procs exist or not I was willing to have the 16 bit code only calling thru the official 32 bit API, so any knowledge of 16 bit entities can be removed from 32 bit code (which of course requires a bit more work)
Well, in general it's better to avoid having the 32-bit code know about the 16-bit one, but there are cases where that cannot be avoided so we can't be 100% "pure" anyway. And if sticking a 16-bit pointer in a 32-bit structure avoids creating all sorts of ugly thunking stuff then it's worth it.
agreed. but if you really want to split, the glue code must be generated from the 16 bit code only, thus the 32 bit code cannot link directly to the glue code (the kind of pointer you suggested in some previous mail).
anyway, the complete mmio implementation (for 16 bit API) would require thunks (we need to export segmented pointers to native 32 bit functions, as well as calling 16 bit segmented pointers without any object at hand). but as a first step (since I don't know any 16 bit app using this), storing both 16 & 32 function pointers in 32 bit code would behave sufficiently correctly (read as it does today)
I think I'll have to rewrite the mmio patch (for a third time)
A+