The quiet fading away of the CtlPanelClass

If you search MSDN for CtlPanelClass, you'll find a few really old Knowledge Base articles that include it in a list of "class names of common Windows applications." I'm not sure why the Knowledge Base articles bothered to list those classes; there is no technical reason for applications to need to know this, and including the information merely encourages programmers to rely on the window class name in strange undocumented ways. (This is another one of those cases where a Knowledge Base article written to assist in troubleshooting becomes interpreted as formal documentation.)

Windows Vista finally got rid of that window class. It took only ten years.

The window class was used by the old Windows 3.1 Control Panel application. Back in Windows 3.1, the Control Panel was a standalone application and was not integrated into the shell namespace (in large part because there was no such thing as a shell namespace back then for it to be a part of).

There was one program which not only searched for a window of that specific class name, but it also sent the window WM_COMMAND messages, since of course it knew what the menu IDs were for the Control Panel application, and it knew that the Windows developers would never change the IDs or replace the standalone Control Panel application with anything else.

When the standalone Control Panel application was converted to a virtual folder, it also came with some decoys in order to maintain compatibility with older programs that relied on the old behavior in strange undocumented ways.

One of those decoys, the CtlPanelClass was removed for Windows Vista. A crash was traced back to a bug in the decoy window which manifested itself if a control panel took more than ten seconds to launch itself. To fix the bug, we just removed the decoy window, but we were prepared to write a compatibility shim in case there were people still running that ancient application from 1993. We didn't actually turn the compatibility shim on, but we were ready just in case.

We removed the decoy and crossed our fingers.

We got lucky. Nobody noticed.

Comments (23)
  1. chloraphil says:

    Old classes never die, they just fade away

  2. R. Bemrose says:


    Old programs never die, either.

    The first thing my father asked me to do when he got a new laptop with Windows 7 64-bit on it was to install Quicken 2000 Deluxe on it.  Despite that Quicken has a new version every year.

  3. 640k says:

    Which shims can I turn on with registry flags?

  4. David says:

    Holy crap, you'd think by Vista you'd have thrown out a lot of those compatibility hacks. I think a more sensible model to support old features would be supporting Windows XP forever, but charge users an exorbitant yearly license to keep the development team alive. Or simply provide support on demand, through third parties, or whatever. Just keeping all those hacks around adds a whole layer of crap to a perfectly sound codebase, that in many cases just introduces bugs for the benefit of 3 guys who want their oscilloscopes to run the latest Windows,

  5. hakzor says:



  6. frymaster says:

    @david: that assumes that compat systems are needed by a small group of people all the time.  In reality, they're needed by just about everyone, but only for a couple of applications.  Not having the compat system would mean NOONE would be able to upgrade, because of a small number of things holding them back

  7. DWalker says:

    @david:  Aas Raymond has said before, when uses upgrade their operating system, and applications stop working, who are they going to blame?  Not the application vendor who used undocumented features taht dn't work any more.  

    Causing users pain to "prove a point" to application vendors is not helpful.  Some of the application vendors might have gone out of business.  And charging users a big license fee is probably not a workable model either, although it is an interesting thought….  

  8. Ben Voigt says:

    Causing users pain to prove a point is helpful, if it's an appropriate amount of pain and doesn't actually prevent them from getting their work done.

    Vista and Windows 7 already have this Action Center thing that sits in my taskbar and nags me because I've dared to use Windows Update settings that prompt me before replacing code on my computer.  Action Center also nags to submit error reports about blue screens of death and upgrade video drivers. (Unfortunately while it was correct about an outdated driver initially, because it tried to put 32-bit drivers on my 64-bit OS, I ended up doing the upgrade without Action Center's help and now it isn't smart enough to recheck the version.  Oh well.)  It seems to me that having an Action Center entry for "Obtain updates for the following applications to improve Windows 7 compatibility: <list all apps with active shims>" would be just the right amount of pain.

  9. Henke37 says:

    They have a shim to inflict pain on users, it shows a MessageWindow before the program loads with a notice about compatibility issues. And then it optionally prevents the program from being started.

  10. Yuhong Bao says:

    "We got lucky. Nobody noticed. "

    Well, keep in mind that 64-bit Windows does not support 16-bit apps at all anyway.

  11. Dean Harding says:

    "keep in mind that 64-bit Windows does not support 16-bit apps at all anyway"

    I'm pretty sure Raymond HAS kept that in mind, given that someone invariably mentions it in the comments to every second post for some reason…

  12. Myria says:

    If Windows has a compatibility shim for your company's application, how do you determine what those shims are?

  13. Zian Choy says:


    I'm pretty sure the Windows SDK has something that lets you view existing shims.

  14. Zian Choy says:


    I'm pretty sure the Windows SDK has something that lets you view existing shims.

  15. Michael Geary says:

    I was helping a friend set up a new monitor on his Windows 7 system, and I noticed an antique-looking Office Quick Launch panel displayed at startup. I asked him and he old me, "Oh, we have the latest Microsoft Office on here." I said, "Office 2010? It doesn't look like that." He replied, "No, it's Office 2007. Version 7."

    I checked the About box and he was almost right – it is Version 7. Microsoft Office for Windows 95. Version 7. Only 15 years old.

    Raymond, I'd say you got lucky on this one! :-)

  16. Henke37 says:

    @myria, I would assume that the application compatibility team is nice enough to give you a call before they release their hack set. That is, if you still exist at that point.

  17. Dean Harding says:

    @Myria You can use the Application Compatibility Toolkit[1], which actually gives you a bucket-load of info. Personally, I think all developers should run their software through ACT before release. It not only tells you what problems you're having *now* but also what problems you might run into in the future.


  18. prunoki says:

    @Michael Geary: and the most beautiful thing is that everyone takes it for granted that Office 95 should work on Windows 7. Me too. This shows the quality of work those application compatibility guys do. That is surely one thing why I use Win.

  19. 640k says:

    most win32s programs cannot even run on vista.

  20. Klimax says:

    @640k: What do you mean and some examples would be good. (Win32s ??? like that thing for Win 3.11? There were apps targeting it?)

  21. Klimax says:

    @640k: What do you mean and some examples would be good. (Win32s ??? like that thing for Win 3.11? There were apps targeting it?)

  22. 640k says:

    freecell (win32s version)

    btw, the blog software suck.

    [The blog software doesn't like short comments. -Raymond]
  23. nobugz says:

    Awesome that you could drop it, bet it took a fair amount of knocking wood.  Next candidate: ComboBoxEx.  Just a personal pet peeve because it is documented and I always went "jeez, what's the point".

    From the other end: DirectUIHWND is starting to rub.

Comments are closed.

Skip to main content