winmm 16/32 code split

[Eric Pouech]

> > this will still cause problems (for example while compiling for mingw)
> > Alexandre, do you have some global plans for splitting further... not
> > linking on compilation unit will not be sufficient, we need a finer
> > grain control
> 
> I think linking on compilation units should work just fine. You may
> need in some cases to add a callback for the 32-bit code; for instance
> in that case you could have some kind of pLoadWin16Driver function
> pointer in the 32-bit code that is initialized to NULL, and when the
> 16-bit part is loaded it makes it point to one of its routines. Of
> course this kind of things should be avoided as much as possible, but
> there are a few cases where it will be necessary.
ok
compilation unit is fine when you have two DLLs side by side (one 32
bit,
the other one is 16); and 16 bit API is a subset (or equiv) to the 32
bit
API
what you would need in some cases, for callback, is to create 32 bit
callbacks
for 16 bit procedure. however, if the address of the 16 callback is not
passed
back in the callback (DDEML for example), then you should create some 32
bit
code to do the glue. I may extend winebuild to create such callbacks
(like
the old CreateProcInstance, but where instead of setting ds, you'd add
another
parameter to the callback)

some other cases are not covered. it's the case in any OWA
implementation of a
DLL, where drivers can be either 16 and 32 bit (that's the case for
winmm)
in that case, I think your pointer would work just fine. it would take a
bit
more than just the load driver, but also sendmessage, unload... but
that's doable
(I'll try that for winmm too)

btw: don't apply my mmio patch yet (I'm working on a better
implementation)

A+