On Thu, Jan 20, 2005 at 09:08:27AM -0800, Juan Lang wrote:
Hi Luke, you said:
that's where you'd need the cooperation of samba / samba tng: it's got "SIDs" behind it, and "SIDs" means a SAMR server and a NETLOGON server and an LSARPC server (and in the case of windows 2000 interoperability, access to an Active Directory Server).
Another possibility is that we implement our own version of a SAM. Right now we just return a fake Administrator SID every time we're asked for one. But if we absolutely needed to, we could implement a local version and it needn't even be a separate process. The NT SAM registry is pretty well reverse engineered here:
hah, coooool! that's so hilarious.
okay, yep - the bit here:
\HKEY_LOCAL_MACHINE\SAM\SAM\Domains\Account\Users%RID%\V (variable length, 424+)
that's just a SAMR_USER_INFO_21 structure - been there, done that.
see here:
http://viewcvs.samba-tng.org/cgi-bin/viewcvs.cgi/tng/source/include/rpc_samr...
by the way - does anyone understand the SamrQueryAliasMembers function and the SamrQueryUserAliases function?
these are the _weirdest_ functions i ever heard about and i really haven't understood them well.
you can always still implement RpcImpersonateClient as a stub.
Yah. I think that's more likely than that we go whole-hog on it.
_great_ because if you do that, i'm likely to rip that off whole-sale for use behind a DCE/RPC interface - using samr.idl (from which samr.h has been generated) - see:
From experience, it's often more important to get things like parameters and error codes just the way Windows programs expect than it is to make a function "really work." By implementing a stubbed or local-only version, we can figure out all this stuff, and maybe make a full-blown version later.
see below, because if you implement "stub" versions, and the intercommunications (in this case DCE/RPC), it will be possible to "drop in" a replacement like samba tng's services or even if the samba team will cooperate, a samba 3 or even a samba 4 server.
at run-time.
because that's what DCE/RPC gives you: binary-level separation and network-defined interface points.
it's just so utterly cool.
and later,
it _does_ mean careful design because i doubt very much whether people will be happy to have samba tng as a dependency on Wine.
Agreed. The focus for the Wine folks is generally, does this get my app to work? Unless it's fixing an app, not too many folks are likely to get real excited by anything.
Feel free to point out what we've been missing. Patches speak louder than anything here :)
would you be _really_ ready for a couple of hundred thousand lines of code??? virtually the _entire_ samba tng project _and_ the freedce project???
*lol* :)
no, but seriously, as you can see by the thing sparked off by rob's RpcImpersonateClient question, there's a whole _truck_ load of code needed that sort of "hangs together".
combine that with the fact that you (wine) _must_ conform _exactly_ to the required APIs at both a header-file level, IDL file level, binary level, pretty-much-everything level, if one group implements one part (behind, say, samr.h to produce samr.dll) then that's _exactly_ what's needed for samba tng.
and also the corrolololorary is that if you can get the rpcrt4.dll working _properly_ - i.e. wire-compatible with DCE/RPC / MSRPC, then you won't _need_ to do any work on producing a samr dll, you can just communicate directly with samba tng's samr server.
plus various other combinations along the same lines that would do everyone's heads in to enumerate.
l.