Any DCOM experts?

[Bill Medland]

On March 27, 2003 12:48 pm, Gregory M. Turner wrote:
> On Thursday 27 March 2003 01:08 pm, Bill Medland wrote:
> > Hi guys
> >
> > For the next part of the work I am doing I am trying to figure out if
> > there is any way that the DCOM part of one of our products is going to
> > work under Wine at the server end.
> >
> > I am not having much success so far and I was wondering if anyone knows
> > whether this is because I don't have things set up properly or if it is
> > because of some inherent known lack of functionality.
> >
> > To start the ball rolling I was working with MSDN's DCOMTST test program
> > pair.
> >
> > I managed to get that working using the local server (after adding the
> > definition of IStream to the registry) but am having no luck getting the
> > client under Wine to talk to the server under Win98.  In fact the client
> > side doesn't even seem to send out a single TCP/IP packet.
>
> There is no implementation of the TCP/IP transport at this time.  Wine will
> fail to make interprocess calls without any indication of this failure in
> some cases.  Frankly, I'm pleasantly surprised to hear that even DCOMTST
> works.

Ah, yes.  But the local DCOMTST case is only going to use named pipes or
something.  And I am actually using the native dlls.
And I know that I can use the native rpc across the net (using the "simple"
sample program)

> The RPC implementation in wine is not up to par yet.  DCOM needs RPC to do
> it's dirty work, so interprocess RPC is very shaky, and interprocess
> between wine and real windows is non-existant.
>
> The good news is that there are people working on this, in particular, Ove
> Kaaven and myself, although we are not exactly making headlines with our
> earth-shaking progress at this moment.  The bad news is that getting wine
> to talk to windows via RPC is a pretty distant target right now; there are
> lots of "lower hanging fruit" that will presumably be addressed first.
>
> > (Aside - Nice demonstration of lazy Microsoft code; in their error
> > reporting they call FormatMessage, ignore the return code and somehow
> > print the returned error message, even when one hasn't been allocated; I
> > guess it only works under Windows because the print routine traps the
> > access violation)
>
> or maybe the thing was supposed to be allocated and wine didn't do it
> properly.  Always presume wine is at fault, not Microsoft; you will usually
> be correct, especially in DCOM territory!

No.  If a function has a return code that indicates failure then you should
test for that failure and not blithely continue as if everything was OK.

They call FormatMessage, asking for FormatMessage to allocate the returned
string.  If nothing else, it could fail to allocate memory in which case it
would be stupid to use the "returned pointer" which is just whatever happened
to be on the stack at the time.  And I noted it failing on Windows too; the
printf or whatever simply stopped processing half-way along the format
string.

> > I am currently running native ole32 and native rpcrt4.
>
> Then you are really using Microsoft's DCOM implementation, and not wine's.
> Which may not be a bad choice if you want it to "just work"

Yes please

> as much as
> possible.  I have successfully used native ole32 and rpcrt4 to talk to SQL
> server via the MMC interface, quite a bit of RPC involved.  It didn't work
> too well, but it was interesting to see it work at all.

Hm.  So something at least is possible (i.e. it is possible to get ole32 to
put tcpip packets across the wire)

> > The builtin rpcrt4 fails on a call to unimplemented
> > RpcServerInqDefaultPrincName but I don't understand why it is even
> > calling that; why does it think I have Netware only and why does it think
> > this is a server process.
>
> This is another unimplemented chunk of DCOM: the RPC name services do not
> exist.  Samba and dce rpc have this feature so it's not unattainable... but
> it ain't there yet.  The name services and other networked DCOM services
> require priveleged ports that wine can't even use without some kind of
> medium-scale reconceptualization of the basic wine security model anyhow...
> it's easy to imagine reasonable solutions to that too, but it will take
> some thought...
>
> > Anyone an expert in any of this stuff?
>
> Yes, but unfortuantely, they all seem to work for Microsoft ;)  Seriously,
> some of it is undocumented, some of it is well documented.  There are
> probably only a handful of people in the world who could answer some of the
> hard questions without reverse-engineering the answers, and they probably
> do work for Microsoft.  So for wine, we must read the specs and reverse
> engineer the rest.  It's not a pretty landscape and you will need to be
> patient, but I believe there is a light at the end of the tunnel.

Good to know.  Unfortunately it isn't my patience we are talking about.

Do you know of any decent low level documentation that I could read that
 would explain why the native OLE doesn't even appear to be trying to hit the
 network?

BTW, on the subject of specs, create_marshalled_proxy includes a reference to
a figure at MSDN.  Unfortunately the link is out of date.  Any idea what it
is a reference to?  I had a quick look through the 1999 MSJ articles but
didn't see anything obvious.

Also, if I get bored and can find a few hours I was going to correct the
arrangement of CoCreateInstance and CoCreateInstanceEx and tighten up the
CoGetClassObject order of testing; does that conflict with anyone?

--
Bill Medland
ACCPAC International, Inc.
medbi01 at accpac.com
Corporate: www.accpac.com
Hosted Services: www.accpaconline.com