by August 1, 2009 0 comments



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.

Direct Hit!

Applies To: Developers
USP: Make your application
compatible with Windows 7
Primary Link:
http://msdn.microsoft.com
Keywords:
Windows 7, Application Compatibility, UAC

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\<Your application
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\<username>\My Documents\
  • In Windows Vista: \Users\<Username>\My Documents\
  • In Windows 7: \Users\<Username>\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.

No Comments so far

Jump into a conversation

No Comments Yet!

You can be the one to start a conversation.

<