This file contains random notes on the implementation of a shell name space
extension.
The shareui name space extension mostly independent of the shell, and only uses
a few shell interfaces that are internal, particularly the standard shell
folder view, using SHCreateShellFolderViewEx.
===========================================================================
== Menus
===========================================================================
Menus appear in several places:
1. Context-menus on a selection
2. Context-menu on the background
3. The menu bar, with a selection
4. The menu bar, with nothing selected
=======
For (1), the menu is:
Delete
------
Properties
and the default is Properties. Properties is grayed if there is more than one
item selected.
=======
For (2), the menu is the standard shell folder view menu, plus a "New" item:
View
Large Icons
Small Icons
List
Details
-------
Arrange Icons
by Name
by Comment
by Max Uses -- only for administrators
by Current Uses -- only for administrators
by Path -- only for administrators
-------
Auto Arrange
Line up Icons
-------
Paste -- always grayed
Paste Shortcut -- always grayed
-------
New
Share
=======
For (3), the File menu should be:
New
Share
-------
Create Shortcut -- always grayed
Delete
Rename -- always grayed
Properties
-------
Close
and the View->Arrange Icons menu should be:
by Name
by Comment
by Max Uses -- only for administrators
by Current Uses -- only for administrators
by Path -- only for administrators
-------
Auto Arrange
As with (1), Properties will be the default, and will be grayed if the
selection includes more than one item.
=======
For (4), the File menu should be:
New
Share
-------
Create Shortcut -- always grayed
Delete -- grayed
Rename -- always grayed
Properties -- grayed
-------
Close
and the View->Arrange Icons menu should be the same as in (3).
=======
The implementation for these various menus occurs in several different places
and should be synchronized to make sure the menus all do the same thing.
Case (1) is implemented by the shell calling IShellFolder::GetUIObjectOf asking
for IContextMenu.
Case (2) is implemented by the shell calling IShellFolder::CreateViewObject
asking for IContextMenu.
Case (3) is implemented by the shell calling IShellFolder::GetUIObjectOf asking
for IContextMenu. The context-menu is created. Also, the ...?
Case (4) is implemented as follows. When a shell folder view created using
SHCreateShellFolderViewEx is created, it calls back the passed-in callback
function with the message DVM_MERGEMENU. At this point, the background menus
are created.
The IContextMenu interfaces are also invoked for other uses, namely performing operations from the toolbar. The toolbar calls IShellFolder::GetUIObjectOf
asking for IContextMenu when it needs to call properties or delete an item.
It calls IContextMenu::InvokeCommand with string commands "delete" or
"properties" in these cases.
===========================================================================
== Multiple file services
===========================================================================
The UI enumerates shares from any of the three supported file services: SMB
(LanMan/NT), SFM (Macintosh), and FPNW (NetWare compatible). A server is
considered if NetServerGetInfo returns the proper type bit for the service.
In addition, for SFM and FPNW, we LoadLibrary their support/administrative
DLLs (sfmapi.dll & fpnwclnt.dll) and GetProcAddress the functions we need.
If that fails, we don't support that service. For the SMB server, we
statically link to netapi32.dll, which must exist on all NT machines. Note
that the user can do remote administration of the non-SMB file servers
by simply copying the proper support DLLs locally. For SMB sharing, we only
support NT machines, not Lanman or OS/2.
Although the different file servers have similar sharing models, there are
subtle differences, including allowable share names, the file system that the
shared directory can reside upon, and permissions. Here's a summary:
SMB:
max share name length: NNLEN (80)
share name is composed of UNICODE characters
illegal share name characters: Use NetpNameValidate
max comment length: MAXCOMMENTSZ (256)
path: can be any file system
security: share ACL
SFM:
max share name length: AFP_VOLNAME_LEN (27)
share name is composed of UNICODE characters
illegal share name characters: ":"
no share comment
path: must be on NTFS
security: volume password
has a properties mask
FPNW:
max share name length: NETWARE_VOLUMENAMELENGTH (16)
share name is composed of UNICODE characters. Must be able to be translated
to OEM. Must be uppercase.
illegal share name characters: ":" "\" "/"
no share comment
path: can be any file system (no SID on NTFS???)
security: share ACL
Since FPNW requires the name to be in uppercase, we will do a case-insensitive
comparison with share name and path name to determine if a share is "the same".
We will display the SMB name in all cases, even though we will create FPNW
shares by first upcasing the name.
When someone creates a share, we make several checks. Currently, only dealing
with SMB sharing, the checks are as follows:
1. Is the share name empty?
2. Is the share name special (IPC$, ADMIN$, drive$)?
3. Is the share name valid?
4. Does the share already exist?
(a) are they trying to re-share a special share?
(b) does the same share and path exist?
(c) do they wish to delete the old share and use the name for the new share?
5. Is the share name accessible by DOS clients?
With the addition of the other two file systems, the checks will be:
1. Is the share name empty?
2. Is the share name special to SMB (IPC$, ADMIN$, drive$)? If so, only create
an SMB share, don't create shares for the other services.
3. Is the share name valid to SMB (length, characters)?
4. Is the share name valid to SFM (length, characters)?
5. Is the share name valid to FPNW (length, characters)?
6. For any file service that we're trying to create the share for, does
the share already exist for the service?
(a) are they trying to re-share a special SMB share?
(b) does the same share and path exist?
(c) do they wish to delete the old share and use the name for the new share?
7. Is the SMB share name accessible by DOS clients?
===================================
== Details view columns
With only SMB shares, there are either two or four details view columns,
based upon user permissions. If the user has permission to enumerate SMB
shares at level 2 (as opposed to 1), then four columns are shown. The
columns are:
Share name (or Wizard name)
Comment (none for Wizards)
Path (if permissions allow)
Maximum Users (if permissions allow)
If there are multiple file servers, then we add an additional column at the
end:
Service Type
Which will be one of:
Microsoft Windows Network (can we get away with just "Windows"?)
FPNW
MacFile
Multiple, in which case the property sheet has all the info you need