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