By Mike Gunderloy
You’ve no doubt seen various versions of the “Certified for Microsoft Windows” logo over the years. Certainly, there’s a marketing component to this, but there are also fairly strict technical requirements. As Microsoft releases new versions of Windows, it also specifies the coding standards that applications must meet to display the certification logo.
For example, applications must install without requiring a reboot, handle laptop suspend mode correctly, and support smart card logons to qualify for the latest version of the logo. Compliance is determined by VeriTest, an independent testing lab, and can require a substantial investment of time and money. The “Designed for Windows XP Gold” certification, for example, has a base price of $3,000 and requires five to 10 working days if your application passes the first time.
Recently, Microsoft has done some work to make it easier for vendors to verify their compatibility with the logo requirements before going to VeriTest. In particular, it has created the Windows Application Verifier, a program that will detect many common logo requirement violations. You can download the latest version, 2.50, as part of the Application Compatibility Toolkit from Microsoft.
As a consultant, though, you’re probably not building shrink wrap software for retail sale. Why then, should you even care about the Certified for Microsoft Windows logo?
Actually, you should care about the requirements for the logo, which are what the Windows Application Verifier checks. These requirements are not simply arbitrary hurdles set by Microsoft. Rather, they embody a large number of best practices for Windows software. If your application passes the checks, it should be usable by roaming users and nonadministrative users and be future-proofed against many possible Windows changes, among other good things. These are worthwhile goals, whether you’re developing software for the mass market or just building a system for a particular client.
The verification process
After installing the Application Compatibility Toolkit, you can launch the Windows Application Verifier from the Start menu. Figure A shows the initial view of the tool. To the left is a pane that will list the applications you’re testing; to the right is a pane where you can enable and disable the various tests.
The first step is to use the Add button to browse to the application that you want to verify. Then, use the check boxes to the right to select the tests to run. You need to be at least a little selective here, rather than just checking everything. For example, the Stacks check is most appropriate for a Windows service and probably shouldn’t be turned on for desktop applications. (I’ll talk a bit more about the available tests later.)
After you’ve selected the tests to run, click the Run button to launch your selected application. Use the application as you normally would in the course of business: Process a file, look things up in a database, or perform any other user operations. When you exit the application, you’ll return to the Verifier. Then, you can click the View Logs button to see the results of your session, as shown in Figure B.
The log groups all errors and warnings (and optional information messages by type). You can expand the tree to see all errors of a particular type. Clicking on an error shows further details. For example, in Figure B, the application stored some data in the wrong location. The details suggest the Windows API you can use to avoid this error.
The verification tests
Here’s a quick rundown on the checks that the Windows Application Verifier can perform. Most of these tests write their results to the log. A few, such as the Stacks and Locks tests, require you to attach an external debugger to the process so that you can see any error output in real time.
This is a catch-all test for the Designed For Windows logo requirements. It checks to see whether the application is properly sensing the operating system version and makes sure that it isn’t trying to circumvent Windows file protection.
This test specifically checks setup applications to make sure that they make proper use of the Windows installer. It verifies the choice of installation location, side-by-side functionality, and proper use of the Registry.
This test verifies some additional nonsetup parts of the Designed For Windows logo program. This includes proper use of the Registry and the file system.
This test makes sure that if the application checks for the DirectX version, it does so by calling the proper API rather than just checking a file version.
This checks the proper use of the operating system to determine file paths. For example, the application should use the API to determine which folders the user can write to.
This one detects invalid handle usage (for example, an attempt to use a freed handle) in the application.
Heap and PageHeap
These tests detect various unsafe operations that can corrupt the system memory heap.
This test verifies version handling by returning an arbitrary (and high) Windows version number when the application checks the version it's running on.
This checks to see whether the application has access to more operating system resources than is safe for a service process.
This test checks to see whether the application attempts to install any unsigned driver.
This one checks for the proper use of locks and critical sections in your code.
This is a catch-all test for a variety of unsafe API calls.
This test warns you if you use an API call that is marked as “obsolete” in the MSDN Library. Such calls are no longer being maintained, so calling them leads to a risk that your application will fail unexpectedly on some future version of Windows.
This test warns you if you depend on a section of the Registry that is dangerous or restricted from some users.
This one makes sure that the application requests an appropriate level of security when calling dangerous Windows APIs.
This test checks for an adequate stack allocation of a service application.
Understanding the results
Should you insist that all of your custom applications get a clean bill of health from the Windows Application Verifier before installing them at a customer site? Probably not. Look back at Figure B for a moment. The application being tested there, which has posted a screen full of errors and warnings, is Microsoft Excel. You’ll find similar results if you test almost any application on your computer. Even Notepad can be made to fail the tests (for example, by opening a file from the Windows folder on your computer).
Conformance with the logo standards, even if you’re not submitting your application to the logo program, is a good development practice. But an even better development practice is to understand the standards and to know when and why they are important. You may well decide that a particular violation of the standards is acceptable, or even required, in your application.
For example, you may need to read some information from the Hardware section of the Registry to optimize the user experience. The Windows Application Verifier will flag this as an error because the layout of that section of the Registry can change unexpectedly. But if you don’t expect your application to be used on future versions of Windows, you may be willing to accept this risk.
The Windows Application Verifier will flag potentially problematic areas of your code. Dealing with those areas is part of your job as a software developer. Use your tools wisely, and you’ll deliver higher quality code. In the long run, that will translate to more satisfied customers.