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? 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.
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 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...) 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.