--- Eric Pouech <[EMAIL PROTECTED]> 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
