215 lines
7.3 KiB
Plaintext
215 lines
7.3 KiB
Plaintext
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
|