[prev in list] [next in list] [prev in thread] [next in thread] 

List:       wine-devel
Subject:    Re: Move various DLLs to dlls/
From:       Ulrich Weigand <weigand () informatik ! uni-erlangen ! de>
Date:       1999-07-29 15:57:42
[Download RAW message or body]


Huw D M Davies <h.davies1@physics.ox.ac.uk> wrote:

> Well let's look at some of these:
> 
> > TOOLHELP, WOW32
> These are probably best left in the core. To move them outside will just be a
> hack.

I'd agree in the case of TOOLHELP.  The native version uses the THHOOK
exported data entry point to directly access the Burgermaster segment etc.
To get this running, we'd have to convert the 16-bit global memory data
structures to comply to the real Burgermaster layout, which I'm not sure
is a good idea.

For WOW32, this contains (on Win95) just forwards to the corresponding
entry points in KERNEL32.  We could easily do the same, but I'm not 
sure whether it's worth the effort.  [ On WinNT, everything is completely
different.  Here, KERNEL32 does not contain the WOW exports at all, not
even as undocumented exports.  Instead, the whole 16-bit subsystem is
completely separate, and WOW32 implements (a part of) it ... ]

> > DDEML
> This is just stubs to USER32, so is trivial to pull out if we care.

Hmm.  The problem is that the (Win95) native USER does it the other
way around:  The Ddeml* entry points of USER32 are just stubs thunking
down to USER, where they are forwarded to the DDEML entry points. The
real meat of the implementation is in DDEML.

So, what to we want to achieve?  Use of native DDEML with built-in USER
or vice versa?  In this case, we'll have to do it the Win95 way and
thunk *down* to 16-bit.  This doesn't sit well with our infrastructure,
however, so it'd require manual CallTo16 stubs, SEGPTR_ALLOC and the like ...

If we don't want to make that effort, we're forced to use all-native
or all-built-in versions of the *three* DLLs DDEML/USER/USER32, so we
might as well implement them in a single elf-dll.

[ Or, yet another variant:  we could create a Wine-only DDEML32.DLL,
  implement a shared DDEML/DDEML32 elf-dll, and have the USER32
  entry points forward to DDEML32 ... ]


> > MPR
> Hmm, some of this stuff are stubs to USER.  So we probably need to move all of
> this to 32 bit, separate and then stub USER to call MPR

Right. Indeed, here the native USER does thunk up to USER32, which forwards
the calls to MPR.  This direction can be easily simulated in Wine, so we
should just separate the 32-bit routines out to a MPR elf-dll, and have
the 16-bit stubs in USER/USER32 call MPR.  So this is not problematic
after all :-/


Bye,
Ulrich


=========================================================================

[prev in list] [next in list] [prev in thread] [next in thread]