winmm 16/32 code split

Eric Pouech eric.pouech at
Sun Oct 13 11:30:37 CDT 2002

> > 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.
compilation unit is fine when you have two DLLs side by side (one 32
the other one is 16); and 16 bit API is a subset (or equiv) to the 32
what you would need in some cases, for callback, is to create 32 bit
for 16 bit procedure. however, if the address of the 16 callback is not
back in the callback (DDEML for example), then you should create some 32
code to do the glue. I may extend winebuild to create such callbacks
the old CreateProcInstance, but where instead of setting ds, you'd add
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
in that case, I think your pointer would work just fine. it would take a
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


More information about the wine-devel mailing list