DefineDosDevice - ??
Martin.Wilck at Fujitsu-Siemens.com
Tue Sep 17 06:22:48 CDT 2002
Am Die, 2002-09-17 um 20.48 schrieb Mike McCormack:
> Did you get my other mails? I'll include the text again... they don't
> seem to have made it to wine-devel, so I'm wondering if they got
> anywhere at all...
No they didn't, at least not to me. Thanks for resending...
> BTW. The PAM module you are talking about was a goal of Samba TNG.
"Was" - does that mean the project is dead?
I reckon that the "winbind" module of the current Samba release is
pretty close to what we want in terms of host, user, and group lookup.
> I think that can be done with a NetBIOS QUERY packet with "*" as the
> name to query. You'll then get every machine on your local network
> sending a QUERY RESPONSE packet back to you with the machine's name.
> The operation is similar to the code to resolve a NetBIOS name (see
> NB_Lookup in files/smb.c)
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?
> 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
> shell32 manages passwords and shares through MPR.DLL. We need to add
> some code to show the Network Neighbourhood icon and probe any connected
> shares, connect new shares, etc to shell32.
> If you need something specific, I'll see what I can do, but a full
> implementation is probably a bit much for this weekend ;-)
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
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.
Martin Wilck Phone: +49 5251 8 15113
Fujitsu Siemens Computers Fax: +49 5251 8 20409
Heinz-Nixdorf-Ring 1 mailto:Martin.Wilck at Fujitsu-Siemens.com
D-33106 Paderborn http://www.fujitsu-siemens.com/primergy
More information about the wine-devel