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:

CLSID_RegFolder {0997898B-0713-11D2-A4AA-00C04F8EEB3E}

The class implements the following interfaces:

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

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.


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:

Registry Folder Registry Path for Namespace Definition
CommonPlacesFolder Software\Microsoft\Windows\CurrentVersion\Explorer\CommonPlaces\Namespace
ControlPanel Software\Microsoft\Windows\CurrentVersion\Explorer\ControlPanel\NameSpace
ControlPanelTasks Software\Microsoft\Windows\CurrentVersion\Explorer\ApplicationsWithTasks\NameSpace
MyComputer Software\Microsoft\Windows\CurrentVersion\Explorer\MyComputer\NameSpace
NetworkPlaces Software\Microsoft\Windows\CurrentVersion\Explorer\EntireNetwork\NameSpace
Printers Software\Microsoft\Windows\CurrentVersion\Explorer\PrintersAndFaxes\NameSpace
ShellDesktop Software\Microsoft\Windows\CurrentVersion\Explorer\Desktop\NameSpace
UsersFilesFolder Software\Microsoft\Windows\CurrentVersion\Explorer\UsersFiles\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

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

Key: HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\SessionInfo\session

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


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,

Offset Size Description
0x00 word size of item ID, in bytes, as defined for all item IDs 
0x02 byte identifies folder class (see below)
0x03 byte sort order index (see below)
0x04 varies item data;
interpretation varies with folder class;
presently used only for ControlPanel items
varies 0x10 CLSID for item

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

Identifier Folder
0x1F ShellDesktop
0x2E MyComputer
0x4D NetworkPlaces if resource display type is generic or root
0x4E NetworkPlaces if resource display type is server
0x70 ControlPanel, but item has no item data at offset 0x04
0x71 ControlPanel
0x72 Printers
0x73 CommonPlacesFolder
0x74 UsersFilesFolder

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:

Value: SortOrderIndex
Default: 0x80

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.

Offset Size Description
0x00 word size of item ID, in bytes, as defined for all item IDs 
0x02 word identifies folder class (see below)
0x04 word size, in bytes, of delegate folder’s data for item
0x06 varies delegate folder’s data for item
varies 0x10 the CLSID {5E591A74-DF96-48D3-8D67-1733BCEE28BA}
varies 0x10 CLSID for item

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.


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).