Why does the class name for Explorer change depending on whether you open it with /e?


I noted some time ago that Explorer's original name was Cabinet, and that the name lingers in the programmatic class name: Cabinet­WClass. A commenter with a rude name points out that Explorer uses the class name Explorer­WClass if you open it with the /e command line switch, adding, "This is rather strange since you can toggle the folder pane on/off in the UI either way."

In Windows 95, the window class names for Explorer were Cabinet­WClass for plain Explorer windows and Explorer­WClass for windows opened in Explore mode with the folder tree view thingie on the left hand side. This was not strange at the time because there were two different types of Explorer windows, and there was no way to change between them. The UI to toggle the folder pane on/off did not exist.

Internally, the two types of Explorer windows were handled by different frame window classes, and naturally the two different classes got different names. The plain Explorer window frame hosted a view window, an address bar, and a status bar, whereas the fancy Explorer window frame hosted those components plus a folder tree. It wasn't until some time later that the ability to toggle the folder pane on and off was added. To do this, the two window classes were merged into a single implementation that dynamically added in or removed the folder tree.

Great, we can get rid of Explorer­WClass and just use Cabinet­WClass for everything.

And then the application compatibility bug reports came in.

Because even though it wasn't documented, application relied on the implementation detail that plain Explorer windows could be found by doing a Find­Window for Cabinet­WClass, and that fancy Explorer windows could be found by doing a Find­Window for Explorer­WClass. They would do things like launch explorer.exe /e C:\some\folder, wait a few seconds, and then do a Find­Window("Explorer­WClass", ...) and expect to find a window. (Just do a Web search for Cabinet­WClass and Explorer­WClass if you don't believe me.)

For compatibility, therefore, Explorer windows still use the old class names from Windows 95. If you open the window with the folder pane hidden, the class name is Cabinet­WClass, and if you open it with the folder pane visible, the class name is Explorer­WClass. The two classes are functionally identical, but people who rely on undocumented behavior expect to see the same names from 1995.

Comments (21)
  1. anonymouscommenter says:

    That undocumented behavior is a lot more reasonable than most we've seen here.

  2. SimonRev says:

    "A commenter with a rude name" — I about snorted my drink out my nose when I read that.  Doesn't take much to guess who that was (might even be better to say "*the* commenter with a rude name" :)

  3. anonymouscommenter says:

    Mr. Chen, if you ever get the chance to document it, why did the hosts file for windows end up in System32drivers ?

  4. anonymouscommenter says:

    It didn't, it ended up in System32driversetc.

  5. anonymouscommenter says:

    These must be the same kind of people who shell out to utilities like "ifconfig" when there's a perfectly good API to do it directly, with much less chance of problems caused by missing (or too much) escaping, and much more reliable treatment of errors. More than one domestic router has security problems due to this mindset.

    Most of the explorer.exe operations can be done via documented COM interfaces. IMHO, the only legitimate reason to launch "explorer.exe /e C:somefolder" is when you want to give the user an exporer.exe window on that folder (for instance, the user clicked on an "Open Explorer here…" button). You shouldn't do anything to the resulting window afterwards (it might have opened on a new tab of an existing window or something equally crazy, for instance).

    And I dislike this "wait a few seconds" mentality some Windows programmers have. Making a program behave differently just because the computer is slow that day (it might be running some heavy background processing, or trashing because the user opened a too-large image on a web browser) is not a good thing.

  6. anonymouscommenter says:

    Better than the commenter with a rude blog who is always trying to show how the customer is a moron and Microsofties are so smart

  7. anonymouscommenter says:

    Raymond considers disliking Windows "rude". Noted.

    [Dislinking Windows is not rude. Saying that Windows "sucks" is rude. -Raymond]
  8. anonymouscommenter says:

    Regarding the hosts file, I always assumed it's location in System32driversetc is due to the use of part of the BSD network stack in Windows.  Under *nix the hosts file is usually at /etc/hosts.  If the network driver is under System32drivers, just concatenating the two yields System32drivers/etc/hosts. Same goes for the other files files in that directory.

    But that's just a guess.

  9. anonymouscommenter says:

    @Pat: I think Raymond's referring to the mild invective used in the Rude Name.  There are many ways to express dislike of Windows; "sucks" or "sux" or however you stylize it is rather classless and rude.

  10. skSdnW says:

    Why was/is so much of Explorer implemented in shell32? Would it not have made more sense to only put the APIs and reusable components (DefView etc) there and things like the start menu and the file browser frame in explorer.exe? Surely you would save a bit of RAM by reducing the size of the non-shareable PE sections so that only explorer.exe pays the price and not every app that loads shell32?

  11. anonymouscommenter says:

    They did. It only eats address space. I can't believe I have to point it out.

  12. skSdnW says:

    @Joshua: Global variables and statics eats actual memory. I can't believe I have to point it out.

  13. Insert Name Here says:

    @skSdnW: IMO, memory use is a relatively minor problem – modularity and layering are more important reasons why those things should be in explorer.exe if possible. *Ideally*, no component should ever be loaded into an application's address space if it doesn't need to be. It just opens up more opportunities for bugs.

    Speaking of bugs caused by component loading, I once had to figure out why application wasn't loading my modified version of SciLexer.DLL wasn't being loaded. Turns out, I had a shell extension installed that had its own copy of SciLexer.DLL, and when I went to File->Open the file I was testing with, it would load the shell extension, and the shell extension's DLL got loaded before mine ever did.

    (I wish incrementally improving Win32 was still a concern for Microsoft. There are so many things that could've been fixed, like adding an API to load DLLs based on their full path… *disillusioned sigh*…)

  14. anonymouscommenter says:

    @Cesar: I suspect they're the same kind of people who think 0 divided by 0 should yield 0.

  15. anonymouscommenter says:

    To be fair, "X sucks" for any value of X is practically a punctuation mark in the Internet technosphere. Besides, all existing successful operating systems suck in various ways. All of the successful ones are also awesome in various ways. You always remember the way that a piece of technology frustrated you more than you remember the way it made things easy.

    I do have to wonder what applications they were. Am I right in thinking that we're talking about one or more Microsoft products?

    One thing that I find interesting about Windows is that some behaviours lie in this strange land between two worlds, where supported behaviour isn't necessarily the same thing as documented behaviour.

  16. AndyCadley says:

    Guessing or naming bad apps is against the rules of the blog, but it's definitely not just Microsoft apps. I've fixed plenty of third party apps over the years where I've seen them doing things like this.

    I think things actually got worse after the internet started to take off, as people would increasingly share "helpful" code for doing things like this, often even in cases where official methods existed.

  17. anonymouscommenter says:

    > Saying that Windows "sucks" is rude. -Raymond]

    Not if it's true. Being backwards compatible with broken apps makes an OS suck in the long run, you know.

  18. anonymouscommenter says:

    @ suxxor, z/OS is backwards compatible with ALL code all the way back to the mid sixties when we called it OS/360.  It would appear as though your assertion is incorrect.

  19. skSdnW says:

    @Insert Name Here: In a Win95 context memory was important for those poor people with a 386!

    There has been some layering changes done by the shell team, first by moving some things to shlwapi in the early IE days and later on with shcore and explorerframe.dll.

  20. anonymouscommenter says:

    @AndyCadley

    Naming MS (external) apps has never been forbidden. Raymond is more concerned about OUTSIDE groups taking offence.

    INSIDE groups already know him. ;-)

    [Naming MS external apps is also forbidden. That's why I always call them "Team 1" and "Team A". -Raymond]
  21. anonymouscommenter says:

    @Raymond

    Naming things you explicitly didn't name is also forbidden by the rules.

    But you constantly reference various MS products and features, by name… :p

    [Not if I'm saying bad things about them. -Raymond]

Comments are closed.

Skip to main content