winmm 16/32 code split

[Eric Pouech]

Alexandre Julliard a écrit :
> 
> Eric Pouech <eric.pouech at 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+