[jcifs] Re: Tridge's PIDL compiler and the Samba4 IDLs.
Christopher R. Hertel
crh at ubiqx.mn.org
Thu Aug 12 22:29:30 GMT 2004
On Thu, Aug 12, 2004 at 05:18:19AM -0400, Michael B Allen wrote:
> On Thu, 12 Aug 2004 01:44:52 -0500
> "Christopher R. Hertel" <crh at ubiqx.mn.org> wrote:
> > So... Anyone interested in working on a Java back-end for PIDL?
> You're a little late. I'm pretty much finished with idlc. At least the
> stubs can marshall pretty much anything. I just need the call harness
> And it's 100% MIDL compatible.
That's a shame, as writing in MIDL will be a pain. The evidence is clear
that the MS programmers are all over the place with regard to their MIDL
coding. The do the same things a dozen different ways. PIDL compensates,
and makes it easy to keep track of what's going on. Converting the
current PIDL code will be difficult.
> Remember if Jarapac is going to
> seriously be of any use to anyone you need to be able to just take your
> IDL files and run them through idlc to get Jarapac stubs. Otherwise are
> you going to re-write the IDL to be "slightly unusual"? Nope.
Why can't the PIDL back-end produce the stubs you need?
> Unfortunately I'm loosing confidence in Samba's IDL as well. For example
> look at NetShareEnumAll:
> WERROR srvsvc_NetShareEnumAll (
> [in] unistr *server_unc,
> [in,out] uint32 level,
> [in,out,switch_is(level)] srvsvc_NetShareCtr ctr,
> [in] uint32 max_buffer,
> [out] uint32 totalentries,
> [in,out] uint32 *resume_handle
> The correct IDL (verified with MIDL and an ncacn_np transport against
> srvsvc on Windows 2003) is:
> int NetShareEnumAll(
> [in,string,unique] char_t *servername,
> [in,out] int *level,
> [in,out,switch_is(*level)] NetShareCtr *info,
> [in] unsigned long prefmaxlen,
> [out] unsigned long *totalentries,
> [in,out] unsigned long *resume_handle
> [Although I use char_t vs wchar_t because wchar_t is not necessary UCS-2LE
> on platforms other than Windows.]
I'll run it past Tridge when I get a chance. I should mention that
Microsoft decided to switch (!?) to a degenerate UTF-16. Ug. Mostly
compatible with UCS-2LE.
> So as you can see there are quite a few significant differences
> here. First what is unistr?
It is one of the many variations on strings that Microsoft uses in their
code. The termination and length calculations differ depending on which
you use. You have to jump thorugh some hoops to deal with this in MIDL.
> Well it is defined in idl_types.h (which is
> included with an include preprocessor statement which would normally
> be an import statement). Also the attributes are totally different. MIDL
> will not encode a referent for a parameter without a unique attribute
> even with pointer_default(unique). There isn't even a string attribute.
> #define unistr [flag(STR_SIZE4|STR_LEN4)] string
> Second, non of the out parameters are pointers. This generates an error
> with MIDL. I suspect they do that because PIDL will trigger an referent
> to be encoded where top-level pointers are ref pointers and out pointers
> are always ref pointers regardless of what pointer_default is.
> Granted I've really focused on this one RPC but AFAICT PIDL is not "slightly
> unusual" it's totally unique.
Right. It's tuned to handling MS-RPC, not DCE/RPC.
> Certainly there will be challenges moving forward for idlc but at the rate
> I'm going it will be much much better than PIDL RSN. Actually I was
> originally hoping to get those guys to switch to mine. I didn't think they
> were so attached to theirs but Tridge seemed a little bent that I wasn't
> interested in PIDL.
You missunderstand. He's been knee deep in MS-RPC code for a long time,
as have others on the Team. PIDL is what they put together based on their
experience. It isn't as complete as MS MIDL, but doesn't need to be.
The other thing is that all of the Samba IDL is being written in the PIDL
language. That's a vast library of IDL that you won't be able to use with
a MIDL-compatible compiler.
Just my 2cents, I guess.
"Implementing CIFS - the Common Internet FileSystem" ISBN: 013047116X
Samba Team -- http://www.samba.org/ -)----- Christopher R. Hertel
jCIFS Team -- http://jcifs.samba.org/ -)----- ubiqx development, uninq.
ubiqx Team -- http://www.ubiqx.org/ -)----- crh at ubiqx.mn.org
OnLineBook -- http://ubiqx.org/cifs/ -)----- crh at ubiqx.org
More information about the jcifs