27 Mar
2003
27 Mar
'03
7:08 p.m.
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.
(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)
I am currently running native ole32 and native rpcrt4.
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.
Anyone an expert in any of this stuff?
--
Bill Medland
ACCPAC International, Inc.
medbi01(a)accpac.com
Corporate: www.accpac.com
Hosted Services: www.accpaconline.com
27 Mar
27 Mar
8:48 p.m.
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.
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!
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" 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.
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.
--
gmt
"An honorable Peace is and always was my first wish! I can take
no delight in the effusion of human Blood; but, if this War should
continue, I wish to have the most active part in it." --John Paul
Jones
31 Mar
31 Mar
1:36 a.m.
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.
5:40 p.m.
On March 30, 2003 05:36 pm, Ove Kaaven wrote:
It isn't, but I am using the native rpc drivers too (rpclt[c,s][cm,3])
tor, 2003-03-27 kl. 20:08 skrev Bill Medland:
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)
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.
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
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.
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(a)accpac.com
Corporate: www.accpac.com
Hosted Services: www.accpaconline.com
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.
2 Apr
2 Apr
5:02 p.m.
On Monday 31 March 2003 11:40 am, Bill Medland wrote:
> > 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.
Probably just crappy docs. IIRC DCE RPC does define an equivalent API, so it
ought to have some non-netware applications as well. Probably, stubs for
more of the RPC security and name services API's would be helpful here, if
only to expose a new landscape of unimplemented functionality ;)
So to recreate this, what does one do exactly? DCOMTST does it with native
rpcrt4? Or some other setup?
--
gmt
"An honorable Peace is and always was my first wish! I can take
no delight in the effusion of human Blood; but, if this War should
continue, I wish to have the most active part in it." --John Paul
Jones
7:20 p.m.
On April 2, 2003 09:02 am, Gregory M. Turner wrote:
On Monday 31 March 2003 11:40 am, Bill Medland wrote:
(Ref. MSDN Q259011)
The DCOMTEST program pair is based on the simple DCOM sample provided with the
platform SDK.
In what way it is different I don't know but it is basically the same.
As far as we are concerned the first stumbling block is a call to
CoCreateInstanceEx with a non-null server.
To get anywhere you will need to use the native ole32.
--
Bill Medland
ACCPAC International, Inc.
medbi01(a)accpac.com
Corporate: www.accpac.com
Hosted Services: www.accpaconline.com
> > 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.
Probably just crappy docs. IIRC DCE RPC does define an equivalent API, so
it ought to have some non-netware applications as well. Probably, stubs
for more of the RPC security and name services API's would be helpful here,
if only to expose a new landscape of unimplemented functionality ;)
So to recreate this, what does one do exactly? DCOMTST does it with native
rpcrt4? Or some other setup?
7719
days inactive
7725
days old
5 comments
3 participants
participants (3)
-
Bill Medland -
Gregory M. Turner -
Ove Kaaven