Why does upgrading my project to Unicode cause Visual Studio to use a different version of the common controls?


A customer was upgrading a program from Visual Studio 2008 to Visual Studio 2017. As part of the upgrade, they also decided to recompile it as a Unicode program rather than an ANSI program. And they bumped their WINVER from 0x400 to 0x600. All together, these settings mean that they dropped support for Windows 95, Windows 98, Windows Me, as well as Windows NT 4.0, Windows 2000, Windows XP, and Windows Server 2003. Given that all of these operating systems left extended support quite some time ago (although Windows XP stubbornly held on way past its best-if-used-by date), these updates were long overdue.

The customer found that as a result of these upgrades, the project also switched from using version 5 of the common controls to version 6. This was not something they expected, since it's not anything they explicitly asked to be upgrade to. What happened?

It was the combination of the two other upgrades that triggered the switch from version 5 to version 6.

Version 6 of the common controls was introduced in Windows XP, so it has as a prerequisite that your WINVER be set to at least 0x0501, since that is the value that corresponds to Windows XP. If you choose a lower value, then you are saying that you are targeting a of Windows that predates version 6 of the common controls, and therefore trying to use it will never work.

Version 6 of the common controls is also Unicode-only, with some concessions for older messages. If you build your project for ANSI, then the project can't use version 6 of the common controls because it's using the wrong character set.

But once you set your project parameters so both of the criteria are met, then version 6 of the common controls becomes available.

If that's not what you want, then you'll need to say, "Hey, like, I know I meet all the qualifications for using version 6 of the common controls, but I don't want to." It appears that if you create a new MFC project, then the IDE will enable version 6 of the common controls automatically once you enable Unicode, so that could be where the manifest magic is coming from.

Comments (26)
  1. yukkuri says:

    Why would they not want to use version 6?

    1. kantos says:

      The “Who moved my cheese” factor. Some clients get very annoyed when things change because that’s what they know and like.

      1. The MAZZTer says:

        In this case, the cheese is ugly, unthemed controls.

        1. kantos says:

          Not disputing that in the least… that doesn’t mean the client won’t get whiny over it. I know in particular Defense contractors would scream about this sort of change even though it’s actually probably more secure. They assume any change they didn’t explicitly approve is malicious.

          1. Douglas Hill says:

            “[…] They assume any change they didn’t explicitly approve is malicious.”
            I think (anecdotally) that it’s more like a variation on the “[…] unexpected performance improvement”: https://blogs.msdn.microsoft.com/oldnewthing/20121123-00/?p=6013/
            It’s a cosmetic change, but it’s still a change. All changes have to be tracked down and approved.

        2. Joshua says:

          I had to explicitly track down the switch and throw it back. Combo boxes and combo editors mixed on the same form look really bad now.

        3. alegr1 says:

          Hey, Windows 10 has feelings, too!

      2. Simon Clarkstone says:

        Spontaneous changes can also be the symptom of a hidden problem unless you can account for them. If you find yourself using Thing B when you expected to be using Thing A, that might mean Thing A has gone missing and the system is falling back to Thing B. Or, if my compile times went from 10s to 1s, I’d be very suspicious that this “improvement” was due to the compilation not working properly, or operating on the wrong set of input files.

        From the other side, there is no such thing as a guaranteed-safe upgrade. Your code might be relying on (e.g.) memory not being re-used or other undocumented behaviour of the library.

      3. yukkuri says:

        Of course. Why did I even need to ask…

  2. Leonardo Herrera says:

    How I wish XP was gone. But it’s like a zombie that keeps crawling back.

    1. Antonio Rodríguez says:

      “The OS that would not die” – what a title for a Z-series zombie movie! I picture zombies crawling out of their tombs, holding Celeron laptops running Windows XP, the sinister sound of wind in the dead trees branches only rivaled with the chilling sound of the laptops’ dying fans…

    2. cheong00 says:

      Since it took about 10 years since the end of support of Win98 for it to go away, I’d expect the duration to be similar or longer for WinXP, given the inertia it gained these years.

      1. cheong00 says:

        Btw, who knows when these organizations will stop paying support contract for WinXP?
        http://money.cnn.com/2015/06/26/technology/microsoft-windows-xp-navy-contract/index.html

        Around 2011, my ex-company still have customer paying big amount to maintenance contract for us to support DOS version of out stock trading system (yup, that’s why they were still using Win98). If the last staff that knows how to support it go retired, I would not be surprised if that company is still using Win98 with that system now.

        1. cheong00 says:

          DOS version of out stock trading system to DOS version of our stock trading system

        2. Daniel Neely says:

          IIRC MS’s pay $tupdily Big Buck$ for post end of life XP support was only going to run 3 years; which means that unless the corporate legacy customers used the I’m a Cash Register registry hack (XP POS Ready 2009 still has a year and a half of support left) they’ve been out in the cold since this April.

          1. Daniel Neely says:

            Of course being out of terminal support doesn’t mean it’ll all just go away. Up until last September I was producing data used by a Navy system whose UI was built around NT4 embedded. The need to make weapon systems as light and compact as possible left them with no easy upgrade path. The PC NT4 was on was too old to run 7 at all or XP well (p3 w 256mb ram); and was a non-extractable part of a 6 figure box. A program to replace that box (and a number of associated components) was on the plan for a decade ago; but was dropped when the platform unexpectedly developed a to mechanically worn out to be safe problem that devoured all the other upgrade funds. The whole platform’s in the process of being replaced now: and between total support funds shrinking with the number of platforms remaining in operation, the replacement platform taking over the missions where updated data would be most important, and the amount of govt bureaucracy between the data getting to the govt and it finally being fielded they let the contract I was on wind up instead.

            I wouldn’t be surprised if other equally ancient systems are still around another 10 or 20 years from now. Even more than industrial machines and scientific/laboratory instruments weapon platforms have natural life spans far beyond the support period of any major software platforms.

  3. Ivan k says:

    Man I love that retro look.

  4. Dennis says:

    One other thing that Raymond forgot to mention about switching your project from VS 2008 to VS 2017 is that if you’re using MFC, every compiled executable in a Release build may add a couple of MB in size for the exact same code you compiled in VS 2008. (Especially if you’re building with static linking to MFC to avoid dealing with the “DLL-hell.”)

    Also, I’m not sure what kind of for-profit company would be willing to neglect 6.47% of the market share for their software by making it not compatible with Windows XP? I mean, don’t get me wrong. As a developer I absolutely hate Windows XP! That is the most bug-ridden and insecure OS Microsoft ever created (in this century.) But from a marketing perspective, not supporting Windows XP is not something I would want to do at this point in time. If we assume that there are roughly 1 billion installations of Windows out there, you’re ignoring 64 million systems.

    Here’s the metrics, by the way (or you can Google “Windows XP market share”):
    https://www.netmarketshare.com/operating-system-market-share.aspx?qprid=10&qpcustomd=0

    BTW, Windows XP still has a larger market share than Windows 8 :)

    1. Mark (The Other Mark) says:

      “TW, Windows XP still has a larger market share than Windows 8”

      Makes sense, doesn’t it?

      If you can’t upgrade, or fear upgrades, you’d be on XP. You’d never have gone to Vista+.

      If you like to upgrade, you’re probably already on 10.

      If you’re a large Enterprise (say, 30k+ endpoints), you skipped Vista, went to 7, skipped 8, refuse to accept that 8.1 was any different from 8, and are slowly moving to 10 now.

    2. On the other hand, the people still running Windows XP have demonstrated that they don’t upgrade anything, so they’re not going to install the latest version of your app either. They’ll keep running the version of your app from 1998.

      1. Dennis says:

        Yes, I agree. I’m just approaching it from a marketing standpoint as well.

        PS. Like I said, coding for XP now (end of 2017) is not my favorite thing to do.

        1. Dear Marketing Department: None of the people in the market you identified are going to buy this or any other product, no matter how good it is.

      2. ender9 says:

        How I wish this was true. Unfortunately, some XP users do whine loudly when your latest version requires at least Windows 7…

    3. Daniel Neely says:

      At best the XP > 8 claim is only supportable by splitting 8 and 8.1 apart even though MS has treated the latter as a service pack and EOLed support on 8.0.

      Netmarketshare puts XP at 6.5% vs 6% for 8.1 and 1.4% for 8,0. Statcounter has XP at 3.9% vs 9.0 and 2.6% for the 8.x versions.

  5. Victor Derks says:

    It is very interesting that they were surprised. Upgrading a MFC program from MBCS to UNICODE is not difficult, but needs to be done carefully. There a lot of places in the code that may need a fix (count of characters, vs bytes in an API cll, forgotten _T() macro’s, etc, exporting and importing text files, etc).
    Using the common controls v6 in a MFC application is often controlled by the following code (simplified version):

    #ifdef UNICODE
    #pragma comment(linker,”/manifestdependency:\”type=’win32′ name=’Microsoft.Windows.Common-Controls’ version=’6.0.0.0′ processorArchitecture=’*’ publicKeyToken=’6595b64144ccf1df’ language=’*’\””)
    #endif

    These statements will be put into your source code when you generate your MFC application for the first time. A global search for UNICODE in the source code of the application that needs to be ported would be a first good step.

    1. Dennis says:

      Victor, it sounds like it’s a trivial issue, but it’s not. I did it for a couple of projects and it was a nightmare! There’re tons of places where compiler may not catch it. For instance, printf() type functions (unless you replaced them with the *_s counterparts and use the latest version of Visual Studio.) Otherwise, I’m still finding bugs in some projects that were converted years ago. It’s way too easy to rely on an automated refractor and gloss over some branch of code that is rarely executed that may crash the thread later on.

Comments are closed.

Skip to main content