Thoughts on VC++ bug fixing

Reader Norm vents some frustration about the VC++ bug fixing policy expressed on the VC++ team blog:

>>Microsoft has made it pretty clear not only to me but even to MVPs that VC++ is not a product where bugs are going to be fixed in the next release. <<

The situation here is really much better than you seem to be reading into it, so let me explain.  First, an important fact: we will have fixed more bugs between VC 2005 and Orcas than any other two VC++ releases in many, many years.  VS 2005 Service Pack 1 will contain much of this quality work, and Orcas will contain fixes that came later in the cycle or were too invasive for the service pack.

I also want to point out that we made a conscious process decision to spend several months of focused time doing nothing but fixing bugs (with customer-reported bugs having the highest priority, I might add).  We called this our quality milestone, or MQ, and it's been discussed on various MSDN blogs as well as Channel9.  Investing in MQ in the pre-Orcas cycle enables us to devote more resources to feature work during the Orcas cycle.  We could have just as easily done what we've always done, which is to start the Orcas cycle with no MQ and interleave bug fixing activity with ongoing feature work.  Instead, we chose to organize things a little differently, and for the better I would argue, as we'll turning around more bug fixes in the upcoming releases than we have in a long time.

Another important point I want to make is that we have made the decision to refactor/rewrite certain portions of our code base rather than simply fix bugs in these areas.  Almost all of this work is long-lead, post-Orcas stuff, but it is major work and absolutely the right thing to do for the product.  I can't yet talk about the specifics of what we're working on, but I will in the not-too-distant future, and I expect VC++ developers to be very pleased when we do have that discussion.

Comments (10)

  1. me says:

    I have to admit, I too have been having some doubts regarding the Orcas release of VC++. In the last week, more than a dozen verified but postponed bugs that I had been watching were closed "won’t fix", one after another. Refactor / rewrite is fine, but as you indicated, they are post-Orcas. So, what should I look forward to in Orcas, the next release? I’m sure there are new features being worked on, but at the moment, I am more concerned about the real bugs that exist now.

    While I wish Orcas a success, I do have my doubts.

  2. Andre says:

    VS2005 is pretty much useless for C++ development, managed and unmanaged.

    C++/CLI is great, the C++ compiler is fast and ISO compliant, support 64-bit CPUs, integration of WinForms / MFC is ok but the IDE is just poor.

    Intellisense is a nightmare, the property pane outdated (__gc ????) and the IDE crashes every 5 minutes.

    I’ve VS2005 installed for a while but continue to use VC6, maybe we should ask for a refund.

    Visual Assist X really makes me more productive, but not VS2005.

    I hope with SP1 I can migrate my projects to VS2005, otherwise the question might be if it must be VS.

    I also remember a PP presentation where it says "bring C++ to the CLR and the CLR to C++" (or similar), but what about unions? Why can’t I have a value struct in a union?

  3. Norman Diamond says:

    One of the "wontfix" bugs is one where VS2005 generates a resource file that it can’t compile.  Every[*] frigging project needs hand editing of the .rc file in order to get it to compile.  Regardless of whether or not we learn the incompatibilities between ISO C++ and VC++2005 (wontfix), or the incompatibilities between MSDN VC++ and VC++2005 (wontfix), or the incompatibilities between VC++2005 and Smart Devices (wontfix), etc., we always[*] have to learn how to edit .rc files by hand in order to get projects to compile.  Say all you want about bug fixing and prioritizing, and we’ll see that you’re just one more Microsoft standard.

    Even an MVP reported a bug that’s a wontfix.  I was only the fourth person to vote it a 5.  Now that I’ve voted for it, we know it will never be fixed.

    [* These are slight exaggerations.  If we stick to Japanese targets then we don’t have to edit the .rc file.  Usually.  But the exaggerations really are slight.  Maybe Microsoft is big enough that it can just target Japan and ignore the rest of the world, but other companies aren’t.  Some of us have to deliver executables with English-language versions, and every one of them needs hand editing of the .rc file because VS2005 generates garbage that it can’t compile (wontfix).]

  4. Andre, there are a couple of QFEs mentioned in the thread on vcblog that you might want to obtain to help with Intellisense issues.  Also, please do let me know whether the SP solves your problems or not.  We are very serious about fixing these kinds of IDE usability bugs.

    Norm, what is the bug#? I haven’t seen a problem that requires the .rc file to be hand-edited for every non-Japanese target.



  5. Norman Diamond says:

    > Norm, what is the bug#? I haven’t seen a problem

    > that requires the .rc file to be hand-edited for every

    > non-Japanese target.

  6. Norman Diamond says:

    > Norm, what is the bug#? I haven’t seen a problem

    > that requires the .rc file to be hand-edited for every

    > non-Japanese target.

    Moved to:

    The new feedback site is so much more cumbersome to use than the old feedback site, I’m not sure if I’m even going to keep checking back to see if updates appear in any of my other old feedbacks.

  7. Recently launched at, the VC team is attempting an almost frightening level…

  8. Norm,

    You may notice that the team did give your bug a second look:

    While I realize the answer is still unlikely to be what you want it to be, I’m glad you pointed it out so that we could take a second look.

    Thanks for asking the tough questions.  I know we’ll take some lumps in the short term, but we are committed to being up-front and opten about our process and priorities.

  9. Norman Diamond says:

    > I know we’ll take some lumps in the short term

    And Visual Studio customers will still be taking lumps for at least 5 years, until at least the version after next.

    Glad your colleagues took a second look.  Wonder if they’ll take a third look, but it’s pretty obvious they still won’t understand.  They need a second brain behind their second set of eyes, eh?

  10. Norman Diamond says:

    A Microsoft employee sent personal e-mail to inform me that they have reopened this particular bug.  Mr. Tei if you contributed to that effort, thank you.

Skip to main content