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