The Windows Explorer Command Line

The EXPLORER command line is a sequence of fields with commas and equals signs serving as separators. To allow commas and equals signs within a field, there is a facility for enclosure by double-quotes. The double-quotes are otherwise ignored, except that two consecutive double-quotes in the command line pass into the extracted field as one literal double-quote. White space is ignored at the start and end of each field.

Each argument for EXPLORER is one or more fields, shown below as if separated only by commas and without the complications of white space or quoting. Where the first field is a command-line switch, necessarily beginning with the forward slash, it is case-insensitive.

The overall aim of the command line is to specify a shell namespace object and a way in which EXPLORER is to show that object.

Ordinary Specification of Object

Where the first field in an argument is not a command-line switch, the whole field is interpreted as a path in the shell namespace. If the path as given does not identify a shell namespace object, it is re-interpreted as a file-system path relative to the current directory.

Shell Namespace Paths

A shell-namespace path may be a file-system path but may also refer to class objects by using the notation of two colons followed by a CLSID in curly braces. For instance,

explorer ::{21ec2020-3aea-1069-a2dd-08002b30309d}\::{2227a280-3aea-1069-a2de-08002b30309d} 

opens the Printers folder in the Control Panel.

As an amusement, note that

explorer ,

is a convenient, if undocumented (and possibly unintended), shorthand for opening the Computer object (previously called My Computer). This works because the comma delimits an empty path. When this ends up with the SHELL32 function SHParseDisplayName as an empty pszDisplayName argument, it is interpreted as referring to the Computer object.

A more serious aside is that Microsoft seems never to have documented a formal syntax for the shell namespace. Some explanation may be that since each object in the namespace can take responsibility for parsing the display names of its items, and interpret the text however it wants, there is no generally applicable syntax to document. However, almost all parsing in everyday practice, as for the EXPLORER command line, starts from the desktop folder and much of it proceeds through one or another built-in objects that have a common handling as registry folders. The syntax applied by these registry folders is as close to a standard syntax as exists for the shell namespace and is surely important to know. Why is it not documented?

Object As ITEMIDLIST From Other Process

It may be that whoever asks to run EXPLORER already has the object described in the structural form used throughout the shell, i.e., as an ITEMIDLIST. A typical occasion is when a shell namespace object is to be opened by calling the SHELL32 function ShellExecuteEx and the database of file associations names EXPLORER.EXE as the program to run for applying the requested verb to the object. In a standard installation of Windows Vista, this is set up not just for objects of type Folder but also for cabinet files and zip files and for less obvious things such as the Windows Search Protocol.

The field after a /idlist is expected to begin with a colon and the handle. The latter is an optional minus sign and any number of decimal digits. These may in turn be followed by any number of characters that are not decimal digits until another colon and the process. This too is an optional minus sign and any number of decimal digits. Any remaining characters in the field are ignored. An object specified by /idlist and a valid second field replaces any object specified by any earlier argument of any sort. If /idlist does not have a second field from which an ITEMIDLIST actually is obtained, then the whole command line is invalid unless an object is specified by an earlier argument (in which case, just the one or two fields of the /idlist argument are ignored).

Root

If /root does not have at least a second field, then the whole command line is invalid. If the second field is /idlist, an additional field is expected as when /idlist begins an argument. However, if the additional field is absent or does not yield an ITEMIDLIST, then the two or three fields of the /root argument are ignored.

The clsid for a /root argument is the usual representation with curly braces. It provides a root class. If omitted, EXPLORER uses {00021400-0000-0000-C000-000000000046}, which is known symbolically as CLSID_ShellDesktop. If a clsid is given without a path, then provided that Windows is not started in one of its safe modes, EXPLORER finds the path from the following registry key:

If the key does not exist or its default value does not have string data or if Windows is in Safe Mode (with or without networking), then the path cannot be resolved and the command line is invalid.