Hi Martin,
> I need yet to understand how all these things relate. Winsock may use > NetBIOS as a service provider, but NetBIOS seems to offer an independent > interface to other APIs as well, right? If I understand you right, the > Netbios stuff is then located somewhere in kernel32. Is the winsock > provider an independent package or part of the NetBIOS core? Yes, I believe that the NetBIOS implementation is a kernel driver in Windows. >>The named pipes code needs to be rewritten to work through SMB so that >>we can support DCOM clients (computer to computer). Supporting a DCOM >>server is a problem because Samba is usually in the way on the ports we >>need to listen to... it would be nice to have some way for Samba and >>Wine to work together... a Netbios kernel module perhaps? > > > IMO this raises more fundamental questions about the role wine should > play. Samba is a service offered by the Unix system on which wine is > running. If wine were to grab the NetBIOS ports, it would take over this > service functionality; I doubt that's a good approach. Wine could > perhaps offer services on an IP alias instead, somewhat similar as > described in http://www.deschner.de/gd/dual_samba.html Well, that's exactly what I want to avoid. NetBIOS multiplexes many NetBIOS "ports" through a single TCP/IP port. It can also use SPX/IPX as it's underlying protocol. If Samba were written the right way, it would be possible to share TCP/IP port 139 with Wine via a unix domain socket, so that applications running under Wine (eg. MS Hearts) could participate on the Windows network alongside Samba. > I think it needs to be clarified what we're actually heading for. As I > said, I consider it potentially dangerous if wine offers services on the > network bypassing the ordinary Unix security mechanism. Acting as a > client is a different story, I guess we want maximum functionality in > that area. Well, at least I would like to have full NetBIOS client functionality; access to file shares without mounting them on the UNIX VFS, access to Named Pipe endpoints on other machines, the ability to browse Network shares, etc. That would be a good starting point. If we could then go onto supporting applications that listen for NetBIOS requests, that would be good too. > When it comes to User authentication, I am strongly for wine > communicating with the Unix system (e.g. PAM). Then if PAM supports > NT domain authentication (through samba or whatever), Active directory > AKA LDAP authentication, etc., wine would, too. > We'd just have to ensure that we don't loose too much on our way through > the Unix layer. Yes, integration is what makes Wine good, so I agree with you here. > Martin > Mike
