We’re in the middle of the first development milestone for Orcas. If you’re an avid blog-reader, you’ve probably already heard that we’re running our development process a little differently this time, in an attempt to be more agile. We’re putting each piece of functionality into its own ‘feature branch’, where it has to live until it is at a standard that is free of known bugs and much closer to ready to ship. A small set of developers/testers and others focus on the feature until it’s done (we call them a ‘feature crew’) We hope this will keep our shipping branches at a higher quality, and also ensure that things don’t make it into the product until we know they are in good enough shape to not delay our release. Of course, building a product this large is complex and diverse, so not every feature can fit into this model, but it’s the general plan we’re using. So far it’s working out well, but of course the proof of a plan like this will only really come later in the product cycle.

Right now, my team is working on three feature crews, and a fourth is about to spin up. I’ll start by talking a bit about each of these.

For some years we’ve been watching with excitement as the MSBuild team built a new build system from the ground up. Several people who have worked for me in the past were involved in the MSBuild effort, and I think they’ve done a great job re-imagining this part of our product from scratch and producing a next generation solution to the problem. We took the decision a few months ago to migrate all our VC builds to use MSBuild, and we’ve had a feature crew working on it for a couple of months now; they’re just getting close to complete. I’m really excited to see the new build coming out. One great result of this has been a total spring-clean of our old builds. Though they are still some of the most complex builds in the division, they’re more comprehensible and better understood than they’ve been in years.

Development process: One of the things we need to do at the start of almost every product cycle is rename our library DLLs. You might wonder why we do this. It’d clearly be simpler for you if we kept our DLL names, and their binary contract, the same across multiple versions. For some parts of our libraries, it’s actually possible to imagine doing that and we seriously consider it. The CRT doesn’t change substantially every version, and because it is a pure-C API, when the CRT does change it can often be done in a compatible way. In our last version we made some non-compatible changes [for example, we widened time_t to 64 bits]. Other parts of our libraries have a greater need to change. Given the way C++ classes version, it’s not really possible to make significant changes to our STL or MFC without re-versioning the DLLs that contain those classes.

Our experience has taught us that if we are making significant fixes or changes to our library components, we should re-version them. We work hard to remain source compatible, but do not need to worry about code compiled with the previous version of the product running on the current version. Our development process is just finishing the process of renaming the DLLs; we already have private copies of our newly minted, shiny msvcr90.dll and mfc90.dll to play with.

This team is also working on a fascinating internal process change that’ll significantly increase our dogfooding and reduce the complexity of our work. But I don’t have space to go into that here.

We and Dinkumware started work again soon after Whidbey shipped, and now have a version that meets a lot more of our original goals. In particular, since last October we’ve done some fascinating optimization work to understand what really drives the performance of a template-based, generic-based library like this in managed code. We’re not finished yet on performance, but in informal testing we’ve seen some exciting results, including a bunch of cases where the magic of templates combined with the C++ optimizer are able to outperform the .NET Base Class Library even in verifiable code. When we envisioned C++/CLI several years ago, these are the kinds of scenarios that we dreamed of, and it’s exciting to see them coming to fruition.

We’re about to spin up a feature crew to integrate the current version of STL/CLR into Orcas. This will just be a snapshot of our current state, but it should allow us to get feedback from some of you in a future Customer Technology Preview. Lots of things will still be incomplete in that release (because we still have future milestones working with Dinkumware to complete the remaining parts of the library), but it should be enough to enable you to get a flavour of the implementation, and try it out and send us feedback. We’d love to hear your experiences.

Servicing: Another group that’s always running is our servicing team. Its job is to deal with incoming bugs in existing features, create QFEs and service packs, and help internal and external customers who contact us via various routes. We rotate membership of this group through our whole team, which gives everyone a chance to work on the broad spectrum of libraries technologies. I do some part-time help for this group too, and I find these issues especially fascinating – it’s always really illuminating to see how people are using our product, and learn what we can do in future versions to increase productivity and reduce pain.

Planning for Vista UI: Orcas is a Vista-focussed release, and once we’ve completed the development process work described above, we can start the serious work of updating our libraries to do a better job targeting Windows Vista. The VS IDE and MFC both need to know about a raft of new controls, messages, and other Windows elements. If you look back at Windows XP, you’ll see that almost as many controls were added in that version of the operating system, and we didn’t have time to add those when Windows XP shipped (in August 2001, just before we shipped VS7). So we’ve gone back and looked at all the missing controls and UI elements back through Windows XP, so we can try to get all of these into Visual Studio Orcas. This is a big planning job that’s only partly complete, but we’re still working on this as we expect to start implementing these new controls sometime in the next 6 weeks.

I get lots of mail from customers about various subjects. It’s very welcome, and I encourage you to mail me too. I can’t always respond promptly, but it is always read, and I’m sometimes able to help people a little bit. The features of our next product are shaped in part by the feedback we get from you through channels like this, so do make sure your voice is heard. Get in touch – keep the dialog going!

Thanks for using the product, and for your feedback,

Martyn Lovell

Development Lead

Visual C++ Libraries