As everyone must know by now, the Windows 7 Release Candidate is broadly released and available for download from the Windows site. The RC build is essentially our dress rehearsal: we’ve hit feature complete, stabilized the release, followed the active bug glide path down to zero, and the build is essentially at a point where we’re looking for any last remaining “showstopper” bugs that might be lurking. To switch metaphors, it’s our last chance to verify that all systems are go before we hit the big red ‘launch’ button and start manufacturing tens of millions of copies of the software for broad distribution.
What does this mean for you, my esteemed developer readership? Now is the time when you really want to be putting the product through its paces: checking your own applications for any compatibility issues that might generate support calls, taking advantage of our test harnesses to ensure that your applications run well on Windows 7, and starting to take advantage of the new APIs in Windows 7 that can make your application feel like a native citizen of this new operating environment and enable new features that your customers will appreciate.
Let’s split that apart into a little more detail.
Compatibility Application compatibility is always something that’s on our mind when we’re building a new release of Windows. With many tens of thousands of applications that rely on both documented and undocumented behavior from the myriad APIs that we’ve introduced over the last couple of decades, it’s never easy to innovate while ensuring that nothing breaks. Raymond Chen’s blog is littered with examples of where we’ve had to go to extreme lengths to ensure that we even work around applications that relied on buggy behavior.
In some cases, there’s a deliberate trade-off that has to be made between two important tenets. For example, in Windows Vista, we introduced User Account Control to increase security for end users even though we knew that it would pose a challenge to certain applications that assumed full administrative rights. We spent a lot of time attempting to mitigate that risk, adding ‘shims’ for certain applications that we knew in advance required privileged rights to run successfully, and introducing features like file and registry virtualization to provide a fallback solution for other applications.
The good news is that with Windows 7, we kept the bar very high indeed for breaking changes. If an application runs on Windows Vista today, there’s a very strong likelihood that the application will run unchanged on Windows 7; this has been borne out by early adopter tests running on the beta and release candidate to date.
Nevertheless, there are four key steps we’d love every application author to take in the next few months to still further diminish the risk of any application issues:
Taking Advantage of Windows 7 Assuming your application runs on Windows 7, the optional next step is to take advantage of one or more of the myriad new features in Windows 7 that can give your users a better experience, while of course still supporting Windows XP or Vista where appropriate. To call out a few specific examples:
I could go on, but but perhaps I’ll save a more comprehensive list of new developer features for another blog post!
There are two main kits you’ll want to download and install on your developer workstation to take advantage of Windows 7:
It’s an exciting time to be a Windows developer: as we enter the home stretch for this release, I’m enjoying seeing examples of applications that build on the platform from the largest software development companies down to individual ‘cottage’ developers. What are you up to?