winmm 16/32 code split

Eric Pouech eric.pouech at
Mon Oct 14 15:09:51 CDT 2002

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

More information about the wine-devel mailing list