DCOM roadmap

[Mike Hearn]

I thought I'd post an update on where Rob and I are up to, and where
we're going. This is the plan that I have in my head, Rob may want to do
things in a slightly different order etc so don't be surprised if we
change some stuff around as a result of this email.

We're currently reworking, extending and in some cases rewriting the
code Marcus wrote originally to work more like native DCOM does. This
means that new features and major improvements are *not* going to happen
for a while, because before we can extend our support for DCOM we have
to migrate to the same architecture that Microsoft use internally. This
has several benefits:

1) It saves us design work, because MS already did it
2) It's the only way to be wire compatible in the long run
3) It means the documentation (like Essential COM etc) is already
   written

Getting to a more native-style architecture has already been started,
but won't be finished for a while. Here are the steps we need to take,
the ones marked with a * are already done, - means they are still to do.

- Replace the wine_marshal_id structure with [STD]OBJREF. This is
  necessary because the Microsoft internal interfaces like IOXIDResolver
  and IRemoteActivation operate in terms of OBJREFs. An OBJREF is a
  marshalled interface pointer, so by using the same structure we're
  able to be wire-compatible with MS.

      * Switch apartments to be identified by OXIDs
      * Refactor and extend the stub manager, identified by OIDs
      * Refactor and extend the proxy manager
           - Make all system interface proxies support aggregation
      - Identify interface stubs by IPID not IID
      - Do a search and replace of wine_marshal_id with STDOBJREF

- Alexandre has stated that he won't allow any more midl generated
  code in WineHQ. Enhance widl until it can generate raw RPC marshallers
  for at least IRemUnknown.

- Generate unique names for the pipes we currently use in communication
  and pull the right name from the OBJREF DUALSTRINGARRAY. In real
  DCOM this contains the RPC string binding for the OXID Resolver
  endpoint. This should be the first enhanced feature, as at this 
  point you can run two apps at once that happen to marshal the same
  interface, and they won't interfere.

- Implement IRemUnknown, using custom marshalling for now. Use this
  to nail distributed refcounting, at the moment we have a bunch of
  bad hacks for that.

- Flip DCOM on top of the RPC transport layer, replacing the current
  named pipe based IRpcChannelBuffer implementation. Not necessarily
  using NDR marshalling at this point, though we may find it's
  necessary (?)

- Rework RPC dispatch to be more Windows-like, so call re-entrancy
  works.

- Implement RPC thread affinity. This will fix the InstallShield
  painting problems ... yes it's a long way off :(

- Begin rewriting/moving the typelib marshaller to rpcrt4 and to use NDR
  (in Windows this is done by generating MOPs at runtime from the type
  data)

.... this point is so far off I don't really care about it ....

I probably forgot some items as well. But as you can see we only just
begun. Also remember that Rob may want to modify it and also we may
change direction at any point to make stuff we want internally work
(like native MSIv2 ...)

thanks -mike