learn.microsoft.com Open in urlscan Pro
2a02:26f0:1700:1b1::3544  Public Scan

Form analysis
0 forms found in the DOM

Text Content

Skip to main content


This browser is no longer supported.

Upgrade to Microsoft Edge to take advantage of the latest features, security
updates, and technical support.

Download Microsoft Edge More info about Internet Explorer and Microsoft Edge

Table of contents Exit focus mode

Read in English Save
Table of contents Read in English Save Print

Twitter LinkedIn Facebook Email
Table of contents
 * Article
 * 09/08/2016




IN THIS ARTICLE

Windows ConfidentialThe Sad Story of the Shell Folders Key

Raymond Chen

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.

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.




--------------------------------------------------------------------------------


ADDITIONAL RESOURCES




Theme
 * Light
 * Dark
 * High contrast

 * 
 * Previous Versions
 * Blog
 * Contribute
 * Privacy
 * Terms of Use
 * Trademarks
 * © Microsoft 2023


ADDITIONAL RESOURCES






IN THIS ARTICLE



Theme
 * Light
 * Dark
 * High contrast

 * 
 * Previous Versions
 * Blog
 * Contribute
 * Privacy
 * Terms of Use
 * Trademarks
 * © Microsoft 2023