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+