Any DCOM experts?

[Bill Medland]

On March 30, 2003 05:36 pm, Ove Kaaven wrote:
> tor, 2003-03-27 kl. 20:08 skrev Bill Medland:
> > To start the ball rolling I was working with MSDN's DCOMTST test program
> > pair.
>
> I haven't looked at it myself, how does it try to locate the server?

It doesn't; you specify it on the command line and (if it is anything like the 
sample program that it says it is based upon) then it passes that server name 
to the CoCreateInstanceEx function (which wine currently doesn't handle)

> If
> it needs to use the name service (rpcss.exe), directly or indirectly, to
> find it, it's very unlikely to work with wine right now.

It does use rpcss.

>
> > 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.
>
> It probably can't send any packets without knowing where to send them,
> and if everything else is working, it probably needs rpcss to find out
> (the local rpcss is usually requested to act on behalf of the client
> instead of having the client contact the remote host directly, since
> this lets rpcss cache such information).
>
> Then again, it may be that not everything else is working.
>
> > I am currently running native ole32 and native rpcrt4.
>
> I don't think native rpcrt4 and ole32 is necessarily enough; for
> example, the TCP/IP stuff may not be implemented directly in rpcrt4,

It isn't, but I am using the native rpc drivers too (rpclt[c,s][cm,3]) 

> it
> might depend on other dlls to provide protocol backends and
> authentication services, and registry entries to identify them (though
> I'm not sure). Also, COM is married to the registry and you'll probably
> need a metric ton (as if there's any other kind of ton, heh...

When did that change?  I was always taught that a ton was imperial and a tonne 
was metric (and a tun was a reasonable amount of beer for a small party)

>) of
> entries to get DCOM to run with native ole32.
>
> > 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.
>
> What does that have to do with netware? As far as I know, the security
> principal is the backbone of the NT domain's and DCOM's security model.

MSDN states "In an environment that only uses NetWare, the server application 
calls the RpcServerInqDefaultPrincName function to obtain the name of the 
NetWare server, when authenticated RPC is required. The value obtained from 
this function is then passed to RpcServerRegisterAuthInfo."  Probably my 
usual jumping to conclusions from MSDN documentation.

Thanks for the answer but basically I am following a different solution that 
doesn't depend upon DCOM.

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