http://wiki.winehq.org/NamedPipes - documenting the samba / wine NamedPipes integration

[Luke Kenneth Casson Leighton]

i've been updating this page with relevant information that is part
requirements specification, part documentation.  of particular
relevance is the lack of support (in both tng and samba 3) for
transferring SetNamedPipeHandleState semantics, although the "stub"
functionality inside tng (smbd/pipe-proxy.c) at least records the NP
message-mode flags, and then _completely_ ignores them ha ha :)

exactly how this is to be implemented is unclear, and to be absolutely
honest, by far the simplest-sounding approach may be to actually
compile samba up as a win32 app!

under such circumstances, it would be incredibly easy to then call the
wine-emulated NamedPipe win32 functions CreateNamedPipe,
SetNamedPipeHandleState etc. etc.

given that samba tng has _already_ successfully been ported to win32,
it has a head start here.  and in that regard, ReactOS has it made,
done and dusted!

the alternative is... gaahd, i dunno... messy, to say the least, and
*shudder* an mmap'd tdb is sounding _really_ attractive.

tell me if this sounds reasonable.  basically, a mini-wineserver
protocol - a mini-SMB protocol - is required.  commands to "send",
"receive", "setnamedpipestate", "waitnamedpipestate" and "close".  all
required.

* samba 3 / tng create or access named pipes as emulations over unix
domain sockets, including sending a security context.

in samba 3, that's called a SamInfo3, but it looks suspiciously like a
NETLOGON NET_USER_INFO_3) and in tng it's a NET_USER_INFO_3... so...
yep, it looks like just the name has been changed.

* a program wants to create or access a named pipe; it asks wineserver
(via a new function) to create or open up a unix domain socket.

the locations will be the same.  i.e. tng / samba3's unix domain
socket pipe locations same as wineserver's.

* sending / receiving of the security context blob is done in the dlls
NOT in wineserver, so as to avoid blocking wineserver.

* read, write, snphs, wnphs are all done with a 2-byte command prefix,
followed by parameters, followed by data.  exactly the same as is done
in SMB and in wineserver.

... you know... if SMB wasn't so damn complicated i'd say bugger it,
just send the SMBs to Wine, for _it_ to sort out!!  in fact, with
cliffsd's auto-generated SMB parsing code, that might even still be a
valid option, given that the relevant code for parsing the SMBs is
public domain.

what do people think?

does this sound like a reasonable proposition - a mini SMB/wineserver
protocol - for use for inter-communication between wine and samba in
order to exchange named pipe traffic?

l.