WORKSHOPS: OPERATING SYSTEMS

Stupid Shortcuts, Dumb Directories

by Bruce Robertson

"Stupid is as stupid does," Forrest Gump says. After my recent work reviewing Windows95, I've come to another conclusion: Shortcuts are stupid. So are any other pointers (like the World Wide Web's URLs) that involve hard-coding the name of the resource to which they point. The real shame, however, is that the directory services that resolve those names into addresses are stupid, too. Together, shortcuts and directories are dumb and dumber.

How Windows95 Shortcuts Work In Windows95, you can easily create a shortcut by dragging a folder with the right mouse button onto the desktop. Double-clicking on the shortcut opens up the target directory folder, application program or whatever the shortcut points to.

Of course, Microsoft didn't invent this. Apple's MacOS uses aliases to do the same thing. You instantiate one (local) object that points to another (remote) object. The shortcut is just the pointer to something else.

Windows95 shortcuts even work over the network, which is where the fun comes in, along with the stupidity. If I mapped a drive either locally or automatically via a login script, the path to the target for a folder on a network file server might be "\\hounwc02\users\bruce" or even "f:\users\bruce." When I'm out on the road and undocked, double-clicking on that shortcut opens the Windows95 Dial-Up Networking dialog box to get me reconnected to the remote resource.

That's pretty great for the user. It's not so great for the network administrator.

Shortcuts Can't Be Maintained The first problem with shortcuts is that the relationship is one way--you can only get from the pointer to the object. The object pointed to has no idea what's pointing to it. You can't change the object reference in the original shortcuts easily. There are ways to replace shortcut icons using MSBATCH.INF parameters during Windows95 setup, but you'd have to know exactly where that existing pointer was to do the registry manipulation required. Besides, who wants to rerun setup just to fix a shortcut? The shortcut pointers can't easily be maintained.

This one-way problem is particularly noticeable in the rapidly changing World Wide Web environment. Every time you go on the Web, you find another URL has been changed. Resources are moved to new machines, or put in different directories, or just deleted.

Unfortunately, the only constant in networking is change. In corporate environments, today's network file server for a user may need to be changed tomorrow (hopefully less often than the employee is forced to move offices between floors!). Windows95 shortcuts will also need to change over time. Who has to do the changing?

How Windows95 Shortcuts Don't Work Centralized "shortcuts" are very useful. In grand NetWare tradition, we often map a drive letter to a resource using the login script. For example, we load our Windows applications from what we call code servers: separate read-only file servers that have application programs but no data on them. We partition users across multiple code servers via a program run during the login script. To our users, it appears that all their applications load from the R: drive, but they actually load from multiple redundant servers. If we need to change the server that user is on, we can at least centrally change the mapping of the drive. The next time the user logs in, the new mapping takes effect, updated to point to the new location. The user didn't have to do anything.

Instal ling those applications on Windows95, however, creates shortcuts pointing to specific servers, and our login script load balancing no longer works. Windows95 automatically resolves the drive letter "name" into the underlying Universal Naming Convention (UNC) machine name address. "R:\APPS\WORD" becomes "\\HOUNWC02\APPS\WORD." So, after any move, when the user double-clicks on the shortcut, they get to the old location.

The shortcuts go to the server from which they originally installed. If that server goes down, the user can't reconnect and use the applications from the other server. We've lost our fault tolerance. Nor can we simply add a third code server without touching shortcuts on all our Windows95 desktops. Scaling for performance and high availability isn't simple or centralized.

Windows95 shortcuts can't be dynamically determined at run time. Centralized "shortcuts" like drive mapping are counterprogrammed by the individual client-side Windows95 shortcut that converted the drive letter to a UNC name. (See figure 1.) Network administrators are going to learn this the hard way. At least Microsoft could have left the drive letter in there and let network administrators get away with a little centralized indirection.

Windows 3.x's Program Manager wasn't this "smart." "R:" stayed "R:".

Shortcuts Need Good Directory Services The larger problem, however, is our device-centric network location thinking. Everyone still thinks of services being offered by machines. To get to the services, you have to know the machine name. UNCs and URLs are device-specific thinking. Folks, this approach won't scale.

Instead, we need to name resources independent of the server device on which they reside. A given service (yes, even file service: witness our duplicated code server approach) might, in fact, be provided by multiple instantiations on multiple servers. Then, at run time (at login or, better yet, at access time), that resource pointer (the name) could be evaluated to point at the server d evice most appropriate for load balancing or fault tolerance.

The problem isn't really stupid shortcuts. The problem is dumb directories.

Network operating systems haven't really thought about this enough, though Banyan has at least talked about not only replicated file services but automatic user load balancing across those replicas. The bigger fish--Novell and Microsoft--remain clueless, as do most network application vendors.

The key is the directory that holds the names. The Microsoft NT domain directory, for example, doesn't yet come close to having the level of attribute support that would even allow such a service-type naming approach.

The directory service should offer appropriate indirection as a generic service to any replicated object on the network. Why should we have to cobble together login script drive mappings and home-grown utilities? The client shouldn't need to know how many servers offer the service. The directory should tell the client where to go.

Microsoft's Systems Management Server (SMS) does offer an anemic approach to load balancing across multiple replicated file services. Unfortunately, the balancing is extremely unintelligent: Applications could load from a distant file server (multiple hops and slow links away) rather than from the server right on their own LAN. Besides, this capability should be part of the NOS rather than a separate client-oriented add-on.

If we had better directory services, we wouldn't need to worry about stupid Windows95 shortcuts on each client machine at all. Pressure your NOS vendors for appropriate functionality.

Don't take shortcuts. Don't be stupid.

Bruce Robertson can be reached at brobertson@nwc.com.

October 15, 1995