Windows ConfidentialWhy are Shortcuts Files?

Raymond Chen

Shortcuts are files. Many people, however, think that shortcuts should have been handled differently. People have suggested that they should have been implemented as hard links, symbolic links, object tracking, or any number of other possibilities. So why was it decided that they would be files? To understand this, remember what the working constraints were back 10 or 12 years ago:

1. The mechanism had to run on a machine with only 4MB of RAM.
2. Shortcuts had to be supported on all file systems—especially FAT, since that was the only file system Windows® 95 supported natively. The mechanism also had to work on Novell, Lantastic, Banyan, LAN Manager, Samba, and other networking systems without requiring a new networking protocol (since that would have required network vendors to release new drivers and people to install them on their file servers).
3. It had to be possible to copy a shortcut to a floppy disk or send it to a colleague as an e-mail attachment.
4. Backup programs had to be able to back up and restore shortcuts.
5. A shortcut had to contain information that allowed a user to customize its appearance and other properties, such as its hotkey.
6. It had to be possible to create shortcuts to objects on different volumes, across file systems, as well as to items that weren't files, such as control panel programs and dial-up networking connections.

The first constraint is pretty straightforward. Basically, it says that we had to keep it simple. Anything fancy would have taxed a poor machine with only 4MB of memory.

Constraints two and three required that shortcuts be plain files rather than special file system objects. Once something has been sent as an e-mail attachment, you've pretty much lost everything other than a plain octet-stream.

Permitting existing backup programs to operate on shortcuts was an argument against inventing a new type of file system object, because existing backup programs wouldn't know how to deal with these new files. Therefore, the inability of backup programs to back up shortcuts wasn't a deal-breaker, but it certainly biased the decision in favor of using plain files. Even the introduction of long file names on FAT drives didn't break backup programs. Backup utilities could still back up the short names; and Windows 95 included the LFNBK utility that allowed you to back up and restore the long names manually.

The fifth requirement could have been satisfied by NTFS alternate streams, except for the fact that Windows 95 didn't support NTFS. (Even if it did, this would have required people to reformat their drives as NTFS in order to upgrade to Windows 95.) In the absence of alternate streams, the information must be stored elsewhere in Windows in order to present the rich user interface we desired.

Finally, the need to create shortcuts that span volumes and point to things that aren't even files meant that shortcuts could not be purely a file system feature, since the target of the shortcut might live outside the file system.

Given these constraints, the most reasonable option was for a shortcut to be a file that contained the necessary information about what it pointed to and any supplementary information, such as its icon and hotkey. This design has proven very flexible. Subsequent versions of Windows have added more functionality. For example, a shortcut can now represent a program that hasn't even been installed yet, but one which your domain administrator has made available. Or you can have shortcuts to files whose paths are relative to environment variables.

Some people have suggested that shortcuts could have operated like the Apple Macintosh Alias Manager. Indeed, on Windows NT®, shortcuts do operate similarly, and take the concept several steps further. If you create a shortcut to an object on an NTFS volume, the object's unique NTFS identifier is recorded in the shortcut and the Distributed Link Tracking Service is used to hunt down that object later on. The Distributed Link Tracking Service can locate the object in relatively straightforward cases where it has been renamed or moved to another directory on the same volume, and it can even track files in more complex scenarios when they have moved from one computer to another—even when a hard drive has been taken out of one computer and installed into another! Let's see you try that with a symbolic link.

Raymond Chen's Web site, The Old New Thing, deals with Windows history and Win32 programming. He still has trouble telling which of the sprouting things in his garden are weeds.

© 2008 Microsoft Corporation and CMP Media, LLC. All rights reserved; reproduction in part or in whole without permission is prohibited.