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 respect.
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. 4. Authentication. 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).