2 Sep
2005
2 Sep
'05
9:58 a.m.
hi, rob, thanks for responding.
On Fri, Sep 02, 2005 at 12:05:24AM -0500, Robert Shearman wrote:
wheeeeee :)
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.
more specifically, rpc server "infrastructure" from which to develop,
create, compile run and support RPC servic_es_.
this you gain in the quickest possible way from FreeDCE and in the
grungiest possible way from either samba or samba tng.
4. Authentication.
5. Services (lsa, netlogon, samr, etc).
yep.
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.
muhahahahah. hey, Security-Enhanced ReactOS, anyone? :)
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.
okay.
the amount of effort required to modify dceidl to support
binary-interoperability with MIDL i do not believe to be very large,
but the key bit which _will_ take some expertise (i.e. there are better
people than myself to do the job) is the adding of Win32 threading
model support to FreeDCE.
going down THIS path will GET you code that will compile with gcc 4.0
(and mingw32) AND it would be binary interoperable with MIDL.
AND it would actually work, without having to reimplement type
marshalling, which if you look at FreeDCE's marshalling/unmarshalling
code is SEVENTY THOUSAND LINES of immensely complex code.
3. We have support for named pipes in the RPC server,
what is the "RPC server"? i do not know of such a beast :)
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.
no. it has nothing to do with the RPC runtime.
you write a plugin that implements thirty or so functions (which have
names like open, write, close etc. funnily enough :) and then register
it with the RPC subsystem (yeh, okay, probably the rpc runtime :)
e.g. the named pipe transport is called ncacn_np - network computing
architecture CoNnection-based named pipes.
and then MSRPC clients and MSRPC services can simply utilise that
transport automatically or by name.
4. Kai and Juan are working on delegating NTLM
authentication to Samba.
ah. brilliant. that's exactly what i outlined as "stage 1" and it
should be done by implementing MSV1_0.DLL, for use by LSASS, see
LsaLogonUser in the ntoskrnl code, it's a stub at the moment, in the
reactos code.
We still need to tie this in to the RPC server though.
i do not know what you mean by the "RPC server". no such entity
actually exists afaik.
That should be a trivial task in comparison.
yes, which is why it is mentioned about 2/3 of the way through my
document, as "stage 1".
Not sure how this will fit in on ReactOS.
in NTOSKRNL the LSASS implementation, which then has MSV1_0.DLL
register with it. i mentioned it in my document.
see the two occurrences of LsaLogonUser in reactos code.
5. Wine isn't really interested in having those
types of servers,
tough luck for them.
nt domain services are a necessary and integral part of supporting win32,
even in a stand-alone environment.
wine has _bypassed_ the MSRPC bits by instead of utilising MSRPC to
split client from server they have "linked" the client-side code with
its server-side code, cutting out the MSRPC runtime altogether.
due to the incredible way that MSRPC (actually DCE/RPC) is designed, it
is perfectly feasible to do this sort of thing, and actually have your
code work (just with no networking and no distributed capability)
anyway.
if the wine team cannot be convinced of the necessity of adding
MSRPC into the mix then wine will pretty much remain in the
dark ages of interoperability along the lines of "win95 with networking
removed".
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.
yes? :) and? :)
i have no problem with that. i'd _love_ to see a registry service
implemented in samba tng and then utilised in a samrd to access an
NT SAM hive :)
it's the way that reactos has gotta go, basically.
So, what you are suggesting is that we instead port
FreeDCE and use it
for 1-3 (and 4?).
basically and ultimately - yep!
BUT, butbutbut - remember, i did say that it is _not_ strictly
necessary at the moment.
there are ways - and it appears that you are already considering them -
to cut down the amount of work required to "GetThingsWorking(tm)", as i
described.
This while still having to implement (1) anyway
because of the applications I mentioned that need it.
no, you don't have to.
you hack FreeDCE into interoperability because it IS the
rpc runtime.
remember, microsoft adopts code wholesale if they can get away with it.
they started from DCE 1.1 reference implementation and ported it to NT.
FreeDCE _is_ the DCE 1.1 reference implementation - autoconf'd and
modularised.
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;
okay, the reason why it seems that way is because i actually know
what's involved and have described to you what's involved.
if you described to me what you are endeavouring to do in
reimplementing the rpc runtime, i can give you some time estimates on
how long it will actually take, and i guarantee you it will make the
amount of time i've outlined for porting FreeDCE look like a walk in
the park by comparison.
that's all.
remember, i did EXACTLY the same thing. i looked at the OpenGroup's
DCE/RPC documentation, and went "christ almighty i can't possibly be
doing with all this" and ignored it.
THREE YEARS LATER i was wishing in some ways that i hadn't.
the learning curve however of doing on-wire interoperability gave me
enough understanding to appreciate just how good dce/rpc really is, and
quite how much work is involved.
you would do well to LISTEN to that advice of someone who wasted three
years of their life NOT listening to advice, who followed the same path
as you are following (the not-invented-here path).
it will save you a lot of time.
you would do well to bite the bullet and utilise your wealth of
experience and knowledge learned to-date as a means to "tie in" to the
freedce code.
you _have_ enough knowledge and expertise now to be able to do that.
you alone rob have been dealing with rpc type libraries for, what, two
years now?
a function-by-function comparison of freedce and wine's rpc runtime
will show EXACTLY the same functions, EXACTLY the same arguments, and i
started to show you that some six months ago, remember?
now there is the reactos project to take into account, too.
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).
there is an opportunity to save _everybody_ time, right across the
project board.
i have said this in 2000 on the samba mailing lists.
i have said it on that mailing list discussion six months ago on
the wine-devel lists.
i am saying it now.
freedce is the key to interoperability for samba, wine, reactos,
because it is the same code that microsoft hacked into submission
to make the services which samba, wine and reactos are independently
implementing, without proper reference to each other.
samba is implementing "on-the-wire" interoperability without the
type-libary interoperability and without the IDL-level and
runtime-level interoperability.
wine and reactos are implementing "binary-level" interoperability and
are avoiding IDL-level and on-wire-level interoperability (by
suggesting to developers that they utilise MIDL.EXE)
this is complete madness.
wine will end up with 100,000 lines of hacked-together and
incomplete code. samba has two hacked-together projects
of about 100,000 lines of code each. samba tng has its
own hacked-together and equally but differently incomplete
implementation.
whereas FreeDCE is 250,000 lines of code that provides IDL-level
interoperability, on-wire level interoperability, and the things that
it is missing - win32 threading support, modern (posix) threading
support and exact byte-for-byte type library interoperability are
TRIVIAL trivial TRIVIAL computer-science first and second year
university projects by comparison.
each time i mention this, the people implementing their own
non-interoperable projects in their own little worlds get
deeper and deeper into the shit.
if i can't convince people that this is the way forward then
i will simply have to give up and come back in five years
and see how people are getting on.
l.
--
--
<a href="http://lkcl.net">http://lkcl.net</a>
--