This documentation is archived and is not being maintained.
Windows Confidential The Sad Story of the Shell Folders Key
Raymond Chen has worked in the Microsoft Windows division since 1992 and has seen a lot of things come and go. His Web site blogs.msdn.com/oldnewthing deals with the history of Windows and the dying art of Win32 programming.
© 2008 Microsoft Corporation and CMP Media, LLC. All rights reserved; reproduction in part or in whole without permission is prohibited.
It’s a little known fact that the Shell Folders key exists solely to permit four programs written in 1994 to continue running on the RTM version of Windows® 95.
The preliminary Windows 95 SDK documented a registry key called Shell Folders that programs could read to obtain the locations of special folders like the My Documents folder. The developers who received the Windows 95 M3 Beta followed the documentation and used that key.
In the meantime, the User Profiles team realized that a registry key was the wrong place to store this information. They had forgotten to take into account a feature of Windows NT® called roaming user profiles, in which a user profile can move around from place to place.
Thus was born the function SHGetSpecialFolderLocation. The documentation was updated to instruct developers to use this new function to obtain the location of special folders. To ease the transition, the old Shell Folders registry key was "temporarily" left around, but it was no longer the location where this information was kept. It was just a shadow of the "real" data that was stored elsewhere.
Windows 95 RTM shipped with this temporary key because there were still a small number of programs (let’s say four) that hadn’t finished converting to the new SHGetSpecialFolderLocation function. The support for this registry key was severely scaled back, however, so it was just barely good enough for those four programs. After all, this was just a backwards compatibility hack. All new programs should have, in theory at least, been using SHGetSpecialFolderLocation.
One crucial element of the Windows 95 launch excitement was that hundreds of programs would be available on opening day. If support for the key were dropped entirely, those four companies would have found themselves "locked out of the party." Infuriating the companies that give your platform life is not the way to conduct business.
You can guess what happened next.
Windows 95 was released and everybody and their brother wanted to write programs for it. But reading documentation is a lot of work. So when there’s some setting you want to retrieve, and you don’t want to read documentation, what do you do? You search the registry!
Now there were thousands of programs which didn’t call SHGetSpecialFolderLocation; they just went directly for the Shell Folders key. But developers didn’t realize that the support for Shell Folders was only intended as barely enough to keep those four original programs working.
For example, did you know that if you never open your Fonts folder, and if SHGetSpecialFolderLocation(CSIDL_FONTS) is never called, then there won’t be a Fonts entry in the Shell Folders key? Those entries are created only if somebody asks for them. No point setting up a compatibility hack until it is needed.
Of course, when you’re testing your program, you don’t reformat your hard disk, install Windows 95 clean, and then run your program. You just put your program on an existing machine and see what happens. Since at some point during all those months you opened your Font folder at least once, the Fonts entry exists and you are happy.
However, back in the application compatibility labs, your program gets a Fail grade. The lab reformats the computer before installing each application to make sure there is nothing left over from the previous program before installing the next one and the missing entry breaks your application.
And then the development team discovers that this program, when faced with a freshly formatted machine, never worked in the first place.
A philosophical question: If a program never worked in the first place, is it still a bug when it doesn’t work today?
I implore you to exercise restraint and not rely on the new User Shell Folders key. Just use the function SHGetFolderPath, which returns the path to whatever folder you want.
From script, you can obtain these paths as follows:
Set objShell = CreateObject("Shell.Application") Set objFolder = objShell.Namespace(5) ‘ ssfPERSONAL Wscript.Echo objFolder.Self.Path
The value 5 for ssfPERSONAL is documented in MSDN® under the topic ShellSpecialFolderConstants.
I strongly suspect that of the four programs for which the Shell Folders key was originally created, not a single one is still in existence today.