Win 7: App compatibility best practices

BANGALORE, INDIA: Windows 7, the latest release of Windows from Microsoft, would have been released to manufacturing (RTM) by the time you read this. The General Availability of the OS is set to be on October 22, 2009.

However, most large companies, ISVs and people with MSDN or Technet subscriptions are expected to get their hands on the final release soon after RTM. This means that many applications or products will start being released for Windows 7 at GA time.

Windows 7 is a result of consumer feedback

We'll start off this series by taking a look at how to make your existing applications Windows 7 compatible by following some simple best practices that will ensure your applications install and work fine on this new OS. In the next few parts of the series, we'll see how you can 'light-up' your applications on Windows 7 by taking advantage of the new features of the Taskbar and Desktop.

Windows 7 is an old technology says Apple

Folder Locations

One of the most common errors that developers do is to assume a folder location on Windows. For instance, you might assume that the default folder to save a setting from your application is in the 'C:\Program Files\'. If you've hard coded this, you are likely to run into issues what if the user has changed the install folder, or is running a 64-bit version in which your 32-bit program gets installed in the 'C:\Program Files (x86)' folder instead?

IT administrators says no to Windows 7

The problem becomes worse when assuming user data folders called 'Known Folders' such as My Documents, My Music, Favorites and others. If you assume that the folder is a particular path, you are then hard coding such paths into your application. However, there is no guarantee that the path will exist in newer version of Windows. For instance, the path to the user's documents has changed in every version of Windows from XP onwards:

• In Windows XP: \Documents and Settings\\My Documents\
• In Windows Vista: \Users\\My Documents\
• In Windows 7: \Users\\Documents\

As you can see, by assuming a particular path, you can cause issues in your application. Windows 7 mitigates this by providing Junction Points that map to older paths. However, the right way of doing things is by querying the system itself for these paths.

The Windows system itself holds the values for these paths and there are many different ways of getting them. Issuing the DOS command set in Command Prompt will display a list of environment variables that you can query for picking many such values from the system from any platform.

For instance, variables such as, ALLUSERSPROFILE, COMMONPROGRAMFILES, HOMEPATH, HOMEDRIVE, SYSTEMROOT, TEMP, PROGRAMDATA, PROGRAMFILES, PUBLIC, USERNAME and USERPROFILE will let you get most of the system path that you require.

If you work with unmanaged (C/C++) code on Windows, you can also use the SHGetKnownFolderPath() function of the Windows SDK. This accepts a parameter that defines which folder you wish to get and returns the full path to the folder.

In case you work with .NET applications, there are many ways of getting this information. In all .NET languages, the System.Environment.GetFolderPath() method with a parameter returns the path. In Vb.NET, you can also get them by using Microsoft.VisualBasic.FileIO.SpecialDirectories or My.Computer.FileSystem.SpecialDirectories methods.

Saving Data in Folders and Registry

A connected problem with the one above is that many application store data in the wrong locations. Windows XP with its lower level of security would allow these to occur. However, on Vista and 7, due to the higher security, this will not be possible and can cause a number of headaches for the user using your application. For this, you should take care of where you write data.

Folders

When saving data into folders, you must first know what kind of data you are writing. Many applications tend to write application settings into their install folder under Program Files or into \Windows or \Windows\System32 folders. In Vista and 7, these are protected folders which require admin access for writing. Both these OSs perform File Virtualization that redirects writes and reads into these folders into a VirtualStore. However, the virtualization can cause issues of its own.

The same occurs when an application tries to write into the HKLM tree of the registry. To solve the issues and use the best practice, you should follow these rules for saving data ? remember to get the paths using the APIs in the previous section:

• If you are saving application data for the current user, it should go into the user's application data folder. For instance, on my machine, my application data folder is in C:\Users\Vinod\AppData\Local.
• If you are saving application data for all users, you should save it in the ProgramData folder- normally in C:\ProgramData.
• If you are saving the data that the user has created or worked with it should by default go to one of the user's known folders depending on the kind of data ? documents, music, videos, etc.
• If saving application data in the registry, it should go to the HKCU\Software tree rather than HKLM.

Following these rules will ensure that your application works fine not only on older versions of Windows such as XP, but also on Vista, 7 and beyond.

Working with UAC

The User Access Control (UAC) feature that was introduced in Vista was one of the most misunderstood aspects of Vista. UAC has been greatly trimmed down in Windows 7. However you will still need to contend with this sometimes. Here are some tips and best practices to work with UAC.

1. If your application installer is a plain MSI file, users will not need to elevate the install process.
2. If your installer has a Setup.exe or equivalent file, in most cases Windows 7 will recognize it as an installer and prompt the user for consent.
3. You should design your application to run without requiring admin rights unless it is absolutely required for business or technical reasons.
4. You can elevate a process from code by using the verb='runas' property before starting the process.

For instance, in .NET to start a process as admin after the consent dialog box, use the following code:

ProcessStartInfo psi = new ProcessStartInfo();

psi.FileName = "c:\Program Files\MyApp\Demo.exe";

psi.Verb = "runas"; // Ask for elevationProcess p = Process.Start(psi);

5. You can check whether the user is running as admin by using the IsUserAnAdmin() function.

6. You can use manifests to request the right type of privilege ? asInvoker, RequireAdministrator or HighestAvailable. This can ensure that your application gets the right set every time it is launched.

Summary

There are a number of things to keep in mind to make sure your applications run fine on new versions of Windows. The Windows 7 RC has been a huge hit already and pre-orders for the final version have already pushed Windows 7 to the top in Amazon's list. It is important that you get your applications working with Windows 7 as soon as possible too and take advantage of the new features in later releases.