The Explorer Replacements™

You thought it was bad enough with the Notepad Replacements™? Ha!

Get It Try It

There are probably still a few people who actually literally navigate Windows file systems. Even high paid PC repairmen today are more likely to scoot straight for 'Add/Remove Programs' if something goes wrong. And many a user won't even know there's something called 'Explorer' - thinking it's all INTERNET Explorer.

But there are probably a few real users left.

Or maybe it's the First Law of Migration: the more alert and intelligent always move first. Ten years ago when the web was nascent everyone knew how to navigate a file system and everyone used Windows. Now that 'everyone' has expanded to include people who weren't sufficiently fascinated by command lines and graphical overviews of file systems. All the while those who were have now moved onto better things.

Such as Unix™.

It all started in 1990 when as history will have it Microsoft surprised everyone by suddenly making a success out of their all time most abortive product. There are of course tangible reasons for this which won't be discussed here. So Microsoft started breaking off their partnership with IBM and calling all their programmers home to begin the super rewrite for Windows 3.1.

For word said Windows 3.1 was a total rewrite of 3.0. It also said Winfile itself had as many lines of code as the entire first release of Unix - 13,500. Looking at the program you could believe it.

Winfile was the Microsoft Windows file manager. It wasn't the first thing that greeted an uninitiated user but it could be. It was at any rate the first thing that greeted a professional user.

Microsoft didn't have any fancy controls back then. They had the list box and that was it. Not the list view - the list box. Box. You could put a single character string in at any row. No columns. Just a single character string. If you wanted to make it look like you had columns you had to use tabs and hope for the best with your font.

And on top of this in Winfile Microsoft built the tree view on the left and the list view on the right. They didn't make new controls - they worked with the list box and wrote lots of code. Lots.

And it worked. And it worked well. And it alone was worth the price of admission to Windows. With Susan Kare's cute little yellow icon it took a prominent place on the Windows desktop along with Program Manager.

Program Manager (PROGMAN.EXE) was set as the default shell but you could change that. Progman had a MDI (multidocument interface) 'frame' with child windows inside. Trouble was they weren't hierarchical. The MDI doesn't think about hierarchy. You could make your own program groups but you couldn't subdivide recursively. Best to stick with Winfile and let the file system be your hierarchy. That's what file system hierarchies are for.

As soon as your shell exited your Windows session exited too. If you set Winfile to be your shell and then exited you'd get the 'are you sure' dialog about ending your Windows session. Answer 'yes' and you were back to DOS again.

Winfile was sophisticated to say the very least. Few people realised how many different ways there were to work with the program. Out of the box it was pretty difficult to use - you needed to spend a good half hour getting everything right again. But when was right it worked like nothing else.

Winfile could completely ignore the mouse if you wanted. Everything you wanted to do with the mouse you could do with the keyboard. Everything. You could even do multiple group selects - separated groups of files in the list view. You used shift+F8 to put the program in a special 'selection mode' and then you could use arrow down and arrow up to navigate through the file list and the space bar to toggle selection. And when you were through you hit shift+F8 again to exit selection mode.

And so forth.

Winfile was a 16-bit program and it didn't understand long file names or file names with spaces in them or Microsoft's 'VFAT'. It was pretty lost when Windows 95 came out. The Windows shell converted long file names to 'tilded' names ('~') and it wasn't too pretty.

At the same time Cutler's NT team took the original code to Winfile and rewrote it in 32-bit code. This version handled long file names and all the rest. For those who had to get a job done and weren't left sitting at a console to keep out of the way of others it was indispensable.

Microsoft introduced a new controls library called 'common controls'. The controls were called 'common' because they were shared by several applications - notably Explorer and Print Manager. The controls were initially two in number: a toolbar engine and a status bar engine. As time went on a dedicated tree view and a dedicated list view were added; after a while the number grew considerably.

The tree view was the accumulation of the work done on the left pane of Winfile; the list view the corresponding right pane. After several prototypes in experimental applications the controls were put into the Windows 95 common controls library - to be used by Explorer.

But although Explorer added the new tree view and list view - and thereby could be said to look a little 'fancier' - it also did other things the pros weren't too happy about.

The Windows 95 'GUI' introduced a concept ne'er before seen (and hopefully ne'er seen again) known as the 'shell namespace'.

File management went topsy turvy.

The Shell Namespace

The shell namespace: whoever thought of this idea should be given a prize. Or at least a sign of distinction. It would be namely so good to know who thought of it. So computer science knew who to blame.

The shell namespace: there are so many things in play here all at once.

Namespace creation. The shell namespace has to be created at login time. It doesn't exist on disk. The system has to scurry around and see what's available - not only on disk but as regards any number of system services.

Namespace navigation. The shell namespace includes the attached file systems but they're only a part of it. The conscientious developer has no way of knowing who is who and what is what. It all melds into a single incongruous monster whole.

The bird that eats its own tail. The crowning achievement was deciding this namespace would have a root node equal to something called the 'desktop'. [The 'desktop window' is slightly different: it too resides at the top of a hierarchy but they're otherwise unrelated. Entities and tasks get easily muddled.] The desktop also appears farther down the hierarchy. And it isn't the only time one and the same node appears at different levels in the same namespace.

For those familiar with Unix: this is tantamount to having a recursive tangle of hard links on directories - which is one of the reasons they're not normally allowed anymore.

Explorer itself is another beauty. There's nothing wrong with amalgamating the hard work of the Winfile team but the bloody thing is so slow and unproductive.

Besides: Explorer isn't the real file manager anyway. It's only the pretty face. As with Internet Explorer which is the pretty face on the real web browser MSHTML.DLL Explorer is the pretty face on the real namespace manager SHELL32.DLL.

Now onto why Explorer sucks. Because it does. Hard.

Explorer can't refresh. Try digging down in a big directory sometime - scrolling all the way down in a 'detail view' - and changing the specs on a file. Try refreshing when you're done. You're toast. Not only is your selection of the file gone - you're also scrolled back to the top again.

The Explorer team most likely decided refreshes were too difficult to implement. Each time you hit 'refresh' Explorer instead creates a new list view behind the one you see. When it's ready Explorer destroys the frontmost one and the new one comes into view.

[This is a technique they've been using for ages to toggle word wrap in their text editors.]

If you rename a file you'd expect it to be sorted correctly; forget it: Explorer can't do sorts like that on the fly. You have to hit 'refresh' to get the file sorted properly again. And you now know what happens when you hit 'refresh'.

Even if Microsoft wanted to they'd be hard put to enable fast sorts anyway. The list view's built in search function is linear and thus unforgivably slow. It simply can't do the job.

Those pretty type names. Rather than rely on file extensions to distinguish files Windows 95 wants to use 'pretty names'. Instead of 'EXE' to single out a program file you stuff in something like 'Program File'. Anything to be more like the repulsive MacOS. And this works for the terminally stupid. They don't know much and are going to learn even less. But for the pro?

Things get even worse when you realise the extensions are hidden by default. [Time for a Love Bug, anyone?] And whilst it's guaranteed you can't have two files in the same directory with the same name you can have as many files as you want with the same 'first name' and the same icon. Watching inept Microsoft developers grapple with this in project directories is a mixture of comedy and tragedy, tears and delight.

Those pretty little icons. Winfile didn't worry much about icons. It had one for regular files and one for directories. That was all that was needed. Those tiny images could be embedded in the program and loaded at launch time. Out of sight and out of mind.

But for Explorer to display a 'pertinent' icon for each and every file listed takes a bit more work. A bit.

1. Check the file's extension.
2. Look in HKEY_CLASSES_ROOT for the extension.
3. Get the corresponding file type for the extension.
4. Look again in HKEY_CLASSES_ROOT for the file type.
5. See if the file type has a designated icon.
6. The icon will be denoted by both a file path and a number.
7. Scoot to the file on disk at the path noted above.
8. Open the file and read the headers.
9. Locate the resource header.
10. Use the number you got in 6. to index into the icon resources.
11. If the number is positive: it's a name.
12. If the number is negative: it's an index.
13. Find the icon and load it and copy it.
14. Resize the icon for display.
15. Give it to Explorer.
16. Next file.

It's easy to see why Microsoft came up with 'ShellIconCache': there are so many steps - so many disk accesses - involved in getting a single icon that navigation of big directories became prohibitive.

The Microsoft 'Enumdesk' sample program - the 'mini Explorer' on which the real Explorer is based and which was written before someone came up with 'ShellIconCache' - needs about half a minute to display the contents of system32.

It's unbearable.

Explorer contains other technologies. Its 'file management' is based on COM - meaning it's going to be sluggish anyway - and it can accept plugins of a sort. But out of the box or even with considerable tweaking Explorer is unacceptable for professional use - it's too sluggish, does all the important things the wrong way, and does a lot of stuff you'd rather it wouldn't do at all.

The Enumdesk Replacements™

And now that Windows totally lacks a 'file manager' you'd think some independent spirit or two would write one. And someone has. But they're pretty much alone. Writing a file manager is a big task: look at how much work went into Winfile.

But the Enumdesk code is out there - it's part of the MSDN ('Microsoft Developer Network') subscription. Its source code is free to use. It's already complete - like Explorer but it's free and ready to go. All you need to do is add a few doodads to it. Piece of cake.

There are any number of 'Explorer replacements' out there. Of course there are. But what they all have in common is 'Enumdesk'. They're actually Enumdesk Replacements™.

Enumdesk is freely available code from Microsoft. You don't have to write your own file manager - it's already been written. All you have to do is hone it and tweak it a bit and then put a price tag on it. Something like being the one who puts 'inspected by #21' on something at the end of a long assembly line. It's not your work at all. And it's just another Explorer.

Here are a few of the 'Explorer replacements' available today.

http://gpsoft.com.au
http://mustangpeak.net/ultraexplorer.html
http://www.konradp.com/products/acbplus/
http://www.v-com.com/product/PowerDesk_Pro_Home.html
http://xyplorer.com
http://zabkat.com

They're neither faster nor more efficient than Explorer: they're Explorer all over again. They're too much of an already bad thing.

But What's This?

David Schneider of Switzerland doesn't want to go with the flow. And he doesn't like Explorer or any of the Enumdesk Replacements™. He wants to make Winfile work again.

David claims Winfile broke under 'V*STA'. Actually Winfile broke almost ten years ago. Windows 2000 didn't ship it. And although older copies would 'run' they wouldn't run very well. Drag-drop didn't work right; settings wouldn't stick; and so forth.

But David's figured out a way to get 32-bit Winfile to run adequately on Microsoft's latest.

To Each His Own?

Now the usual array of 'pundits' laud any number of those Enumdesk Replacements™. That's their job. And they're not exactly pros. But of course you understood that. And not a single one of those Enumdesk Replacements™ is more efficient, faster, less aggravating, or less of a bloated misery than Explorer itself.

And you already have Explorer for free. Or at least using it won't cost you any more than you've already spent.

There are few people who actually literally navigate Windows file systems anymore. Even high paid PC repairmen today are more likely to scoot straight for 'Add/Remove Programs' if something goes wrong. And many a user won't even know there's something called 'Explorer' - thinking it's all INTERNET Explorer.

But if you want something that really works you can either beg borrow or steal a copy of 32-bit Winfile and then try the Schneider hack - or you can look into the product listed below.

See Also
The Radsoft XPT Gallery: The X-file Suite
David Schneider: Windows File Manager under Windows V*STA