Before I go off and duplicate a bunch of work somebody already did, I wanted to verify that wine has no existing implementation of NDR data marshalling? I don't know of such a thing, but I don't necessarily have the big picture. rpcrt4 needs this for somewhat obvious reasons, and the format is well documented by OpenGroup if we need to start an implementation from scratch.
On Thu, 17 Oct 2002, Greg Turner wrote:
Before I go off and duplicate a bunch of work somebody already did, I wanted to verify that wine has no existing implementation of NDR data marshalling? I don't know of such a thing, but I don't necessarily have the big picture. rpcrt4 needs this for somewhat obvious reasons, and the format is well documented by OpenGroup if we need to start an implementation from scratch.
The format may be standard, but the API that rpcrt4 use is pretty undocumented (apart from the self-documenting function names and pretty complete header files). I was planning to work on this stuff again soon, but haven't yet written any more code than what you've merged (and I would probably begin spending time mapping more RPC format chars by writing some IDL, feeding it through MIDL, studying the output, and update include/wine/rpcfc.h, or I would spend time typing in stuff like a Wine version of wtypes.idl, so might take even longer before I got to write any marshalling code), and I don't know about anyone else working on it (Juergen Schmied is probably busy with other stuff). So if you want to start on it, go ahead, I'll give you all the help I can (as long as time permits, and the license of your work remains ReWind-compatible), my employer wants to see a functional RPC/DCOM infrastructure in Wine...
On Thursday 17 October 2002 03:19 pm, Ove Kaaven wrote:
On Thu, 17 Oct 2002, Greg Turner wrote:
Before I go off and duplicate a bunch of work somebody already did, I wanted to verify that wine has no existing implementation of NDR data marshalling? I don't know of such a thing, but I don't necessarily have the big picture. rpcrt4 needs this for somewhat obvious reasons, and the format is well documented by OpenGroup if we need to start an implementation from scratch.
The format may be standard, but the API that rpcrt4 use is pretty undocumented (apart from the self-documenting function names and pretty complete header files). I was planning to work on this stuff again soon,
my goodness, tell me about it! at least some of them have entertaining names like I_RpcTransServerMaxFrag ;)
but haven't yet written any more code than what you've merged (and I would probably begin spending time mapping more RPC format chars by writing some IDL, feeding it through MIDL, studying the output, and update include/wine/rpcfc.h, or I would spend time typing in stuff like a Wine version of wtypes.idl, so might take even longer before I got to write any marshalling code),
the format chars have a bit of documentation in MSDN Library. It's a little confusing and terse but much better than nothing, and, so far, consistent with what I see coming from MIDL. Kinda surprising that they bothered to document the format since they don't document what to do with it :)
BTW, I assume that MIDL-generated code can't go into wine? I plan to avoid the issue by generating proxy/stub code in wetware, with corresponding IDL so we can eventually replace wetware-generated proxy/stub code with widl-generated equivalents...
Anyhoo... I don't like to bang out code without being able to run it and see that it works. So I'm leaning towards an incremental approach. That's why I've been playing with "hello world" and the unit-testing framework. OTOH, I don't want to pile crap on the foundation you've built, so I will tread with caution.
and I don't know about anyone else working on it (Juergen Schmied is probably busy with other stuff). So if you want to start on it, go ahead, I'll give you all the help I can (as long as time permits, and the license of your work remains ReWind-compatible), my employer wants to see a functional RPC/DCOM infrastructure in Wine...
It would be unfortunate for both of us to work on the same parts of this at the same time and create a merge situation, so let me know if you start diving into it and we'll work out some way not to step on each other's toes. I appreciate your offer to help out, I won't hesitate to take you up on it! If ignorance is bliss, I should be a happy guy...
As for licensing, I will release everything as X11 for now. X11 seems to allow all the major wine forks to absorb my code, which would be my preference.
and I don't know about anyone else working on it (Juergen Schmied is probably busy with other stuff).
Yes, I'm not able to do much of work for some month. (Bussy changing nappies...). I was only merging the RPC stuff because I was interested in getting ove's COM stuff into wine. I might start to work there (COM) again sometimes later [or more early if I could pay my bills from it ... - thats life ;-) ]
I still have some not-yet-ready-for-submitting LPC stuff in my queue. (If sbd interested...)
PS: I found te freedce project at sourceforge. Maybe rpc could borrow (ndr-)code there?
juergen --- juergen.schmied@debitel.net
On Tue, 22 Oct 2002, Jürgen Schmied wrote:
and I don't know about anyone else working on it (Juergen Schmied is probably busy with other stuff).
Yes, I'm not able to do much of work for some month. (Bussy changing nappies...). I was only merging the RPC stuff because I was interested in getting ove's COM stuff into wine. I might start to work there (COM) again sometimes later [or more early if I could pay my bills from it ... - thats life ;-) ]
I still have some not-yet-ready-for-submitting LPC stuff in my queue. (If sbd interested...)
PS: I found te freedce project at sourceforge. Maybe rpc could borrow (ndr-)code there?
I borrowed the UuidHash algorithm from freedce. I don't think we can borrow a lot since the way rpcrt4 does ndr internally is part of the exported API, but it can be used as a reference implementation (and maybe a source of .idl files?)
Am Die, 2002-10-22 um 13.46 schrieb Ove Kaaven:
I found te freedce project at sourceforge. Maybe rpc could borrow (ndr-)code there?
I borrowed the UuidHash algorithm from freedce. I don't think we can borrow a lot since the way rpcrt4 does ndr internally is part of the exported API, but it can be used as a reference implementation (and maybe a source of .idl files?)
What about Samba-TNG (www.dcerpc.org, www.samba-tng.org)and the sidlc compiler that is part of it? (Forgive me if that's a stupid suggestion)
Martin
On 22 Oct 2002, Martin Wilck wrote:
Am Die, 2002-10-22 um 13.46 schrieb Ove Kaaven:
I found te freedce project at sourceforge. Maybe rpc could borrow (ndr-)code there?
I borrowed the UuidHash algorithm from freedce. I don't think we can borrow a lot since the way rpcrt4 does ndr internally is part of the exported API, but it can be used as a reference implementation (and maybe a source of .idl files?)
What about Samba-TNG (www.dcerpc.org, www.samba-tng.org)and the sidlc compiler that is part of it?
Samba is GPL, is it not? Also, it has been my impression that Samba-TNG was moving towards using freedce anyway, though I haven't looked at any of their code (probably since the license would make it useless anyway).
Am Die, 2002-10-22 um 21.43 schrieb Ove Kaaven:
Samba is GPL, is it not? Also, it has been my impression that Samba-TNG was moving towards using freedce anyway, though I haven't looked at any of their code (probably since the license would make it useless anyway).
Studying their code can't hurt. And the IDL compiler would be usable, regardless whether it's GPL or not.
Martin
On Tuesday 22 October 2002 06:46 am, Ove Kaaven wrote:
I borrowed the UuidHash algorithm from freedce.
When are you planning to give it back? ;)
DISCLAIMER: Sorry. That is a terrible, and old, joke. But somehow I couldn't resist. I take no responsibility for any feelings of discomfort, disappointment, or hatred this comment may have engendered.
-
Greg Turner -
Jürgen Schmied -
Martin Wilck -
Ove Kaaven