proper nt-style authentication (reactos, wine, samba tng)
rob at codeweavers.com
Fri Sep 2 00:05:24 CDT 2005
Luke Kenneth Casson Leighton wrote:
>that you - the wine team - continue to reinvent an non-interoperable
>version of MSRPC, for binary-level "DCOM" interoperabiltiy ONLY,
>demonstrates quite how just as bloody stupid you are being. that _can_
>be taken as a compliment, as i genuinely i mean it with the greatest of
Ok, I want to condense your huge message into a numbered list of things
you say we need:
1. Type marshaling.
2. IDL compiler.
3. RPC Server.
5. Services (lsa, netlogon, samr, etc).
Ok, so we are we at with Wine and ReactOS?
1: We need to implement this anyway because, like you crudely put it, we
are in the crazy business of getting real code like InstallShield and
Office 2003 to work.
2. We can either use MIDL and accept the problems that go with it (like
not generating code that will compile with gcc 4.0) or we can finish
implementing proxy support in widl.
3. We have support for named pipes in the RPC server, but Wine doesn't
support remote named pipes and AFAIK ReactOS doesn't either. This is not
a problem that should be solved by the RPC runtime.
4. Kai and Juan are working on delegating NTLM authentication to Samba.
We still need to tie this in to the RPC server though. That should be a
trivial task in comparison. Not sure how this will fit in on ReactOS.
5. Wine isn't really interested in having those types of servers, but it
would be nice for the client code for those to work. I'm not sure that
porting them from Samba would be fruitful as they would fundamentally
need to tie into the registry.
So, what you are suggesting is that we instead port FreeDCE and use it
for 1-3 (and 4?). This while still having to implement (1) anyway
because of the applications I mentioned that need it. Then we get to
test two different MSRPC infrastructures and get to fix bugs in one
without it fixing any bugs in the other. Just porting FreeDCE seems like
a lot of work; perhaps more work than implementing the remaining
features in our own MSRPC infrastructure, even when including the task
of finishing the IDL compiler. Maybe I am being blind, but it seems to
make sense just to carry on in the direction we are going with having
our own MSRPC implementation and being able to "dogfood" our
implementation (i.e. use it for our own proxies/stubs at the same time
as letting applications use it).
More information about the wine-devel