Where to put static libs?

[Juan Lang]

Any advice on where to put code that needs to be
shared by multiple dlls?  I'm tweaking the SMB code
right now, and I'd like to reuse it in netapi32 (to
implement some of the Net functions) as in kernel32
(for CreateFile and CreateNamedPipe).

I'm thinking a new directory in libs (libs/smb).  Any
better ideas?

Thanks,
--Juan

__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com

[Eric Pouech]

Juan Lang wrote:
> Any advice on where to put code that needs to be
> shared by multiple dlls?  I'm tweaking the SMB code
> right now, and I'd like to reuse it in netapi32 (to
> implement some of the Net functions) as in kernel32
> (for CreateFile and CreateNamedPipe).
>
> I'm thinking a new directory in libs (libs/smb).  Any
> better ideas?

first of all, most code dealing with file/pipe opening will be moved 
from kernel32 to ntdll (at least the core)
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)
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

A+

[Juan Lang]

--- Eric Pouech  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

[Eric Pouech]

> 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.

beware that you cannot directly call wsock32 functions (nor netapi32) 
from ntdll.
> 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."

if you really want to share the code, better implement the TDI interface 
to linkage points in ntdll and make netapi32 depend on it, but that may 
be a bit overkill for the moment.

A+

[Juan Lang]

--- Eric Pouech  wrote:
> > 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.
>
> beware that you cannot directly call wsock32
> functions (nor netapi32) 
> from ntdll.

Ah!  I wasn't aware of this.  Why not?
> if you really want to share the code, better
> implement the TDI interface 
> to linkage points in ntdll and make netapi32 depend
> on it, but that may 
> be a bit overkill for the moment.

Yikes.  Probably.  I don't know enough about the TDI
interface to do this yet.

Thanks,
--Juan

__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com

[Eric Pouech]

Juan Lang wrote:
> --- Eric Pouech  wrote:
> > > 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.
> >
> > beware that you cannot directly call wsock32
> > functions (nor netapi32) 
> > from ntdll.
>
> Ah!  I wasn't aware of this.  Why not?

because we don't allow, in Wine, for (direct) circular dependencies on 
modules:
wsock32 => kernel32 => ntdll
you can always doit by handle, with LoadModule/GetProcAddress pair
A+