Why Windows Exploder Stinks

Week of February 28, 2000

A tribute to a landmark in computer science.

(Note: all of the following is based on Windows Exploder, the original culprit, rather than its successor Internet Exploder, but it applies in spades to the latter anyway, which brings the art of bad system design to a new and heretofore unknown nadir, unbeatable by even the Windows Exploder team.)

Extensions are gone - file types have superseded

Developers live by extensions. They have C files and DEF files and DLL files and DSP files and DSW files and EXE files and H files and LIB files and OBJ files and RC files and RES files and VER files - and all these files can have the same root name and only be distinguished by their extension. Using pretty file type names, even if they are visible, does not help much; instead it befuddles, confuses and obfuscates - and it sorts the files wrong too. Developers are used to seeing ASM files sorted first, then C files, then project files, then include files, then resource script files, and so on. And as if the esthetic experience were not painful enough, Exploder will list all sorts of important files, such as source object, resource object, and the like, as the innocuous 'Intermediate File', which is about as helpful as anything else in this moronizing 'new look and feel' environment.

This carries over to so-called 'shell file operations'. Suddenly a box comes on screen saying Exploder is about to remove a file (or directory, you don't know) called 'MyApp'. 'MyApp' - what? Is it an EXE file, a directory, a Make file, a project file, a workspace file, a source file, an include file - what the heck is it? All this pampering of the clueless has, for the developer, gone too far - and it's even confusing for the clueless.

Exploder cannot see real file names anyway. The only place the actual, physical as in written on disk physical, name of the file is stored is in the shell namespace. And this name is almost never used, never displayed. The wonderful GUI freaks behind Windows Exploder assume that a file name with all upper case letters is a 'DOS' file name and that the REAL name is a 'titled' (i.e. first letter only capitalized) variant of this. Any file or directory which is explicitly named with all upper case letters will be displayed incorrectly by Windows Exploder.

It takes a lot more crunching to sort according to extension; the 'architects' behind Windows Exploder would not be able to offer even the 'performance' of today if they attempted it; but developers need files sorted according to extension, and this most basic of options is therefore painfully lacking.

The shell is HEAVY

Developers need all the CPU, RAM and disk they can get for the task at hand. If other people want to use resource hogs like Windows Exploder, let them, but developers must have basic tools. Developers are supposed to understand what a file system hierarchy is (Bill Gates contends ordinary end users never will). Developers need to know, need to see, everything. Navigating through a file system with Windows Exploder is like walking through life blindfolded or, even worse, with dirty rose colored glasses - apparently manufactured in the greater Seattle area.

More than being a hindrance than a help, Windows Exploder crushes the system under an onerous weight. Not only is the C++/OLE code lugubrious, the mere idea of disregarding the underlying file system out of this world, but the preponderance of icons and graphics all over the place is the perfect fundament for all that follows: dwindling RAM, depleted system resources, and of course that most wonderful of phenomena, recognized by Microsoft in an official knowledge base article, the desktop turning to mush. The most basic tool in their box of operating system applets is hopelessly bugged: sooner or later it's going to screw up your desktop. That is a simple fact. There is no cure. It is inevitable. And all Microsoft has to save you from this mess is a rather clumsy work around.

The cause of this embarrassing misery is not Exploder per se - it's the very design of Exploder, a design that won't hold up to scrutiny in theory and can never hope to work satisfactorily well in practice. Developers cannot be expected to have to deal with such shoddy operating system fundaments as this all the time. By all accounts, David Cutler, when he first saw the monstrosity of Windows Exploder, put his hands up in the air and concluded that the days of his sojourn in Redmond were numbered.

The very concept of a namespace chock full of icons replacing the file system of the real world is so unwieldy, so unrealistic, that the system has to rely on a special cache of icons to make it work fast enough. A few years back Microsoft published a tutorial on how Exploder was written. The sample application was called EnumDesk. When EnumDesk got to the SYSTEM/system32 directory, its window froze for half a minute: it didn't use the ShellIconCache, and so it was on a hopeless hunt for icons for all the files it needed to list. The listview window got ugly, the hour glass cursor was etched into the phosphor.

Not many people realize how much silly data processing and disk access is necessary for Windows Exploder to simply list a directory. One would think that finding files on disk and then going right ahead and listing them would be enough. Oh no, not for Redmond. Redmond's brand of planned obsolescence is not an art concerned with improving products, but making them look new and flashier - and improvement be damned: 'if things get too slow, just throw some more hardware at it' (yes, this is an authentic Redmond quote - meditate on it for a while).

For every file found, Windows Exploder must access the Registry. Some of the information needed might be cached, some might not, but Registry calls are still disk accesses - but slower. And Windows Exploder has to access the Registry - i.e. go to disk - to find out the following:

1. Given a file extension, look it up under HKCR and find out its corresponding file type.
2. Find the file type's Registry key and navigate to its DefaultIcon subkey.
3. If the DefaultIcon subkey is found, get the path and index found there.
4. If the DefaultIcon subkey is not found, there's even more work to do: navigate down through the subkeys and see if any command lines do anything with the file type. If they do, parse the path to an executable out of there and assume index 0.
5. If the index is zero or positive, it is an absolute index in the file. If the index is negative, it is a numeric identifier for an icon in the file.
6. Find the file, open it, read its headers, and find out where its resource section begins.
7. Navigate to the resource section, read the resource headers, and find the file offset for the icon to be used. If the index was zero or positive, count out the offset by index. If the index was negative, go through each icon directory, one by one, until the right number is found.
8. Read in this icon from disk.
9. Study the size and palette of the icon and if necessary adjust the palette and stretch the icon to the required size.
10. Give the icon to the listview, populate the entry with other data (which is just as inaccessible), and move on: time, finally, to work on the second file.

And so on. For a directory such as SYSTEM/system32, this can of course take a long time. The thirty seconds required by EnumDesk is not unreasonable and cannot be blamed on bloat in Redmond code. No number of code tweaks can improve on certain disaster.

And the only way Windows Exploder can make this work so users don't scream down their telephones at Microsoft support is by 'cheating'. A basic operating system concept is so weak it can't stand on its own two feet.

Most of the above is admittedly accomplished through system or shell calls, but that's not the point. The point is that it's being done: all these disk accesses are taking place. And any caching used can help only temporarily - sooner or later it has to be down to disk and available for any other client that wants valid data from the Registry. Microsoft Windows has always been an extremely disk intensive 'operating system', but this is ridiculous.

You know that sound your disks make, wheezing, thrashing, sneezing, just after you log on? That sound when you invoke one of the shell dialogs such as File Delete or File Properties? Ever wondered what that is? Well now you know: it's Windows Exploder, either constructing its unreal namespace on the fly from the physical reality on disk, or re-creating or adding to the bloat file ShellIconCache.

Other operating systems handle the business of representative images a bit differently, and depending upon exactly which method is used, the concept of individual icons representing individual files, including executables, may or may not work. But on Windows, where the system is so indirect and requires reading through and jumping helter-skelter to so much data, through so many files, for every file to be listed, the concept is outright folly - and users everywhere are paying for this folly each and every day.

What is 'document centric' anyway?

The new Windows Exploder shell is supposed to be 'document centric'. Initially Microsoft called it 'object oriented', but IBM put up such a stink (and IBM was right) that Microsoft retracted rather than face the bad publicity. They called it 'document centric' instead. What does this mean?

For starters, MDI is dead. This technology breakthrough, supposedly an idea first born in the IBM camp for Windows 3.0, places the program in the center and the documents around it as children. Watching how the Word team jumps through hoops trying to keep up multiple documents but not let its application appear to be running MDI is great entertainment. Watching Microsoft's Developer Studio not even try is outright disheartening.

Caption bars are supposed to list the file name first now, and the program name after, a dash in between. It was the other way around before of course. But caption bars are not supposed to show complete paths either. And caption bars should always show the 'pretty' or 'long file name' variant, not the 'DOS' name.

But Microsoft's own technology has not kept up with these 'revolutionary' ideas. Go to any associated file with a real long file name in Exploder and double click on it. Chances are you'll get a mangled name up in the caption bar of the program that opens the file. The reason? The Windows Exploder shell still doesn't pass the 'pretty' name to programs.

Mangled file names are a walking disaster just waiting to occur. Either you recognize the one or the other, but not both, and then you should be done with it. Let's take an example:

• Simon decides it's time to clean a partition on his disk. He zips up everything on the partition, moves the zip file to another partition, and then cleans out the partition, re-formatting it. Thereafter he upzips the zip file back into the partition and thinks he's ready to run again. But he's not. Nothing on his partition seems to work.

• During the first life of that partition Simon happened to install two versions of the same program from Acme Enterprises. To keep them separate, he named their directories 'Acme Enterprises Version 1' and 'Acme Enterprises Version 2'. After a while Simon realized he didn't have to keep the old version 1 around anymore and deleted its directory.

• Simon is just a lowly end user - the kind of user Bill Gates says has no brains. Simon has brains all right, maybe more than Bill Gates & Co. collectively, but how could Simon know what Microsoft has in store for him?

• The first time around, his directory names were mangled to 'ACMEEN~1' and 'ACMEEN~2' respectively. But when Simon unzipped the zip file back into his partition, 'Acme Enterprises Version 1' was no more, and so 'Acme Enterprises Version 2' got the name 'ACMEEN~1' instead (try it yourself, you'll see).

• What Simon never knew was that this fantastic 32-bit document centric long file name 'new look and feel' Windows Exploder technology he'd heard so much about was not being used here. All throughout his Registry Microsoft had chucked gobs of references to 'ACMEEN~2' - for their fabulous OLE technology, for all the CLSIDs Simon wished he could take out of there, for all the fugly Interface references, and more. Now when Simon re-installed everything on the re-formatted partition, all this stuff pointed wrong. Simon was up the Redmond creek without a paddle.

Think this is bad enough? You ain't seen nuthin' yet. How's about finding out that all this junk follows you around all the time, sucking up your precious RAM, and still can't do it right? If you start moving registered CLSID and Interface files around on an active partition, Windows Exploder will make the Registry dance right along with you. Just think how much memory Windows Exploder needs to try and carry this one off. And then ask yourself the next embarrassing question: if Windows Exploder does try to do all this, why in tarnation can't it try to properly keep track of shortcuts too?

For watching Windows Exploder ruin shortcuts is one of the great Windows annoyances of all time. This bastardized version of the UNIX link, perhaps the most paraplegic perversion of it imaginable, will pre-empt your own wishes at any time without telling you and simply re-write all those LNK files cluttering your disk. You won't even be told. Suddenly when you click a link some weird program will be up there, doing goodness knows what. If you've seen it before you might be able to track the error down quite quickly. If you have not, you're in for a real treat of a Redmond sponsored panic attack.

CLSIDs, HKCR, and Interfaces are machine-dependent

What does this mean? CLSIDs, HKCR and Interfaces are in theory supposed to help you. They're supposed to give you this miracle of 'document centricity' that Windows Exploder has. But do they? Only if you're the only user on the machine. For while so much else is based on the 'current user', this stuff is not.

Say Amy and Jane share the same machine at work. And Amy runs Winword but Jane does not. When Amy logs on she uses her Winword network installation; when Jane logs on she uses the local copy of WordPad.

Both Amy and Jane regularly edit RTF documents. Initially when they bought the computer, Windows Exploder in its wisdom set RTF files up to be handled by WordPad. But when Amy started using Word, the install changed this association and suddenly RTF files were opened by Word instead.

So when Jane logs on and double clicks an RTF file, she gets a diagnostic telling her some application or path cannot be found. At the very best. If things really get screwed up, Exploder can go off crunching to find another path for her shortcut and come up with Adobe Illustrator or who knows what. Good old Exploder.

When Jane finally figures out what's going on, she hits 'File Types' in Exploder, sees that RTF files are now associated with Adobe Illustrator, has the intestinal fortitude and general wherewithal to ferret out WordPad, and makes WordPad again the program that opens RTF files. She works a while, pushes the earlier misery caused by the morons at Microsoft to the back of her mind, logs off and goes home.

The next day Amy comes in, turns on the machine, logs on, and double clicks an RTF file. She's expecting Word to open the file, but WordPad opens it instead. Amy is in a panic. She assumes something has gone wrong with the install, runs around the office like a chicken without a head, finds the CD with Word, finds the sysadmin, and asks him to help her re-install Word. After about half an hour she's ready to run. She too works long and hard, pushes the Microsoft trick or treat surprise to the back of her mind, turns off the machine, and goes home.

The next day Jane comes in and the whole circus starts all over again. And it never ends either.

Windows is meant to be used by any number of users on the same machine. That's why we have the current user key in the Registry. That's why we have user-specific logons with passwords. That's why we have user managers on local machines running NT. Applications that are installed - especially Microsoft's own - are licensed to users and not machines. All the About boxes specify the user and not a machine. Yet the settings needed to make the applications work correctly for any given user are architecturally placed in the wrong area of the Registry. Major blooper. They pertain to an entire local machine - and not to any specific current user.

The Registry began back with Windows 3, with something then called the 'Registration Database' (curiously, the tools used to edit this Registration Database could 'save' changes after a session or not as the user wished, but today's supposedly more advanced tools lack this option). Back then REG files claimed we were at version 1 and invariably put HKCR at the top.

No one forced Microsoft to later place this key under the auspices of the local machine instead of the current user; but by so doing, Microsoft treated poor end users to another in a long succession of monstrous unfixable screw-ups.

Object re-use and the OS slowing down

Bjarne Stroustrup, who needed the C programming language to bail him out at Bell Labs so he didn't look like a complete fool, has since gone on to castigate the language that saved his butt, claiming, among other things, that his own love child can offer extensive object re-use. As anyone in the industry is aware, this is a joke, just as Bjarne is. NeXTSTEP, using the far more civilized Objective-C which does not castigate or interfere with the C programming language at all, does accomplish authentic object re-use, and does it brilliantly: you don't even have to re-compile these objects, you simply drag them, ready made, into projects, and they work 'just like that'. But as usual, Microsoft is ages - light years - behind the times.

It wasn't Microsoft's idea (nothing ever is), but Microsoft's abuse of CLSIDs ultimately brings every decent install of one of their operating systems to a grinding halt.

Every doofus wannabe or even major player application in the world today, invariably designed by some OO bonehead, is going to clutter your Registry full of wimpy CLSIDs or Interfaces on install. Most often this junk is placed there before you even click on the button agreeing to the EULA. If you abort the install at that point it's going to stay around too, because the guys who built the install are just as much boneheads as the guys who designed the application. And if you've aborted the install, you won't have any uninstall program around which might or might not clean that junk out. You're stuck with it - you just got the 'OO shaft'.

All of these components are supposed to serve you well, but most Registries are full of OO junk that's referencing files that aren't even there on your machine and just slowing your system down. And wonderful Windows Exploder keeps all this stuff close by all the time, cluttering your RAM as well, and with everything you do it checks the megabytes of CLSIDs and Interfaces resident there to see if what you're doing is all right and to make its own adjustments on the fly accordingly. If you move a registered component, Exploder will change its Registry references straight away.

This takes a lot of CPU - and a lot of RAM too. And this goes on continually, from the moment you log on and start that first fateful Win32 thread, until the moment you've again had it with Microsoft and do your power down. It never leaves you alone.

The sluggishness of any given local machine is directly proportional to the amount of junk piled up in your Registry, in particular under HKCR. Not only would you save precious megabytes of disk space if you could get this trash out, your system would run significantly faster too.

Worst of all, most of this stuff is basically useless anyway - it's put there by lame Delphi and VB programmers who can't spell 'bit' and who are probably going to overwrite your precious system files before adding a few megabytes to your file system with choice files of their own. Some of these files - very often OCX's - are so paraplegic it's funny. Some of them are used for such trivial tasks as centering text. But if it's lame, or if it can be done even lamer than now, and with more damage and destruction to your system as a result, count on the Delphi and VB people to do it - and Microsoft to support them all the way. Like minds, as the saying goes.

Count on it, gauge it, calculate it, watch it happen before your eyes - and basically be helpless to do anything about it: the railed concept of object re-use, attractive in its abstract form and on some non-Redmond platforms, but fugly beyond description in its Microsoft bastardization, is going to gradually bring your precious computer grinding to a halt. When an innocent install of Winword 2K adds three megabytes (3MB) of HKCR, CLSID, and Interface junk to your Registry - you know your machine has had it.