What is the difference between CSIDL_DESKTOP and CSIDL_DESKTOPDIRECTORY?

Among the various CSIDL values you can pass to functions like SHGetSpecialFolderLocation are CSIDL_DESKTOP and CSIDL_DESKTOPDIRECTORY. What's the difference between them?

The CSIDL_DESKTOP is the virtual folder that represents the desktop. The contents of this virtual folder is what gets displayed on top of your wallpaper.

The CSIDL_DESKTOP virtual folder is populated from various locations, some of them virtual, and some of them physical. The CSIDL_DESKTOPDIRECTORY special folder is a physical folder that contains the files that you think of as on your desktop. These are the files that you've saved to your desktop, files that you've dragged to your desktop, that sort of thing. Some files on the desktop come from CSIDL_COMMON_DESKTOPDIRECTORY, which is the shared desktop. Files in the shared desktop directory are visible to all users.

What does this mean for you, the programmer? (Well, assuming you are still using CSIDL values and haven't switched over to the new FOLDERID model.)

Programs shouldn't care about CSIDL_DESKTOPDIRECTORY; they should just operate on CSIDL_DESKTOP, because that's what the user sees. If you want to generate an ITEMIDLIST for a file on the desktop, use the CSIDL_DESKTOP folder. The physical folder behind the desktop can change (for example, due to roaming user profiles), but the logical location on the desktop remains fixed. If you had generated the ITEMIDLIST based on CSIDL_DESKTOPDIRECTORY, then the experience for your users will be much more annoying: They will get file not found errors if the user profile roams to another machine (since the directory has changed). If they perform a Save As operation, the default save location will be some deep file system path instead of just being the desktop.

The CSIDL_DESKTOPDIRECTORY is the plumbing behind the scenes. Don't show it to the user; it's ugly.

Comments (10)
  1. John says:

    I am not very familiar with programming with the shell, so forgive me if my questions are dumb.  It seems like ITEMIDLISTs are fairly useless without IShellFolder.  The only top-level method to obtain an IShellFolder is via SHGetDesktopFolder, which returns the IShellFolder that CSIDL_DESKTOP represents.  So why would you ever need an ITEMIDLIST that represents the desktop if the only way to make use of that ITEMIDLIST is to obtain an IShellFolder which also represents the desktop?

  2. Ivo says:

    There seems to be some confusion related to these on Vista.

    I’ve been using the Deskmenu powertool since Win95 and it works great. On Vista however, half of the time it shows only portion of the desktop items (I’m assuming the DESKTOPDIRECTORY portion). If I click again it shows the complete list.

    I may be way off base here, any idea what’s going on?

  3. D. Garlans says:

    This virtualization becomes pretty obvious when on my Windows 7 desktop, I have two "desktop.ini" icons right next to each other :) obviously a fluke in the system, but it’s pretty funny to see.

    Windows 7 still rocks though!

  4. Worf says:

    Actually, it happens in Vista too. If you configure Explorer to show all files, you get two desktop.ini files on your desktop…

  5. Drak says:

    @D. Garlans:

    How is this a fluke? As Raymond said, the desktop is a collection of items collected from multiple places. Both desktop.ini files come from a different location, so it has to show both of them. Would you rather it ate up one of them, or perhaps your CoolGame.exe which you also have in both locations?

  6. Generic Development Device says:


    It sort of breaks the desktop abstraction, doesn’t it?

    The user will be surprised to see two files with the same name.  You can argue that the implementation makes sense (at least, to a developer), but ideally the system shouldn’t surprise the user in the first place.

  7. Gavin Greig says:

    @Generic Development Device

    The desktop.ini files only show up if you’ve tinkered with file visibility in the Folder Options, in which case you as the user are implicitly saying "Yes, I can cope with seeing stuff the OS designers usually want to hide from me." The system won’t surprise the average user because the average user won’t have changed the visibility of those files in the first place.

  8. acq says:

    > The system won’t surprise the average user

    But it does, maybe not directly the way you discussed, but the feature leads to confusing UI! I don’t use Vista or 7, but my former girlfriend was puzzled to have the file in one dialog and not have it in Explorer (or something like that). See one more exact description on:

    Mark’s Blog “The Case of the Phantom Desktop Files”


    I’d call that bad implementation. Anybody knows if it’s fixed in Win7?

    [That’s why “Hide protected operating system files (recommended)” is on by default and turning it off requires you not only to go to something called “Advanced settings” but also to click YES in response to a scary confirmation dialog. Your former girlfriend said “Do something that would confuse most people” and then got confused. What would be the correct implementation, adding a second confirmation dialog? (You can’t just say that something is bad; you have to say what would be better.) -Raymond]
  9. acq says:

    Raymond, I’m thankful to you for your time invested in this blog. I still believe you improve MSFT image much more than most of their advertising campaigns.

    > That’s why “Hide protected operating system files (recommended)” is on by default

    I don’t think my former girlfriend ever turned on “show hidden files.” If I remember correctly just reading the e-mail and doing simple drag and drop of the attachment from Windows Mail to the desktop makes the file “disappear” or something like that on Vista. I’m still on XP and not experienced enough in Vista/Win7 subtleties.

    > You can’t just say that something is bad; you have to say what would be better.

    I’d say, either showing the user the dropped file or changing the Mail/whatever not to allow the “drop and disappear” action. But I’m not relevant, I don’t claim I know enough as I don’t use Vista and there are people actually programming these features who should have the right answer. I just mentioned that at least some inconsistencies resulting from having some virtual folders mapping to “the desktop” are certainly visible to “normal” users and asked if anybody knows if Windows 7 somehow fixed the problem.

    I read your blog as I hope to learn something significant for me as a Win32 programmer, even if I’m at the moment still having an older, XP/2003 target.

    [Then the original bug is that some program removed the hidden attribute from desktop.ini. Dropping a file from Windows Mail auto-repaired the desktop.ini file and re-marked it as hidden (like it should have been all along). Maybe you’re saying that Windows Mail shouldn’t try to fix data corruption? -Raymond]
  10. BC says:

    Maybe this explains why I see duplicate filenames on the Desktop on my kids account on XP.  Somehow a file or link was created in the "virtual desktop", and then someone copied the same thing to the desktop directory. Thanks!!

Comments are closed.