DefineDosDevice - ??

[Mike McCormack]

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