--- Eric Pouech pouech-eric@wanadoo.fr wrote:
first of all, most code dealing with file/pipe opening will be moved from kernel32 to ntdll (at least the core)
Okay.
moreover, the SMB code (currently) is more a proof of concept than a full implementation of SMB (using SAMBA if possible would of course be preferred)
Agreed, although somebody needs to resolve the licensing issues. I'm a nobody, so what I say would have no weight with either group, so I'm not the right person.
the internal NTDLL interfaces for handling file systems are likely to evolve very shortly I also assume that you're referring (parly) to NetBios resolution if so, then copying the code might not be a wrong answer for now if not, please explain what you want to do in more details
Yes. In particular, this is what I've done: - implement a large set of the NetBIOS client functions (the function Netbios(), with NCBENUM, NBCFINDNAME, NBCCALL, NBCSEND, NBCRECV, NBCSENDDG) - improve the NetBIOS code: WINS support (experimental, I don't have a WINS server), big-endian support, name lookup retries - use winsock, rather than UNIX socket interfaces
I'm in the process of rewriting the SMB code to use winsock name lookup and socket calls without NetBIOS first, and to fall back to NetBIOS (using the Netbios() function) second if that fails.
I'd like to expose some SMB functions so that named pipes and files to UNC paths use the same library of SMB functions. A couple of netapi functions (NetServerEnum and NetShareEnum) need to create SMBs also, and I'd like to implement them--they can be used to implement "network neighborhood."
Thanks, --Juan
__________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com