Wine call graph; wineserver; the "big picture".

[Ove Kaaven]

On 14 Aug 2001 phi at icon.co.za wrote:

> I've been lurking for a while now with a view to starting work on wine -
> specifically COM and DCOM. I know some people have started some work and
> there might be some patent issues with COM at least - so maybe DCOM is a
> better bet (I had the possibly niave idea of implementing COM via DCOM -
> it would be almost transparent, slower but less "dangerous").

It would not have to be slower. In real Windows, local interprocess COM
and networked COM (DCOM) both does use the same marshalling layer on top
of MS's RPC layer (rpcrt4.dll and rpcss.exe). The only difference here is
that rpcrt4 uses loadable modules for the various transports it can
support. One such module supports the TCP/IP-based RPC that everyone knows
DCOM can use - and there's probably another module that only supports
local (same-host) messaging, but is optimized for that, by using shared
memory where possible. (That is probably what the CLSCTX_LOCAL_SERVER
transport use.)

It would actually be really nice if someone would implement rpcrt4's
marshalling support, i.e. its Ndr* entry points (heavily used by the
marshalling proxies and stubs that MS's IDL compiler, midl.exe, creates).

Even if someone only implemented standard DCE RPC and whatever marshalling
standard DCE RPC supports, it'd still go a long way towards interprocess
COM and DCOM support, and help my efforts when I get to the "cleanup"
stage (as right now I'm ignoring rpcrt4 and doing really bad hacks to get
InstallShield up, and I doubt Alexandre would accept that if not done
properly using rpcrt4)