Alexandre Julliard wrote:
>
> Eric Pouech <[EMAIL PROTECTED]> writes:
>
> > just one question before finishing the creation of winmm/mmsystem as a separate
>.so file:
> > when a 16 bit API is needed (let's call it foo in dll mydll), what's the best way
> > (preferred practice) to get the function
> > 0/ try to replace the 16 bit call with an 32 bit equivalent
> > 1/ I've seen a few places where the foo16 function is added to the exported EP of
>the
> > 32 bit module counterpart (mydll32). but this may grow quite heavily (see François
> > Gouget latest mails)
> > 2/ make the import "by hand" in the caller module (LoadLibrary16/GetProcAddress16
>and
> > use the Wine's standard glue to do the call)
>
> 0/ is clearly the best choice wherever possible. In the few cases
> where the 16-bit version has different semantics and we really need
> the 16-bit semantics, the best solution is 1/; but we should only add
> exports to the core dlls (kernel32/gdi32/user32) where we already have
> some Wine-specific exports anyway, and for which we won't support
> native dlls. If you absolutely need to call a 16-bit function in a
> higher-level dll, 2/ is the only solution; but it should be avoided as
> much as possible, as it's quite expensive to call through 16-bit code.
ok...
for example, shouldn't we use WOWGlobal???16 functions (and import wow32.dll)
instead of using the Wine only Global???16 functions (and get rid of the
EP in kernel32 ?)
A+
--
---------------
Eric Pouech (http://perso.wanadoo.fr/eric.pouech/)
"The future will be better tomorrow", Vice President Dan Quayle
