The history of the Windows XP common controls


In the beginning, there was one control library, namely USER, the window manager itself, which provided buttons, static controls, edit controls, scroll bars, list boxes, and combo boxes. These controls were under the purview of the window manager team.

In Windows 3.1 a second control library known as the shell common controls was added, but the library really didn't come into it own until Windows 95, where it consisted of the list view, header, tree view, tooltip, toolbar, status bar, track bar, tab, updown, progress, hotkey, and animation controls. These controls were originally custom controls written by the shell team for use in Explorer, but since they seemed to be generally useful, time was budged to do the extra work to make the controls more suitable for general use, testing the controls in combinations and scenarios that Explorer itself didn't use, and putting together formal documentation.

The shell common controls library underwent many changes over the years, whereas the core intrinsic controls in the window manager changed much more conservatively.

With Windows XP, the visual design team wanted to give the look of Windows a new life. Changing the non-client area (such as the window frame) was comparatively straightforward, since programs didn't have much control over that part of the window anyway. As a result, they get the Windows XP look "for free".

The client area is another story. Programs are in control of their client area, where they can place controls that come with Windows, their own custom controls, or controls obtained from a third party library. Making major changes to the core controls or the common controls would be a high-risk endeavor since there are thousands upon thousands of Windows program that not only use them, but use them in all sorts of crazy ways.

The initial stab at resolving these two conflicting goals (making major changes to these controls to increase visual appeal and functionality while simultaneously not changing them to maintain compatibility) was to create a new DLL that would contain the "fancy new version" of the core controls as well as the shell common controls. The old DLLs USER32 and COMCTL32 stayed where they were, so that old programs continued to get the behavior they were expecting, and the new XP-style controls were placed in a DLL named UXCTRL.DLL. UX stands for user experience, which was the hot new buzzword at the time. To avoid name collision with the old style controls, the new controls got new names beginning with Ux. For example, the UXCTRL version of the button control was called UxButton.

New features could be added to these new Ux controls with wild abandon without heed for backward compatibility since they were brand new controls. There was nothing they had to be compatible with. Explorer was changed to use these new controls instead of the old stodgy controls, and everything worked great.

Or so it seemed.

We thought we had cleverly sidestepped the backward compatibility problem by creating entirely new controls, but doing that created a whole new category of compatibility bugs. Even though it's completely undocumented and unsupported, programs like to grovel into the internal data structures of other programs or otherwise manipulate those programs' windows. In Explorer's case, it turns out that a lot of programs like to go spelunking around Explorer's window hierarchy and use functions like FindWindow and EnumChildWindows to find the object of their affections. For example, a program might use EnumChildWindows to enumerate all the child windows of an Explorer browser, and then use GetClassName and lstrcmpi(szClassName, TEXT("button")) to look for a specific control. In this example, the target was a button, but it could have been a list view or a tool bar. Since all the new XP-style controls were named things like UxButton and UxListView, these programs which looked for a button by comparing against the string "button" stopped working.

Of course, there was no guarantee that Explorer would even use buttons at all; Explorer was completely within its rights to revamp its user interface. But that's not much consolation to the customers who paid good money for these programs, especially since magazine columnists are the types of people most likely to be running (or indeed even writing!) strange off-the-wall programs that pull these sorts of nasty stunts in the first place.

Okay, so it is now a compatibility requirement that all the new window classes have the same names as their old counterparts. This created an impasse, since these controls needed to be created by dialog boxes, and therefore they had to be globally-registered window classes. But you can't have two global window classes with the same name, because that would create ambiguity over which one the caller was asking for.

More brainstorming ensued, and a Plan C emerged. The common controls library would take advantage of side-by-side assemblies and use the application manifest to control which DLL a given window class name would resolve to. Thus was born a new DLL also called COMCTL32, but with a new version number—version 6. Old programs would get version 5.82 just like they did in Windows 2000. New programs would have to use a manifest to specify that they wanted version 6.

Once again, the solution came with a new problem. Since the entire COMCTL32 library got split into two versions, this meant that there were two versions of the image list code. Whole new scenarios emerged, such as putting a version 5 image list in a version 6 tree view, or vice versa. (As the linked thread notes illustrates, not all of the problems with cross-version scenarios were caught in the initial release and had to wait for a service pack for the fix to become available.)

Comments (63)
  1. FusionGuy says:

    Yet another great example as to the extent Microsoft is willing to go to maintain backward compatibility.  Whoa.

  2. Spike says:

    FusionGuy> And the extent some developers will go to to make their applications as fragile as possible.

  3. Jack Mathews says:

    "And the extent some developers will go to to make their applications as fragile as possible."

    Well when you allow any application to do anything to any other applications’ windows, you’re kind of asking for this sort of thing.  Give people an inch, they take a mile.

  4. MS says:

    I will admit to spelunking into another application’s internals for very specific reasons.  As far as I could tell at the time, there was really no way to achieve what I wanted to do otherwise.  I did make every effort to ensure that the code that crawled through the other application was as robust as possible.  I would love to revisit this code and try to find another path, but I cannot think of how I would do it differently.

  5. Joe Bruno says:

    This all leads to an interesting "behavior by design" that I came across recently. If you don’t use anything than the standard window controls, then you’re not using COMCTL32.DLL and you don’t need to call InitCommonControls.

    BUT – if you use a manifest to say "please use the themed appearance", then although you aren’t using anything from COMCTL32.DLL, you still need to call InitCommonControls. If you don’t, then all your dialog boxes will fail to appear.

    This is interesting for two reasons. First of all, it’s a way to make the following Hello World program fail:

    int … WinMain(…)

    {return MessageBox(NULL,"Hello World",NULL,MB_TASKMODAL);

    };

    Because the problem affects every dialog box, even the standard MessageBox ones, if you use the "modern" manifest then this program will do nothing and say nothing.

    The second interesting thing is that I’m sure that this problem didn’t originally exist in Windows XP. I started getting reports of it so late that I think that the "behavior by design" must have been added in a later update.

  6. Koro says:

    A little precision on my previous comment:

    I was more specifically talking about the controls in COMCTL32 than those in USER, because I don’t think such a low-level component as USER could have a direct dependency on UxTheme, but, something more in the lines of RegisterUserApiHook.

  7. Ben Cooke says:

    Given the problems that occur when changing the UI of bits of the shell, I’m left to wonder why Windows XP switched from having the taskbar be a tab bar to being a toolbar. The two behave in much the same way, but it broke applications that wanted to screw with the taskbar.

    I can only assume that this had something to do with the "Group Windows By What Executable Created Them" feature. I find that feature immensely irritating, but I get the feeling that I’m the only one.

    As silly as it might sound, I used to use a simple little utility that added some extra functionality to the task bar. This program didn’t work for Windows XP, so this was a deal-breaker for me and I stayed on Windows 2000 for many years. I’m told that it’s been updated to work with Windows XP’s taskbar now, but I don’t use Windows anymore so I’ve not verified this for myself.

  8. John says:

    Why is it that some older programs do get the new visual look?

    Everytime I read about the way visual styles are implemented it always seems that applications only get it if they ask for it, yet some old apps manage it (not to mention those that sort-of manage it, with a mismash of both styles of controls).

    Could it be that some runtime library that they use was updated in XP and enables it?

    The same sort of things used to happen in Windows 95 (and probably still does, it’s been a while since I ran a 16-bit app), it seemed totally random whether a 16-bit app would get 3.x or 95 style controls or a mixture of the two.

  9. WikiServerGuy says:

    May be sad, but XP seems like the good old days now. In modern time (i.e. Vista) you have to do themed calls and various hacks to get a common-looking interface similar to IE or Explorer.

    Common controls seem depreciated with all the apps using varying menu strips search boxes and more, glass is an absolute beast, and a paradigm shift towards per-app interfaces instead of using common elements. Heck, to even get the common shell font you have to do in-place DLGTEMPLATE hacks, as "MS Shell Dlg" and friends no longer work!

    I feel like an old fogey :D.

  10. JamesNT says:

    You’ll never in a million years see operating systems like Mac OSX and Linux strive for this kind of back compat.

    No wonder MS is number one.

    JamesNT

  11. Ulric says:

    a paradigm shift towards per-app

    interfaces instead of using common elements

    Whether it’s true or not, I get the same feeling.  I believe this is a detriment to Windows and it’s advantage over other OS.  I’m baffled by a lot of the UI in Vista.. there are multiple versions of the File Open dialog, some message boxes have buttons for choices, others  use the new vertical list of "->" (that don’t actually look push-able).

    I’m confused with where this is going.  Are the OK/Cancel buttons supposed to be on the bottom, on the right, centered, or aligned right..

    Any programmer that’s trying to copy the built-in look won’t know where to look, which version to follow.  Office has its own thing, too.

    Another example, under Vista our app’s message boxes look ‘the old way’ but the buttons are aligned right instead of centered.  So.. it’s inconsistent with other dialog.

    Anyways, a manager over here ask that we support the ‘standard open file dialog’.  I showed him 4 different Open File dialog in Windows, including the compact one that comes up in MSPaint/Notepad, which an expand button.  It’s an obvious direct clone of the one in OS X.  "Which one do you want?"  The answer was some XP variation.  

  12. So at what point did controls like Button and CheckBox move from User into the common controls?

  13. Bob says:

    There "should" have been a great deal more safety checks and a much better design, so that the issue could never arise in the first place. And while it’s easy to say so, it’s a lot harder to build a time machine and take a modern PC back to 1982 so that they could have actually written a perfect OS that benefits from the last 20-odd years of development, and had the resources to actually run it.

    And Ben, you’re not the only one who finds that "feature" irritating, but (a) it can be turned off and (b) various Linuxes were doing it well before XP came out, and (c) some people do actually find it useful.

  14. Triangle says:

    [It’s “only” the visual look”? I’m sure you can use your imagination to come up with ways changing the visual look of a button could totally screw up a program that relied on the previous visual look. 99% of programs are just fine with it, but it’s that last 1% that is the deal-breaker. -Raymond]

    1: The only case I can think of is something uses owner drawing to customize the way the button looks, which wouldn’t exactly break, just look a bit different.

    2: Why didn’t you just shim the 1%, so that the people who put in the time to make it work properly benefit ?

    [“Look a bit different” counts as breakage if the button becomes unusable as a result. (Actually, it’s still breakage if the button looks bad. The customer who’s using the program won’t be happy that all the buttons in Program X show up in a weird mishmash of colors.) And 1% is an unacceptably high shim rate. And having a shim doesn’t help when Random Vertical Market Application That Is Not In The App Compat Library stops working, since it won’t be in the shim database. -Raymond]
  15. Igor Levicki says:

    I have always been annoyed with the fact that computers (actually software) cannot distinguish two things with the same name.

    Why on Earth you don’t start using those GUIDs as the index/key? Then you wouldn’t have to worry about name collisions anywhere, file systems included.

    [Please go back and read the article again. It already explains why your proposal doesn’t work. -Raymond]
  16. WikiServerGuy says:

    Unfortunately, those 1% tend to include most popular commercial apps.

    For example, take the messagebox (it isn’t really a common control but its close enough). A lot of people like to subclass the thing and add UI elements to it, as it does a lot of neat little things transparently that are difficult to get exactly right, and you can reuse common code etc..

    Now, this in some cases doesn’t cause a problem – but lets say you put a checkbox or something between the buttons and messagetext. It is ok from 95-XP or so but vista introduces another window in the middle that might end up hiding it. Not a biggie, unless you depended on the user to do something in that case – then you end up getting screwed and your program no longer works.

    This is just one example – more common ones are flicker workarounds for issues in Windows itself, for example. When they make a new version and make drastic changes it might even break that workaround.

  17. A Bad Coder says:

    Bob: while it’s easy to say so, it’s a lot harder to build a time machine and take a modern PC back to 1982

    Actually it is easy to build a time machine for apps to take them ‘back’ to the time they were written, to the system environment they call home.  This is the approach Apple takes to compatibility.

    Linux chooses to bring the apps ‘forward’ into the modern environment.  This can be done because any apps that matter on linux are open source.

    Microsoft chooses to make their os look different depending on what spot you are standing in or what mood you are in — like the optical illusion where the picture is both of young woman and the old lady.  This approach cannot be maintained for long.

    [I dunno, 25 years is pretty long. -Raymond]
  18. Tom says:

    Perhaps it’s just me, but there are so many APIs in Windows for doing things “the right way” that I find it hard to believe anybody would resort to trolling through Window hierarchies to fake pushing buttons.  I know that it happens — as Raymond likes to point out — but it just seems that there should be something in the programmer’s head that says “whoa! There’s gotta be a better way!” when they start writing code like that.

    [Hey, Tom, maybe you could have a chat with commenter MS. -Raymond]
  19. Koro says:

    [“Look a bit different” counts as breakage if the button becomes unusable as a result.]

    Usually, either the button is completely redrawn (using ownerdraw), in which case THAT button would look classic amongst the other skinned ones, or either the app coder is really bad and somehow subclassed the button, and half-handles the WM_PAINT case (letting part of the original background shine through).

    But in both cases, at worse it would look ugly, but still be usable.

    The only way this could break was if the app somehow reads the screen (using GetPixel or BitBlt from a screen DC) to locate the button, but THAT is far-fetched enough (I still bet some crappy in-house VB app written by an intern does that somewhere).

    Do you have some specific incompatibility scenarios in mind that I did not think of?

    [An app that looks uglier on Windows N+1 than it did on Windows N counts as an app that fails the app compat criteria. Maybe you think it’s acceptable, but say that to the user who has to use that app every day. (And your “far-fetched” scenario isn’t all that far fetched.) -Raymond]
  20. Eff Five says:

    Ok I’ll bite, what are the "nasty stunts" that the app that you linked to pulled?

  21. Dean Harding says:

    Eff Five: Looks to me like this "RegEdit+" just hooks into the regular regedit and disables/replaces various functions. The only way that could be done is by spelunking in regedit’s private data structures and stuff. Seems pretty "nasty" to me…

    A Bad Coder: have you actually used the compatibility layer in Mac OS? In my opinion, it’s horrible and I couldn’t wait until the vendor updated the software to work without it. I don’t believe it’s a very nice way to treat your software developers if you’re forcing them to re-write their code every 5 years. See, for example, http://www.joelonsoftware.com/articles/fog0000000069.html

  22. Skip says:

    Well sometimes spelunking like this is the only way to get something done.  For example, the most recent time I did something like this, is the brain-dead way that Visual SourceSafe 2005 broke compatibility with previous versions in handling files with local modifications.

    In previous versions, when you did an update on a tree and it found a file with local modifications you were presented with a dialog with options for ‘leave this file alone’, ‘check out and merge’ or ‘discard changes’.   In CSS2005, it uses the exact same dialog, but the ‘leave this file alone’ option is disabled.

    Now, there are a myriad of reasons to need this option.  If you’ve got concurrent checkouts disabled due to the high risk of damage of projects and solutions, you may have done some local modifications you’re not ready to deal with yet.  Or you may have local configuration files that you explicitly never want to check in, because they have your specific setup info in them.   Or you may have files that you need to not have the readonly bit set on them, even if they’re not going to be updated in the normal course of things on your box.   DB files are that way frequently, when deploying them to CE devices.

    So the solution?   Use FindWindow() to find the radiobutton, and EnableWindow() to enable it.  Problem solved.   Now I’m sure later versions will break this, and if I’m forced to move to one of them, I’ll just have to find a different solution.

  23. MS says:

    "but it just seems that there should be something in the programmer’s head that says "whoa! There’s gotta be a better way!" when they start writing code like that."

    "[Hey, Tom, maybe you could have a chat with commenter MS. -Raymond]"

    I sincerely wish there was a better way.  Getting into the details would take too long, but I exhausted every other means of getting the piece of information needed.  Maybe I missed something, or maybe the latest version of the APIs has better options for doing what I need to do.

  24. Skip says:

    I do think, though, that the main thing is, as a programmer, when you do something like this you should realize "not supported, it will probably break on some update".  I certainly do.   And I’m not sure I’d ship code that did this, but I certainly have no problems doing it in internal tools I maintain.

  25. Adrian says:

    Yup, great lengths for backward compatibility.  It’s a herculean effort and an impressive acheivement.

    As an ISV, though, it’s frustrating that our programs don’t automatically benefit from *forward* compatability.  When the look-and-feel is overhauled and improved, we need to produce a new version with a couple extra lines in the manifest.  Because MSFT has to compromise to keep fragile programs running, robust programs lose out on the benefits of the new system.

    A more recent example is the visual scaling in Vista for high DPI displays.  Vista assumes by default the programs didn’t follow the rules and write DPI-agnostic layout code.  And, unless the program is updated with an I-really-do-the-right-thing flag, they get visually degraded on high DPI displays.

    I understand why Microsoft makes these choices, and I don’t blame them.  It’s the fault of vendors who don’t pay their taxes.  But it sure makes it hard to build lasting-value software.

  26. Koro says:

    Thanks for clearing that up Raymond, as I always wondered why it was that way (and have been saddened about the lack of forward compatibility too).

    However, one comes to wonder, why wasn’t it possible to add the skinning code to the existing old controls instead of coding brand new ones? After all, it’s only the visual look (and some response to mouse movements, for hover notification) that changes, so how could *that* break programs that much? Mac OS X does it with OS9 programs, as I remember, and they don’t break.

    Although the manifest way has one advantage over the UXCTRL DLL way, that it’s easier to res-edit the old .exe to make them use CommCtrl v6 than the hex-edit their EXEs to change their window class strings in all place (and with longer strings at that)

    [It’s “only” the visual look”? I’m sure you can use your imagination to come up with ways changing the visual look of a button could totally screw up a program that relied on the previous visual look. 99% of programs are just fine with it, but it’s that last 1% that is the deal-breaker. -Raymond]
  27. Xepol says:

    Frankly, I get a little sick of hearing about how the design of Windows is continually compromised to support other products which violate good design rules (and often explicit warnings and tons of advanced notice).

    Won’t someone please get some sanity, and say "screw it, its broke because of how THEY wrote it, we warned them, its their fault, they have to fix it." ???? PLEASE?!?!? Heck, just list the identified apps in the incompatible apps list and be done with it.

  28. AlmostAlive says:

    I wonder how many big commercial applications do the sorts of crazy things that Raymond is talking about.  His example is something that messes with Explorer — that doesn’t sound like an app that my business would fail with if it doesn’t run.  It sounds more like a utility.

    But my question is, has the Internet at all changed the situation?  Right now probably half my applications check for new versions automatically (and half of those will update themselves with a single click).  When a new version of Windows comes out, there’s no shortage of new versions of utilities available to download quickly and easily.

    Does that change the situation at all now from what it was a few years ago?

  29. Aaargh! says:

    “[I dunno, 25 years is pretty long. -Raymond]”

    You seriously think that 25 years is ‘pretty long’ ? And to say it has been working for all that time. Ok, most apps still work because of this, but the OS is a mess. The win32 API is horribly complex, most functions take a gazillion parameters half of which don’t do anything anymore or have to be set to some magic value to keep it working. (See earlier articles on this blog for examples).

    This stuff must be unmaintainable by now, just look at Vista, it took more than 5 years to produce it, even with the amount of resources that MS has at it’s disposal. And the end result is disappointing to say the least. 5 years of development and hardly anything to show for it. How much of those 5 years went in to keeping stuff working instead of fixing the OS ?

    [If you say “This operating system won’t last long” and it lasts 25 years, then I ask you to provide your definition of “long”. -Raymond]
  30. cmpl says:

    "you’re not using COMCTL32.DLL and you don’t need to call InitCommonControls. […] then all your dialog boxes will fail to appear."

    I’ve been bitten by this too, but this behaviour changed between XPSP1 and XPSP2. But I don’t remember which one was pickier.

    ["And your "far-fetched" scenario isn’t all that far fetched."]

    I too, thought that this is really the only scenario that would break and can only think of accessibility tools like screen readers (since they might want to read buttons IE which are windowless), and macro tools that automate clicks and keyboard typing.

    Still you could get away with placing the user in control, a checkbox under an "advanced" tab/button along with an explanation that it can break compatibility, and off by default. But then you might have to make a group policy for it too (and perhaps just leave it at a policy), where you can do more neat stuff like keep a list of known-to-be-broken apps. But maybe that would add too much work and releasing in time was more important back then.

  31. MadQ says:

    I think the shell team probably saved me a lot of tedious work. I dislike the standard mouse-wheel behavior of always scrolling the focused window, so I wrote a program that intercepts mouse-wheel messages and posts them to the window under the cursor.

    Getting this to work correctly 99% of the time was no mean feat. Had they stuck with the UxXXXX class names, the behavior inevitably would have diverged drastically from the old controls over time, which would have caused me no end of trouble. Writing the “WheelHook” has been (and still is) an interesting learning experience. Early on, I found out the hard way that RealGetWindowClass() only works properly for COMMCTL32 version 5. For version 6, it behaves the same as GetClassName(). I had to roll my own (Real)ChildWindowFromPoint(Ex) because none of those functions behave as expected all of the time. If you want to see an example of this, run CALC.EXE in scientific mode, then start Spy++ and try to use the mouse to select one of the radix, Inv or Hyp buttons.

    Don’t even get me started on Product X‘s dialog widgets. Also, if I ever find out who on the Product Y team thinks that it’s cool to use STATIC controls to parent other controls, he or she is going to get a serious tongue-lashing.

    WheelHook uses a WH_KEYBOARD_LL hook, so it doesn’t require a DLL to be loaded into every process. One consequence of the SxS approach to COMCTL32 is that global sub-classing becomes a lot more difficult, because now you have to deal with activation contexts. The thread calling the DllMain() (let’s not even get into the loader-lock issue) of your sub-classing DLL may be running under a different activation context than the application’s UI thread. In other words, one thread may have loaded COMCTL32 version 5 while another thread loaded version 6. Try it – create a .NET Windows Forms application, and spin off a second thread to run your main form, except don’t call Application.EnableVisualStyles() this time (also, make sure it’s apartment-threaded.) You can use Process Explorer to confirm that two versions of COMMCTL32.DLL are loaded. But wait, there’s more! Have you checked recently how many different versions COMMCTL32.DLL are installed on your PC?

    Yep, this also means that you have detect under which activation context your sub-classing DLL was loaded, switch activation contexts, and install your sub-class a second time. If you’ve ever wondered why the common controls on your Windows Forms application retain their old behavior after installing an application that globally sub-classes the common controls, now you know.

  32. wtroost says:

    but it just seems that there should be

    something in the programmer’s head that

    says "whoa! There’s gotta be a better way!"

    There are many commercial software packages that can only be automated by Window messages.  Visual Studio even has a handy utility for capturing those events (Spy++ I think.)  If it works you can automate a lot of typing work– until the next version of the application comes out.

    Now I have no clue why someone would automate Explorer in that way.  But if all you know is sending Window messages… I guess you could copy a file by sending window messages to Explorer?  Kinda funny hehe

  33. Gabe says:

    Xepol: You do realize that Microsoft actually wants to *sell* Windows, right?

    People don’t buy computers to run Windows; they buy computers to run Windows *apps*. If their apps don’t run on the latest version of Windows, people won’t buy it.

    [Don’t waste your breath. Xepol wasn’t convinced last time this topic came up. I don’t see why this time will be any different. It’s just a rehash of an old argument for the purpose of causing trouble. -Raymond]
  34. Evan says:

    @Xepol: "Won’t someone please get some sanity, and say "screw it, its broke because of how THEY wrote it, we warned them, its their fault, …"

    There is a fundamental problem with your proposition. By denying backwards compatibility the way you are suggestion, *MS wouldn’t be punishing the companies publishing misbehaving software,* at least directly. They would be punishing the people who BUY misbehaving software. And the problem ISN’T their fault.

    How should I, as the purchaser, know if Product X tries to hook undocumented structures, and Product Y doesn’t? And if Product X works under Windows version N but fails under Windows version N+1, depending on how important Product X is, I may stick with version N. If so, I’ll tell people that I can’t upgrade to N+1 because Product X doesn’t work. [Those are my anonymizations; I don’t have any specific examples in mind.]

    One of the major reasons Windows is as successful as it is is because of the lengths MS goes to maintain backwards compatibility. If I need to re-purchase a chunk of my programs if I want to upgrade (or need to for other reasons) because they don’t work or don’t work as well, that lowers the bar for how easy it is to switch to, say, Mac. "Oh, well, I won’t be able to run Product X on my new computer anyway; so I need to buy Product Z instead. I could buy the Mac version and switch" vs. "If I upgrade to Windows N+1, I can continue to use Product X. If I upgrade to a Mac, I need to buy Product Z to replace it. Option 1 is cheaper."

    It’s an interesting question why other OSes don’t seem to have a problem with this. Is it that they take the attitude that it’s the program’s fault, and don’t support it? At least in the case of Linux this may be the case, since many of the most popular programs are open source and free. (Essentially then the second option above — switch and buy Product Z — looks okay, because Product Z is now free.) Is it that there are fewer badly-behaved programmers on other systems because they are less popular? Does MS’s attitude of maintaining compatibility at almost any cost help produce an attitude of "MS won’t break it, so let’s do it"? I don’t know.

  35. A Bad Coder says:

    Raymond: If you say "This operating system won’t last long" and it lasts 25 years, then I ask you to provide your definition of "long".

    But I said it wouldn’t be maintainable, and I counter than Windows hasn’t been maintainable for at 20 years.  It’s lasted that long by market forces allowing Microsoft to throw billions of dollars on it.

    Harding:  [ mac backward compatibility sucks ]

    Imagine if Apple had the resources to put as much effort into backward compatibility as MS.  Microsoft spends a ridiculous amount of money on maintenance like this.  After they got OS 9 program support completely bug free they’d have so much left over to do Apple II and throw in perfect rendering of Amiga demos.  Ok, I exaggerate a little.

    What would be awesome is for Microsoft to put 100 engineers (actual SEs) on Singularity as a skunk works and start it over from scratch without polluting it with Win32 this time… make that a ‘time machine’ that allows existing programs to run as a separate emulation.

  36. Ulric says:

    I’m glad you like OS X, Aaaargh, but that’s the ‘grass is always greener’ phenomena.  OS X frameworks aren’t more modern or better documented; they’re just something else you’re not familiar with so you assume it’s better.   Apps: there are much fewer apps for OS X overall, and the bad apps, you don’t hear about.  

    In any case, Win32 doesn’t need to be abandoned.  Maybe C# and the newer APIs are better for you.  This blog is a lot about the pragmatism of application compatibility.

    Win32 is certainly not holding Microsoft back from doing anything. In fact in Vista they were able to fundamentally change the system and add desktop compositing on top of all the existing applications, and it all works with existing apps.  

    What the APIs are and looks like in fact just syntactic sugar. Junior programmers always think you need to delete everything and re-start from scratch to do new things, but that’s just laziness or lack of experience.  And that’s not what this blog is about.

  37. Ulric says:

    btw I wanted to say our application subclass dialogs and controls in Windows, and I’m aware of a few others that do as well.

    These apps are really sensitive to changes in the way combo boxes, check boxes, edit boxes and buttons, the way Raymond suggests.

    re: The post above by "WikiServerGuy" about the Message box change in Vista.

    We had that problem.

  38. Marc K says:

    @Raymond: "An app that looks uglier on Windows N+1 than it did on Windows N counts as an app that fails the app compat criteria."

    ALL apps on XP that don’t have the XP common control manifest look uglier than on Windows N-1 because they are using controls that don’t look right amongst the rest of the programs.

    @Skip; "…Visual SourceSafe 2005…"

    Skip, what are you doing using SourceSafe?  There’s 99% of your problems right there.

  39. iheath says:

    Well, whatever way you spin this Raymond, its still a "Legacy of Ashes".

    Of all the architectural gaffs that the common controls team have made over the years, I think choosing to use SxS to solve the v5/v6 problem was the worst. We’re all living with that legacy now. SxS is something that only installation engineers should even care or know about. Now we have a community of UI devs that have to deal with the nightmare of crap like ACTIVATION CONTEXTS and the like.

    The motivation for going with a SxS solution seems to have been to make like easier for the comctl team, at the expense of all the rest of us. So the comctl code needed to be forked, fine, but that should have been implemented using some kind of internal layer of indirection based on a runtime switch, so that there would still only be one DLL and one API for the rest of us to deal with.

  40. Aaargh! says:

    "OS X frameworks aren’t more modern or better documented"

    Yes they are. Their API’s are clean, no bogus parameters, no magic values that need to be passed for no apparent reason. And they are very well designed. Not only the ‘how’ is discussed, but also the ‘why’. (I had the ‘pleasure’ of having to program something against the MapPoint SOAP api a while back, and using the documentation on MSDN was a horrible experience.)

    OS X is very well designed, things aren’t needlessly complex.

    As an example, lets look at the hoops an application has to jump to to register its filetype so doubleclicking one of it’s documents starts the application: http://msdn2.microsoft.com/en-us/library/bb776875.aspx

    Basically, you have to mess around in the registry. You have to keep track of where your application lives, if you move the app the registry entry needs to be updated, etc. etc.

    To do the same thing on OS X, you have to do… nothing at all. A document is automatically opened by it’s associated application. The applications filetype is stored in an XML file inside the application bundle, which is automatically created when starting a new project in Xcode. When you copy an application onto your harddrive, the OS picks up the association and takes care of everything. Moving the application to a different location won’t break a thing.  Of course, the user can change the associated application when they want. They can even change this on a per-file basis, so Document1.doc is opened in Word and Document2.doc is opened in Pages. Very convenient. OS X is full of little things like this that make life a whole lot easier.

    Why make things difficult when they don’t need to be ?

  41. MadQ says:

    Raymond, I tried to post a comment that I thought was on-topic, and included information about some other consequences of COMCTL32 using SxS, but my comment never showed up. If you deleted it, that’s OK – your blog, your rules.

    It’s just that I don’t know whether I messed up posting it, or whether you deleted it. I don’t suppose you could just delete the content of comments, instead of deleting the whole thing? That way at least I would know that my comment did post correctly. Hmm, now that I think about it, people would probably abuse that.

    *sigh* Sadly, this kinda discourages me from posting comments in the future.

    [The blog software categorized it as spam for some reason. I went and fished it out of the Recycle Bin, but this is not something I intend to do as a regular basis. -Raymond]
  42. Landslide says:

    With all this talk of backward compatibility and Vista, here are just a few of my personal bug-bears: –

    * Full Screen Command Interpreter… not supported under Vista Aero.

    * Visual Studio .NET & 2003… not supported under Vista.

    * Embedded Visual C++ 4.0/3.0… not supported under Vista.

    For the latter two I resort to running XP in a VM under Vista. I can live with it.

    Why didn’t Microsoft focus those 5 years of energy and billions of dollars of R&D into a clean slate with _far less thought_ for those obscure backward compatibility cases you mention? It must have burnt a few neurons, not to mention time…

    Wouldn’t bundling a free VM and XP license for backward compatibility have been inordinately easier?

  43. Ulric says:

    Aaargh, you’re selectivly looking at whatever supports your point.  I’m guessing you’re comparing some GUI Cocoa against whatever you may have encountered in the whole of Win32.  I could do the same and tell you about the 2500 functions (I’m not making this up!!) of Quicktime, most poorly documented if at all MS’s WPF. You’d say I’m insane.

    I work on OS X as well, I’m writing a small MIDI app.  It’s dreadful. the documentation for the API is essentially non-existant, it’s what you get generated from the header files. example:

    http://developer.apple.com/documentation/MusicAudio/Reference/CACoreMIDIRef/MIDIServices/index.html

    how is that better than Win32 I don’t know.

    When you don’t try to do anything serious, anything looks perfect and genial.  GUI framework and toolkits are always good at that generic sample app.

    sorry that, has nothing to do with Win32 anyway, which is the point of this blog

  44. Good Point says:

    I’m baffled by a lot of the UI in Vista

    Yes, even though Vista has a 5 year gestation period it looks like it was rushed.  Which leads me to believe it will go down as the ‘Windows Me’ of the NT lineage.

    Despite what is said in: http://blogs.msdn.com/oldnewthing/archive/2007/08/28/4599238.aspx  I have still never seen ‘Log Off’ show up in the Start Menu search results.  I guess the search box is still learning about what I do most often.

  45. Ulric says:

    Sorry that example was suposed to be ‘compare the Quicktime API to MS’s WPF’.  It’s as irrelevant as comparing Win32 to Cocoa Frameworks.  My point is the new framework in Windows is already here.

  46. MadQ says:

    [The blog software categorized it as spam for some reason. I went and fished it out of the Recycle Bin, but this is not something I intend to do as a regular basis. -Raymond]

    I understand. Thanks, and I’ll remember not to mention product names next time.

  47. Evan says:

    @A Bad Coder: "It’s lasted that long by market forces allowing Microsoft to throw billions of dollars on it." … "Imagine if Apple had the resources to put as much effort into backward compatibility as MS."

    I would assert that one of the main reasons MS *has* those resources is because they put such an effort from it to begin with. I know Windows was already established at the release of Win95, but what would have happened if MS took the Mac/Linux/Unix attitude at that point and not been so aggressive about making sure poorly coded programs still ran? I strongly suspect that MS wouldn’t be in the position it is today.

    (Perhaps that’s not so much true today, but remember that at that point most people couldn’t just go online and download a patch for their broken program.)

  48. Triangle says:

    "I’m glad you like OS X, Aaaargh, but that’s the ‘grass is always greener’ phenomena.  OS X frameworks aren’t more modern or better documented; they’re just something else you’re not familiar with so you assume it’s better."

    Actually it’s a different phenomenon: You’ve been programming Windows for so long that you’ve become desensitized to how bad it really is.

    "Sorry that example was suposed to be ‘compare the Quicktime API to MS’s WPF’.  It’s as irrelevant as comparing Win32 to Cocoa Frameworks.  My point is the new framework in Windows is already here."

    That’s stellar news for those of us who don’t have to support anything other than Vista.

  49. Aaargh! says:

    "If you say "This operating system won’t last long" and it lasts 25 years, then I ask you to provide your definition of "long". -Raymond"

    Depends on the context of course, in this case, I would consider a few hundred years to be a long time for an OS to be around.

    We’ve only just started using computers, so we have no real concept of how long an average OS family lives. *nix has been around since ’69 and while it’s certainly not perfect and there are lots of things that need fixing it shows way less wear-and-tear than win32 does. I won’t be a bit surprised if it’s still around in 2069 and beyond. Actually, Apple is doing a pretty good job of modernizing *nix with OS X.

    My point is, calling 25 years a ‘pretty long’ time is a bit pointless when there is not much to compare it with.

    When is MS planning on retiring Win32 ? With their current attitude towards backwards combatibility they won’t be able to, ever. You can’t break backwards compatibility because that would release MS’ stranglehold on the OS market and there would be no need to keep using an outdated OS like Windows.  At the moment the win32 software catalogue is the *only* selling-point for win32 over other OSes.

    So how do you plan on keeping it all working for the next hundred years ?

    I see three distinct options

    1) maintain the current state and in a few more years it will be impossible to keep up with the rest.

    2) break compatibility, clean it all up, lose market share to competitors.

    3) drop win32, build en entirely new, clean, OS. (Singularity is supposed to be pretty cool) and try to lure customers to this new platform as win32 fades into obscurity.

  50. Aaargh! says:

    "I would assert that one of the main reasons MS *has* those resources is because they put such an effort from it to begin with."

    That may very well be true, but that’s just marketing and business and short term thinking. I don’t care about those, I care about the technology and the long term.

    As a counter point: look at the quality of software available for the OS X platform. In my opinion the available commercial and freeware for OS X is, in general, of much higher quality than that on the win32 platform, with cleaner and better designed user interfaces. In my limited experience programming for OS X / Cocoa the quality of the frameworks offered by Apple is very high and the documentation is excellent. It could be that this motivates developers to also write clean code. Or maybe it’s that the expectations of the average Apple user are just higher than for the win32 crowd.

  51. WikiServerGuy says:

    ALL apps on XP that don’t have the XP common control manifest look

    uglier than on Windows N-1 because they are using controls that don’t

    look right amongst the rest of the programs.

    Well, I think he meant literally if they look worse then before, but still it is a point. I’m interested if there is a better way to do it, I imagine it would require a LOT of deep thought about the issues involved. Also, when it first came out, people did complain about the manifest-related issues like crazy – much like people (including myself) bloviate on Vista issues – at the time, mostly due to lack of IDE support at the time.

    People would (and some still do) put the manifest directly in the resource file or something and then get duplicate errors when they loaded it into MSVC; so they would put actual #defines in the resource itself. Then a lot of other fun issues arose….

    Anyway, back to the subject at hand. In Vista they take a different approach with the menus – if you use a certain version of the old owner-drawn calls, you get the old style menus.

    It seems like a good solution and to this particular issue isn’t the worst I guess, but then you have problems like "badly-behaved" explorer extensions (which tend to be pretty much all of the popular ones) causing explorer itself to have old-looking right-click menus. Plus, Microsoft a lot of the time doesn’t even follow their own rules (see favorites menu in IE, for example). Then of course there is the mandatory IconToPARG32 routine that you end up writing, but that can’t really be avoided.

    Makes me wonder what would happen if they tried to apply that solution to the XP common controls issue. I’m not sure how they could do it though – maybe revert to old-style control if you subclass it perhaps? Problem with that is most complex apps subclass most controls, so realistically you’d have an application with mostly old-style controls and some new-looking ones. Plus, ones written before often worked around legitimate problems like flicker (yeah, I can’t think of anything better ATM), so it would penalize those apps.

    You can even have a new flag to GetWindowLongPtr that would set the wndproc but also signify that you know what you are doing or something. Still, I can imagine that some applications that do some really evil things outside of subclassing that could conflict with it.

    Just another (probably awful) idea. Curious about other ideas as well.

  52. Dean Harding says:

    "That’s stellar news for those of us who don’t have to support anything other than Vista."

    I think you mean: "That’s stellar news for those of us who don’t have to support anything other than Windows XP, 2003 and Vista".

    But anyway, that wasn’t even the point Ulric was trying to make. Cocoa is a new framework. WPF is a new framework. You can’t run a Cocoa application on a version of Mac OS released before 2001 and you can’t run a WPF app on a version of Windows released before 2001. Seems like a much better comparison to me.

  53. WikiServerGuy says:

    Since most modern OSX apps are made using bindings, realistically at the very minimum it is late 2003+ (10.3).

  54. Dean Harding says:

    "My point is, calling 25 years a ‘pretty long’ time is a bit pointless when there is not much to compare it with."

    There’s plenty to compare it with. You cite "*nix" as your ONE AND ONLY counter example, but I can find dozens of operating systems that didn’t last as long as Unix or Windows.

    This page on Wikipedia has plenty, most of which are now defunct: http://en.wikipedia.org/wiki/List_of_operating_systems

    Besides, typically, Unix has had a very different development model to Windows. Windows has always been sold as a consumer (or desktop at least) operating system. However, for the vast majority of Unix’s life, it was sold as a "holistic" solution. You bought your hardware, operating system AND application(s) all from the same vendor. So you didn’t typically have the same backwards-compatibility constraints that Windows has had. When you wanted to upgrade, you called IBM (or whoever your vendor was) and they sent you a *whole new mainframe* software and all.

  55. anonymous says:

    Speaking of common controls, I have one question. When I run apps under Vista that already have a XP-style UI manifest, they don’t get the Vista look. If I run them in XP SP2 compatibility mode, then they get the Vista look. And later if I remove the compatibility mode check box, they retain their Vista look. Why is this? Same thing happens for apps that don’t have a manifest but when a manifest file is added.

  56. Stephen Jones says:

    As another poster mentioned, anybody who claims Apple software is superior to Microsoft has a lot to do explaining away QuickTime, one of the most horrible pieces of software to disgrace a computer.

  57. Anonymous Coward says:

    “Even though it’s completely undocumented and unsupported, programs like to grovel into the internal data structures of other programs or otherwise manipulate those programs’ windows.”

    I understand the desire of Microsoft to do whatever is humanly possible to maintain backward compatibility even in these cases, but surely this has to stop one day? If for no other reason, then because of security? A plug-in for safer registry editing might be cool, but an interception layer between the user and the registry definitely isn’t.

    http://blogs.msdn.com/oldnewthing/archive/2008/01/29/7294949.aspx#7326619  seems to be the only viable solution to me: why keep adding convoluted ways of doing things that should be easy to the OS and incur mounting costs of providing backward compatibility when you could cover all those issues by providing a VM with a (nowadays, rather cheap) XP license on it? The later this will happen, the more applications will have problems with it, and if it never happens, then the performance of Windows will suffer, which is a real bad thing.

    [Running old programs in a virtual machine doesn’t necessarily create a good user experience. -Raymond]
  58. Ross Bemrose says:

    AAargh!:

    (Note: I’m intentionally using different cases for Unix and UNIX… Unix for the AT&T operating system and UNIX for the Open Group certification/trademark)

    Unix as a counter-example only works if you’re not talking about AT&T/USL/Novell/SCO Unix and instead talking about UNIX-certified POSIX-compliant operating systems.

    After all, Unix is one of the few operating systems that isn’t even written in the language it originally started with.  It’s true that Unix was written in 1969.  However, it was re-written in 1973 using a programming language custom-design to write OSes in.  That language is C.

    I could go on more about history, but what really matters is how things look today.

    Un*x/POSIX currently has 5 major operating system families that I’m aware of: Linux, BSD, Solaris, AIX, and Unix itself.  Software written for one may not run on the others.  There are both shims (#ifdef) and programs (configure, autoconf) to get around incompatibilities, but it’s one of the underlying problems you must consider when you’re writing programs expected to run on multiple different Un*x platforms.

    In other words, UNIX/Unix/Un*x isn’t as homogenous as you think.

  59. Ulric says:

    Thanks Dean Harding, right on the money.

  60. Anonymous Coward says:

    [Running old programs in a virtual machine doesn’t necessarily create a good user experience. -Raymond]

    In that case, is anything being done at all to if not prevent, then at least discourage people from using quirks which obviously shouldn’t be supported? If there’s no real downside to writing dodgy code which just happens to work right now ("well, the guys from Microsoft will fix it anyway if the product ends up successful, so why bother?"), you will always be swamped by applications which refuse to adopt good design; and the compromises made during accommodating those applications to the new environment will keep the said new environment from reaching its potential.

    (This is of course under the assumption that producing an emulator is out of question. Given the system requirements for Vista, I would think that if a program could run under XP’s minimal requirements, then even doing some sort of software emulation could be acceptable on a modern machine capable of running Vista)

  61. Alex Cohn says:

    One of the strangest common controls (well, not exactly) is the Wizard mode of Property Sheets. I believe that it is much easier to use a sequence of normal dialogs than to tweak a property sheet to do exactly what your PM wants. Take the limitations the Wizard97 poses on the sizes of the images (the "icon" must be 49×49 pixels)!

    It’s puzzling that behavior of Wizard97 depends on the compilation flags: use _WIN32_IE=0x0400 to get a header bitmap stretched to the width of the wizard window, or _WIN32_IE=0x0500 to get it clipped to 49×49 pixel.

Comments are closed.