A Developer’s Guide to Preparing for Windows 7

A Developer’s Guide to Preparing for Windows 7

  • Comments 17

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
EN-w7-comp_rgb_L 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:

  1. Download (and read!) the Windows 7 Application Quality Cookbook. This is the ultimate guide to changes in Windows 7, offering 80+ pages of detailed guidance on the various different edge cases that might cause an issue with your application. (A quick perusal of the document will allay any fears of widespread change – unless the likes of ‘removal of Microsoft Agent’ is of major concern to you.) Using this document as a checklist, you’ll be able to very rapidly identify anything that you should take care of.
  2. Install and use the Windows Application Compatibility Toolkit (ACT) 5.5 and Application Verifier 4.0. These tools are valuable both for compatibility and quality, and are particularly helpful to renovate an older application that you never moved up to Windows Vista. The former provides automated tools for developers to check for issues like UAC incompatibility and setup problems, as well as administrative tools that can be used to apply and view other shims that may be in place. The latter tool is a runtime verification tool for applications that can be used to identify issues in the way native code calls into the Win32 API – in some ways, it’s the closest equivalent to FxCop for C++ code.
  3. Get your application certified for Windows 7. Applying for a logo for your application has historically been a somewhat painstaking process – it’s involved spending money on submitting the application for manual testing. Now it’s much simpler: we’ve provided an automated toolkit that tests the application for known compatibility issues, targeting application issues that we’ve seen in the wild and providing clear guidance on how to fix your application. And there’s no cost either, beyond signing up for a certificate for WinQual registration. Whether or not you actually care about using the Windows 7 logo for marketing purposes, this is a worthwhile step to validate that your application runs smoothly on Windows 7 and that your customers will get a good experience.
  4. Lastly, we’d obviously greatly appreciate it if you’d be kind enough to update the “system requirements” page on your web site to call out your support for Windows 7!

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:

  • Multi-touch: enabling your application to take advantage of new devices like the HP TouchSmart desktop and notebook that support gestures to zoom, manipulate and control a user interface.
  • Taskbar: adding support for new taskbar features in Windows 7 such as jump lists, progress bars, icon overlays and custom thumbnails.
  • Libraries: taking advantage of the new common file dialogs in Windows 7 that support the library model of virtualized views over multiple physical folders.
  • Sensors and Location: new APIs that enable suitably-equipped machines to report ambient light, user proximity, accelerometers and even geographic location.
  • Direct2D, DirectWrite and Ribbon: replacement libraries for 2D and text rendering as well as the Windows 7 ribbon control that is an evolution of the ribbon in Office 2007.

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:

  1. The primary resource remains the Windows SDK (available both as an ISO image and for web-based installation) – this provides headers and libraries, tools, documentation and samples for building for Windows 7 (as well as older releases). We’ve recently updated this to support the RC; although we’ll ship an updated version for the final release of Windows 7, this release is more than suitable for use for production development. You’ll find API reference documentation for all the features listed above, along with some new tools (such as a ribbon XML markup compiler). Most developers have a subset of the Windows SDK already installed as part of Visual Studio, but you’ll need to install this later build if you want to target new APIs in Windows 7.
  2. If you’re a .NET managed code developer, then you might be a little nervous of using the new Win32 COM-based interfaces and rather low-level samples included in the SDK. We’ve made great strides in Windows 7 to ensure that these interfaces are easier to consume from managed code, but nevertheless this can be somewhat daunting if you’re not acquainted with the COM interop libraries in .NET. The good news is that we’ve invested in building some great interop assemblies and helper classes to provide a seamless experience for .NET developing against Windows 7, and you can find the first fruits of this project in the Windows API Code Pack for .NET, available today from the MSDN Code Gallery. The current version includes support for many of the features listed above, with more coming both in future releases of the code pack and in a forthcoming release of the .NET Framework.

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?

  • PingBack from http://microsoft-sharepoint.simplynetdev.com/a-developer%e2%80%99s-guide-to-preparing-for-windows-7/

  • Tim Sneath har skrivit en lång och väldigt matnyttigt bloggpost med bra information och länkar för dig

  • Thank you for submitting this cool story - Trackback from DotNetShoutout

  • You've been kicked (a good thing) - Trackback from DotNetKicks.com

  • We use Microsoft Agent for all our business simulations!!!

    What alternative are you offering?

  • We've been looking forward to this for some time.  Great to hear good news on the progress!

  • ... well the older ones that we still sell 1,000s of units of a year.

  • I really like the Windows API Code Pack, but it needs better downlevel support for apps that will light up with Win7 features on Win7 but can still run on Vista. Right now when I run the samples on a Vista machine I get a Fiery Death Exception.

    I posted a discussion item about that on the Windows API Code Pack site on CodePlex, still waiting on a reply: http://code.msdn.microsoft.com/WindowsAPICodePack/Thread/View.aspx?ThreadId=1667

  • DotNetBurner - burning hot .net content

  • This week on Channel 9, Brian and Dan discuss the top developer news, including: - Windows 7 RC is available

  •   Como saben ya contamos con la versión Release Candidate de Windows 7 en la calle. Esto no solo

  • We too use MS Agent for our internal tutorial guides. Won't the runtime be supported for the lifetime of Windows 7?

  • Is there any news about the Windows 7 HIG?

  • I was anticipating the release of Windows 7, at least until I heard about the retiring of Microsoft Agent. We use this technology heavily, so we will have to reconsider our choice of OS platforms.

  • Thanks for the great post.

    I wondering why a new API was needed to do 2d graphics and text(Direct2D and DirectWrite).  Why not fix GDI+ ?

    How do these new technologies relate to WPF ? I was under the impression that WPF was the future for GUI in Microsoft.

    Felipe

Page 1 of 2 (17 items) 12