Win 7: App Compatibility Best Practices

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.

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.

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\ install folder>'. 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?

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.

Working with UAC means dealing with virtualization, unless you use the correct APIs to save data into the correct folders.

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.