Gavriel State fired a discussion on integrating Samba into Wine. Samba is a GPL implementation of the Microsoft SMB protocols and environment which allow the sharing of resources on a network (mounting remote drives - known as shares in Microsoft jargon -, browsing resources of a distant machine - exported shares, printers... -, discovering the other machines attached to the same network...).

Gavriel's first post was in fact a public answer to a note from Jean-Claude Batista: The way I see this implementation consists in three levels. The File I/O functions, the Windows Networking API (the WNet functions) and the shell functions that deal with virtual folders to implement the network neighborhood. Since a filename can consist of a UNC (Universal Naming Convention) and a file path, the file I/O functions must be able to find them on the network. I believe the less troublesome way to obtain file network transparency would be to use "smbmount" (Samba mount tool) to mount the network drive to a temporary path and then use this path to access the file. Once the file is no longer needed, we would unmount the path. I'm not sure I could call smbd functions directly and using the C code, it might result in a licensing conflict between Wine and Samba. Using smbmount might require to install it as root with the SUID bit enabled, so that users can mount the drives.

Since we need to keep track ok all the mounted drives, I think we should do that in the Wine server side.

Gavriel agreed on the global orientation, but proposed another solution regarding the file I/O functions: There is a library called 'smbwrapper', that if pre-loaded before libc, will replace the libc file management routines with ones that understand UNC pathnames. IE: You'd be able to fopen "\\server\share\file" directly. Also, you can list the network neighborhood by just doing an ls on /smb. There may be a license issue though, in which case we might have to use smbmount directly as described above. It's probably worth contacting the Samba team via email if it looks like there's a license issue.

Note that the Corel File Manager does exactly the same kind of thing (using smbmount, etc) and they may have already implemented code that might be useful on the WINE side in some of their libraries.

Gavriel also preferred to mount temporary shares in ~/.wine directory (to deal with Unix file permissions issues, read the technical details - the same as the ones for wine-server's socket creation), and noted that some UI parts (like getting the user ID and password), and under the hood features (caching the passwords for a given session), already written by Corel, shall be reused. Printer and File dialogs will also need some more work to integrate the Network facilities.

Steve Langasek sadly posted that, because of a 'design decision' on the part of the glibc team, smbwrapper no longer works with glibc: they deliberately removed several shadowed function symbols in order to make it impossible to use userspace VFS modules. I think this was a downright crummy thing to do, but the decision stands for the time being.

OTOH, smbwrapper could be linked into Wine at a higher level; but at that point, you run into the problem of licensing.

Oleg Noskov (also from Corel, but on the CorelLinux part) gave a inner look at the SMB integration shipping with Corel Linux 1.0: Here's what we do in brief:

• we have a constantly running server process (called netserv) which does
  • UNC name resolution and handing
  • Credentials (username/domain/password) caching
  • Automounting of shares
• we have a shared library (libmwn) which is acting as a wrapper for Linux file I/O. We have our wrappers for open/fopen/access/stat/unlink etc. library functions and system calls. Internally, libmwn looks if a file name is a UNC filename and in such case it issues a "netmap" call to the netserv process. Netserv mounts the corresponding share in the temporary location if necessary (or reuses earlier mounted share if UID of the caller is the same) and returns temporary local path to the libmwn. Libmwn passes that name to the native function/system call and returns to the calling program. When mounting, netserv uses its credentials cache to find out which set of credentials to use. If necessary, user will be prompted for new set of credentials (works OK for us). Netserv monitors successful network access attempts and updates its cache.

  Additionally, netserv takes care of garbage collection, usage counters, removal of temporary directories,

Netserv/libmwn are working great in Corel Linux and can be used by WINE.

If WINE is running not in Corel Linux, it is still possible to use all of this, provided netserv is launched by some script or application before all the UNC-related activity begins.

Netserv/libmwn are distributed under CPL.

and Oleg went later on: Well, at present time libmwn depends on some KDE core libraries and on ccqt library (Corel's version on Qt 1.4x). Looks like if WINE team is interested in using netserv/libmwn, we should consider extracting UNC mapping/wrapping code from libmwn and making it a completely separate library (currently libmwn contains LOTS of other stuff needed by Corel File Manager).

Gavriel State answered: The licensing isn't a problem, since WINE is under a BSDish license, and soon to switch to the X11 license. What's much more questionable is how we can mix WINE code with QT code: can windows handled by WINE co-exist in the same process as QT's windows?

If not, we have two possible approaches:

1. Make a separate process that handles UI for browsing, etc, and have WINE talk to it through a socket.
2. Rewrite netserv/libmwn to be completely independent of the underlying GUI system (ie: have them weak link to another library that provides UI). That way, we could do a direct WINE UI for browsing and password entry in addition to a KDE UI. Doing something like this will help the transition to KDE 2.0, and will make GNOME-based usage possible as well.

Everyone (at least the ones who spoke out their minds) agreed that option (2), even if it's the most costly one, was the favored one, at first for its flexibility.

Uwe Bonnes posted a patch which checked, while processing the data block of the bitmap, if those bytes were readable. If not, it was just returning an error (instead of the previous behavior which was a naughty segmentation fault).

Alexandre Julliard rejected the patch because testing if the memory was valid (with IsBadReadPtr() API) before doing an operation doesn't imply, in a multi-threaded environment, that memory will still be valid after the check (another thread could for example free the memory block).

Alexandre was also angry at Microsoft:It can be noted that most Win95 functions that have an exception handler do it the same way (set handler/touch memory/remove handler/do actual function) but it is of course wrong. Not that you need that in order to crash Win95 anyway...

Uwe agreed in general, but asked, regarding another patch (which was also using IsBadPtr()) that Alexandre accepted.

Alexandre pointed out that this patch was using 16 bit IsBadPtr functions, which should stay, since we cannot use exceptions to trap them (because we are always doing 32-bit accesses we bypass the CPU selector checks)., but that 32 bit IsBadPtr functions should be avoided.

Joerg Mayer posted the announce an interesting Windows NT tools for the Wine developers: Hi,

I've written a debugging/investigation utility for examining the NT system calls made by a process. It is meant to be used like the strace on linux and other unix OSes.

An example: [c:\strace] strace notepad
1 133 139 NtOpenKey (0x80000000, {24, 0, 0x40, 0, 0, "\Registry\Machine\Software\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\notepad.exe"}, ... ) == STATUS_OBJECT_NAME_NOT_FOUND
2 133 139 NtCreateEvent (0x100003, 0x0, 1, 0, ... 8, ) == 0x0
3 133 139 NtAllocateVirtualMemory (-1, 1243984, 0, 1244028, 8192, 4, ... ) == 0x0
4 133 139 NtAllocateVirtualMemory (-1, 1243980, 0, 1244032, 4096, 4, ... ) == 0x0
5 133 139 NtAllocateVirtualMemory (-1, 1243584, 0, 1243644, 4096, 4, ... ) == 0x0
6 133 139 NtOpenDirectoryObject (0x3, {24, 0, 0x40, 0, 0, "\KnownDlls"}, ... 12, ) == 0x0
7 133 139 NtOpenSymbolicLinkObject (0x1, {24, 12, 0x40, 0, 0, "KnownDllPath"}, ... 16, ) == 0x0
8 133 139 NtQuerySymbolicLinkObject (16, ... "C:\WINNT\system32", 0x0, ) == 0x0
.
.
.
For more information and download (including source), see http://razor.bindview.com/tools/desc/strace_readme.html