winmm 16/32 code split

[Eric Pouech]

Alexandre Julliard a écrit :
> 
> Eric Pouech <eric.pouech at wanadoo.fr> writes:
> 
> > well, address is only known as runtime, but call framework is
> > always the same. if the number of thunks is fixed (which is
> > anyway the assumption made in existing code), then the code
> > can be generated automatically (of course will eat up lots
> > of pages)
> 
> I still don't follow you. Why do you say that the number of thunks is
> fixed?  
I was referring to allocating them in a fixed size heap
> If you mean the number of different types of callback
> functions, then yes, that's what the glue code does. But this is
> already implemented so I don't see why you'd need something else. All
> the dynamic thunk has to do is to retrieve the 16-bit callback address
> and call the corresponding glue function. And in the vast majority of
> cases you can retrieve the callback address without creating any thunk
> at all; even if the callback doesn't have an lparam you can use,
> there's usually a handle to an object where you can store the info.
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)
A+