RegFolder

The RegFolder class is one of many that SHELL32 exposes through its exported DllGetClass function. Instances can therefore be created using such well-documented COM functions as CoCreateInstance, by anyone who knows the CLSID:

The class implements the following interfaces:

• IBackReferencedObject (version 6.00 from Windows Vista, and higher)
• IContextMenuCB
• IDelegateHostItemContainer (version 6.00 from Windows Vista, and higher)
• IObjectWithBackReferences (version 6.00 from Windows Vista, and higher)
• IRegItemFolder (version 6.00 from Windows Vista, and higher)
• IShellFolder2 and its base IShellFolder
• IShellIconOverlay
• ITransferProvider (version 6.00 from Windows Vista, and higher)

A RegFolder is intended to exist as an aggregated object. It is the inner object for the following other creatable SHELL32 classes:

• CommonPlacesFolder, implemented internally as CCommonPlaceFolder
• ControlPanel, implemented internally as CControlPanelFolder
• ControlPanelTasks, implemented internally as CTasksFolder
• MyComputer, implemented internally as CDrivesFolder
• NetworkPlaces, implemented internally as CNetFolder
• Printers, implemented internally as CPrinterFolder
• ShellDesktop, implemented internally as CDesktopFolder
• UsersFilesFolder, implemented internally as CUsersFilesFolder

Use of the RegFolder class as the inner object for all these others gives them a common format for their PIDLs and a shared handling of much of their basic behaviour. For present purposes, all these outer objects are referred to collectively as registry folders.

Namespaces

Registry folders have common treatment of their namespaces. Put another way, there is a common mechanism for populating registry folders. This is perhaps even what gives the class its name, since the population is defined through registry settings. When each registry folder is initialised (through the Initialize method of its IRegItemFolder interface), it can be given a registry path in which subkeys define items in the folder’s namespace:

Of the two namespace paths for the ControlPanel class, the second applies if the current process is running as a 32-bit process on 64-bit Windows. For the NetworkPlaces class, one namespace path is selected according to whatever is specified as the resource display type when initialising the object (through the Initialize method of its IInitializeNetworkFolder interface). The paths are listed for RESOURCEDISPLAYTYPE_ROOT, RESOURCEDISPLAYTYPE_GENERIC and RESOURCEDISPLAYTYPE_SERVER respectively.

Each registry folder is initialised from

• a hard-coded list of required items, which is empty for most folder classes;
• subkeys of the namespace path in HKEY_LOCAL_MACHINE;
• subkeys of the namespace path in HKEY_CURRENT_USER;
• subkeys of the DelegateFolders subkey of the namespace path in HKEY_LOCAL_MACHINE;
• subkeys of the DelegateFolders subkey of the namespace path in HKEY_CURRENT_USER;
• subkeys of the per-session namespace path;
• subkeys of the DelegateFolders subkey of the per-session namespace path.

The per-session namespace path is the same as the namespace path but relative to the session key instead of to the Explorer key. The session key is

in which session is a decimal representation of the current session ID.

PIDLs

Items in registry folders have a shared format when represented as an item ID (more formally, an SHITEMID structure). As with all such structures, the first word is the size in bytes of the ID. The bytes from offset 0x02 and onwards are whatever the folder wants. For registry folders,

The signature byte at offset 0x02 is convenient as an immediate description of the folder that contains the item:

The sort order index at offset 0x03 helps determine the ordering of items in the folder. For required items, such as the MyComputer object in the ShellDesktop object, the sort order index is fixed. (Only the ShellDesktop and ControlPanel clases have required items.) For other items, except delegates, the sort order index is read from the registry:

The data is presumably meant to be REG_DWORD, but data of any type is accepted, to a maximum of 4 bytes. If the current application has the MYCOMPUTERFIRST compatibility flag (in the sense of the undocumented SHGetAppCompatFlags function), then whatever is read from the registry is ignored and the sort order index is forced to 0x51, placing it just higher than the sort order index that is hard-coded for the MyComputer object.

Delegate Items

The preceding description of PIDL format does not apply to items in delegate folders. For these, the PIDL is a DELEGATEITEMID.

The identifier at offset 0x02 is the same as in the registry folder’s own PIDL. The first CLSID confirms for the registry folder that this PIDL is for a delegate folder. Microsoft’s name for this CLSID is not known.

Availability

The RegFolder class is implemented in SHELL32 version 5.00 and higher.

Though this class dates from 1999, it was still not documented by Microsoft as late as the January 2007 edition of the Windows Vista Software Development Kit (SDK).