views:

436

answers:

3

There seem to be a few virtual folders which have GUIDs associated to them (control panel, desktop) -

::{00021400-0000-0000-c000-000000000046} // desktop

Where the blazes are these defined? When are they used?

What I want is a way to have a string which represents a virtual folder without any ambiguity.

If, for instance, I were to create a PIDL for the desktop, the display name comes back as "C:\Users\Steve\Desktop".

Well, that's true at the moment - but its not really the correct folder. I can navigate in Explorer to that folder, and it contains a portion of the files on my desktop, not the entire desktop.

What I want is a way to encode that location as a string that will always navigate to the virtual desktop folder (the one that has all of its contents, not just a few things).

Does anyone know of a definitive list of such GUIDs? Or how I might convert a given PIDL into one?

I tried SHGetDisplayName(pidl, SHGDN_*) - every version of that for the desktop pidl gives me either a short "Desktop" or "C:\Users\Steve\Desktop". (I'm logged in under the 'steve' account, obviously).

Ideas / comments / pointers?

EDIT: So it seems that I can use the given answers below to have a list of Known Folder GUIds. But does anyone know programatically how to convert from a PIDL -> known folder GUID? I assume that I can ParseDisplayName("::{guid}") to get the PIDL, but is there a way to get to the GUID?

EDIT2: I still cannot find a way to get to the GUID programatically. However, for my purposes, I am recording the CSIDL_xxx that I use to create the object initially, and write that out & restore it later, and then create a PIDL by way of the CSIDL, which retains its correct identity (ie. it doesn't degrade into "C:\Users\\Desktop" but rather generates a PIDL that really points to the virtual desktop.

The trick for me is to always use the CSIDL->PIDL, never going to a string in between. CSIDL->PIDL->string->PIDL = degeneration into non-virtual path.

Thanks everyone for the help - and I'll keep looking if anyone finds more on the subject and posts it, I'd be interested! ;)

+2  A: 

I suspect you'll find this MSDN article to be useful.

Jerry Coffin
+3  A: 

If i understand you correctly you are looking for the CSIDLs (pre-Vista, include Shlobj.h) or KNOWNFOLDERID (>= Vista, Knownfolders.h).

Georg Fritzsche
Interesting! Props for link
John Dibling
A: 

I don't think these GUIDs are formally documented. You can use SHGetPathFromIDList() to get the GUIDs. It will indicate failure, but if you look at the pszPath parameter you will see it is filled in with a GUID (however, the first character is set to NULL). Aside from that, you can find various lists of GUIDS discovered by other people.

EDIT: I found a few interesting links; it seems you can discover these GUIDs by searching the registry.

A forum posting about shell GUIDs

Control Panel GUIDs

How shell namespaces are installed

Luke
Running under Vista, compiling with VS2008, and having my exe marked as vista-aware (common controls 6.0 in the manifest), I do not get the GUID when I execute SHGetPathFromIDList() - rather I get the same thing as SHParseDisplayName() (i.e. a simple string path or folder name, but never a GUID)
Mordachai
You will only get the GUID for virtual objects; "physical" objects will still return the file path.
Luke
But that's the thing: CSIDL_DESKTOP is both a virtual and real folder. And I have as yet found no way to coax the OS into giving me back its GUID - only the real folder (which is not what I'm needing)
Mordachai
CSIDL_DESKTOP is the virtual folder and CSIDL_DESTOPDIRECTORY is the real folder. It seems you are correct in that the shell tries not to give you the GUID, though. It appears to work for some of the virtual folders; I got "::{20D04FE0-3AEA-1069-A2D8-08002B30309D}\::{21EC2020-3AEA-1069-A2DD-08002B30309D}" for Control Panel. I don't really know enough about the shell to help you any further.
Luke