hi,
wrote to the wine-devel mailing list about this one describing a few words about what's needed to be done to "support" your efforts.
documentation.
rfc1001.txt and rfc1002.txt - these describe NBT (netbios over tcp) and how to get:
- datagrams (port 138) equivalent to UDP - sessions (port 139) equivalent to TCP - names (port 137) LISTEN UP! THIS IS EQUIVALENT TO DYNAMIC-DNS + DHCP!
the last one of these needs careful explanation.
in light of the recent attempts by the wireless IETF crowd to create a dynamic routing protocol is is _totally_ ironic that netbios got there first _by over twenty years_ - and that there is a FREE implementation for the taking, in nmbd.
it's also pretty ironic because they've had to play catch-up with concepts like node status queries in additional extension draft rfcs, and they STILL haven't added the "name conflict" concept which is there to tell anyone that will listen that a name which is attempting to be claimed is being taken by someone else who won't give it back.
port 137 _is_ actually dns, so if you happen to know of any wine-licensing compatible DNS client code then you can use that as the basis for your efforts.
it's dns but it's extended: the names of the types of packets mean slightly different things;
there is additional packet types to represent NAME_REGISTER and NAME_STATUS;
there is also a different CNAME type to cope with netbios names;
the "dns zone" is there it's called a "scope";
the "dns name" is "compressed" it's a brain-dead misnomer given that the name is actually expanded in some sort of stupid base-4 (no, not base-64, yes, that's right, base-4) encoding scheme that turns a 16-byte space-padded thing into an overbloated 64-byte monster.
cifsbrow.txt.
eek, it's been a while. have a look at www.cb1.com/~lkcl/ntdom.
no, try this: http://www.monyo.com/technical/samba/rfc/
actually, first try this: http://ubiqx.org/cifs/References.html
which will give you a better idea of what the other one contains: the ftp://ftp.microsoft.com/developr/drg/CIFS directory appears to be inaccessible, now, which is just typical.
basically you should read cifsbrow.txt in conjunction with rfc1001.txt and rfc1002.txt.
SKIM THEM!
YOU ONLY NEED A MINIMAL SUBSET OF THOSE DOCUMENTS FOR A CLIENT IMPLEMENTATION!!!!
the only reason that you need to read those docs - skimmed - is because you need to know what you are going to be communicating with (not implementing, server-side, just connecting to, client-side).
all you _really_ need is to be able to do a NetBIOS name query and also to be able to do a couple of SMB queries to obtain lists of servers.
THAT IS ALL THAT A CLIENT-SIDE NETWORK NEIGHBOURHOOD BROWSER IS. REALLY!
if you're implementing this from scratch, however, expect to allocate about ... mmm ... anywhere between four and eight weeks.
i _thoroughly_ recommend that you investigate finding some dns client code to adapt and save yourself some time with decoding port 137.
also, while you're at it, you might want to next focus on the contents of the ntnp.doc file which was last available with the ms-dev that contained visual studio 4.3.
ntnp.doc stands for nt network provider and it had a companion "client-side" document to describe the other bit that went with it.
basically there is a "redirector" protocol on both client _and_ server-side that covers browsing.
these two protocols "merge" the network neighbourhoods into one big happy family, such that netware's network neighbourhood can be installed and cooperate happily with the smb network neighbourhood can be installed and cooperate happily with the kerberos-domain-based network neighbourhood and it was all one big happy family yippee.
so, whilst you may believe that it is best to implement the network neighbourhood browsing functions as "direct" as possible, if you ever install the "client for netware" under wine and then wonder why it doesn't appear in the network neighbourhood, remember what i said in the paragraph above!!
l.