10 steps to a well-behaved Windows application

Microsoft has published development guidelines for Windows 7 applications. They make interesting reading even if you don't plan to develop specifically for Windows 7 - after all, it has only just gone into beta - because they presumably represent Microsoft's latest thinking about how Windows applications should behave. In fact, I don't see much in the document that is specific to Windows 7. Arguably many of the problems with Windows are a result of badly-behaved applications, so I'd suggest that it pays to follow the guidelines unless there is a good reason to do otherwise. Most are applicable to internal apps as well as publicly available software. You can read them in detail by following the link, but here is a quick summary.

First, there are three "policies":

1. Don't be malware or spyware. Goes without saying; yet even supposedly reputable applications stray over the line sometimes, for example by phoning home with user data without proper explanation or consent.

2. Do not modify Windows Resource Protection files. This is about not installing system files except with official Microsoft redistributables.

3. Sign up to receive crash data from Windows Error Reporting. Probably not relevant to internal applications, where users soon let you know about crashes, but a great idea for anyone distributing software more widely.

Next, 10 guidelines. Note that there can be good reasons for breaking the guidelines; Microsoft's logo rules allow for waivers in these cases.

1. Install and uninstall cleanly, and never force a reboot at the end of an installation. The guideline doesn't address the question of how much user data to leave behind on uninstall. Most applications leave user data in place; but occasionally users reinstall to try and fix a configuration problem that is in the user data.

2. Install to the correct folders. Apps in Program Files, for example, and user data in AppData. An interesting twist here is that if your app is available for all users on the machine, then it cannot write user data during the install, but only on first run:

Since the install potentially elevates to a different user account during a "per machine" install, there is no correct user location to store data at the time of installation.

3. Support x64. That doesn't mean a 64-bit version, just that it works OK on 64-bit Windows.

4. Follow User Account Control (UAC) guidelines. This is the security feature in Vista and Windows 7 that means even local administrators run with limited permissions. I have seen app vendors advise customers to turn UAC off for the sake of their application. UAC is a security feature, and Windows insecurities afflict all of us in the form of viruses, spam and other malware, so I reckon we should support Microsoft's efforts and work with UAC rather than against it.

5. Do not load services and drivers in safe mode. For obvious reasons - safe mode is meant to be safe.

6. Digitally sign all executable files - both DLLs and EXEs. Worth doing, if only to avoid the user seeing ugly warnings about unknown applications.

7. Do not prevent an installation or application from launching because of version checking. This is an interesting one. If you write and test your application for, say, Windows Vista, it seems reasonable to block it from running on Windows 7, which you haven't yet been able to test. Unfortunately this kind of thinking causes major problems for users, who upgrade Windows and find that it "breaks" their applications. However, you are allowed to check for a minimum version - after all, if you know your app won't work on, say, Windows NT 4.0, there is little point in permitting the user to try.

8. Listen for system shutdown messages, prompt to save data if necessary, and avoid unnecessary reboots.

9. Support multi-user sessions. This means that multiple instances run by different users have to be isolated from each other.

10. Don't crash. Pass Application Verifier checks (Microsoft's utility for finding heap corruption and other common problems).

In the past I've read Microsoft logo guidelines that have struck me as placing unreasonable burdens on developers; but these seems concise and sensible. I'd be interested in opinions - has Microsoft set attainable goals, and is there anything here you violently disagree with?