Program files, on the other hand, are scary. These are the nuts and bolts that make the computer go: data files, DLLs, configuration files, helper processes, and other things that users shouldn’t be messing with.

This distinction was preserved in the user interface. Programs appeared on the Start menu. This offered a friendly, inviting place where you could see all the programs on your computer and choose one to run. Program files, on the other hand, were squirreled away in a directory with a scary name that discouraged exploration. A directory named Programs would be an attractive nuisance. A user who wanted to run a program might open My Computer, see a directory named Programs, and wander into it, unwittingly entering a frightening world of DLLs and executables with baffling names. If this user were lucky, she might discover that this thing called WinWord.exe launches Microsoft® Word. She might even conclude that, in order to run Word, she needs to open My Computer, click her C drive, click Programs, go into the Microsoft Office directory, then to Office11, and then in the list of 200 files (all of which have nonsense names) find the file called WinWord.exe and double-click it. This is so complicated. Why can’t Microsoft make a computer that’s easy to use?

The Documents and Settings directory arrived on the scene in Windows 2000. Windows NT® kept user profiles in a subdirectory of the Windows directory. This turned out to be poor planning, because it made it difficult to adjust the access control list (ACL) on the Windows directory without accidentally messing up all the user profiles. Moving the user profiles out of the Windows directory solved that problem.

But why "Documents and Settings"? The original name for the directory was actually "Documents & Settings". That ampersand caused a good deal of application compatibility problems. Programs misinterpreted the ampersand as a menu accelerator and ended up displaying the directory name as "Documents _Settings".

In retrospect, the name "Documents and Settings" was a poor choice. Although this new directory met the immediate need of moving profiles out of the Windows directory and it had a highly descriptive name, the spaces didn’t make the directory name particularly easy to type, and its whopping twenty-two character length consumed nearly ten percent of the MAX_PATH characters available for file names.

In Windows Vista™, the name of the user profile directory is simply "Users." It gets the point across, it’s easy to type, it doesn’t contain spaces, and it’s short. Of course, programs should continue to use functions such as SHGetFolderPath to obtain the locations of these special directories.

Another security change in Windows Vista is that the All Users profile has been moved out of the profiles directory and into the root of the drive (though a symbolic link has been left in the profiles directory for compatibility purposes). Some administrators share out the root of the user profiles directory as a cheap way to allow users to access their user profile from another machine. The Application Data directory inside the All Users profile can be written to by any user. This has two serious consequences.

Anybody who has access to the share can create files in the All Users\Application Data directory, thereby consuming disk space without even having an account on the machine. Suddenly, your server has become a warez server—illegally hosting cracked software and bootleg movies—without your even realizing it. And when you go through the audit logs, all you see is that the files were uploaded by "Anonymous" or "Guest."

A second (and possibly more dangerous) consequence of sharing out the profile root is that some applications may create a subdirectory of All Users\Application Data and override the default security settings on that directory with a much less secure ACL, allowing any local user to modify global configuration settings or, worse, modify executable code. Sharing out the All Users profile turns that local vulnerability into a remote one, raising the security stakes considerably. When Shakespeare wrote "What’s in a name?" he probably didn’t have security and software compatibility in mind. But then he wasn’t managing a Windows environment.

(I’d like to give many thanks to Eric Flo, Piero Sierra, and Chris Guzak for their historical assistance.)