coding volunteers needed for msrpc server-side API conversion

[Elrond]

Okay, that convinced me. :)

But then we need some lot of functions that will operate on
unistrings. Like strchr, so we can strip of the domain in
lsarpc, when we want to ask samr.

... Wee... sounds like some lot of work...

Oh well... and in the long run, we will need dynamic
unistrings.


On Fri, Jan 28, 2000 at 06:43:21AM +1100, Luke Kenneth Casson Leighton wrote:
> > > so, for now, we massage the code into something suitable, remove the
> > > marshalling / unmarshalling from actual _implementation_ of the functions,
> > > and _then_ we can go for auto-gen'd marshalling / unmarshalling.
> > > 
> > > which is why it's important to use UNICODE strings not char*.
> > 
> > Hmmm... yes... (not yet completely convinced :-))
> 
> on UNICODE?  it's simple.  we can't do it, because that's not what
> microsoft implemented.  therefore, we have to use UNICODE.
> 
> i want to implement, for example, a srv_samr_tdb.c which stores UNICODE
> strings.
> 
> if you convert to using char* as the samr API, i can't do that, and we
> lock out all the samba users in russia, china, japan and all other
> non-ascii-based alphabets.
> 
> plus, the recursive-implementation of the LSA (as a redirector) has to be
> in UNICODE because the client-side is UNICODE because the server-side is
> UNICODE (a recursive argument for a recursive implementation :-) :-)
> 
> we can't just convert to ascii and back to unicode because we feel like
> it, we're losing info.
> 
> the only reason i did that as a first  implementation was because it is
> simple to do.  now we have to move on.