On Sun, Jun 24, 2001 at 10:30:00AM -0700, Justin Erenkrantz wrote: > On Sun, Jun 24, 2001 at 07:18:41PM +0200, Luke Kenneth Casson Leighton wrote: > > > I'd guess that it wouldn't be too hard on your end to at > > > least post a patch/code (within APR framework) that illustrates what > > > you are talking about. > > > > ack. well, a _quick_ one is simple, you are right. about... > > 1 days' work? > > Yeah, that would be sufficient (Unix only). Just give us an idea of > what you are talking about. The fact that on NT/OS2 it goes directly > to a system call that is named pipes and on Unix goes to domain sockets > (I need to read up on those) doesn't bother me in the least. The > functionality would have to be equivalent (LCD) and they would have to > be able to talk to each other. i have a question: can you do a select() / listen() / bind() / accept() on a *unix* namedpipe?
can you do equivalent-of-select() /listen() ... on an NTnamedpipe? > So the Unix implementation on the network side has to be compatible > with the NT implementation - how are endian issues dealt with in SMB, > for example? well, in samba, there are conversion-macros - equivalent to ntoh - but intel-byte-order not network-order :) so, you always end up, in your host, with data in the right order. but, i have to point out: it doesn't really have anything to do with creating an NTpipe api :) :) okay, maybe it does, and i'm so used to it, i forget :) > > a more complete one? with a 'clean' way to transfer > > security context? and the code _does_ need a security > > audit, which i even print out this fact into the > > log files :) :) about a week. > > That's what we are here for. =) We're not perfect, but enough good > people looking at it will do just fine for our purposes. -- justin :)
