Developing on Windows Vista

Windows Vista has a huge number of enhancements aimed at the developer, The
largest one being a whole new platform-.NET 3.0 that incorporates some of the
best development features available such as WPF (Windows Presentation
Foundation), WCF (Windows Communication Foundation) and WF (Workflow
Foundation). However, we are not going to dwell on this platform in this
article. Instead, we'll take a look at a few other new or enhanced development
options that are available in Vista that have not been talked about too much but
are still very useful and important to understand.

Task dialogs and CommandLink buttons

Task Dialogs in Windows are dialog boxes that prompt the user to perform an
action or take a decision. For instance, the dialog box you get when you try to
exit Notepad when you have some unsaved work is an example of a task dialog.
These dialogs are usually written in C++ with resource files that hold the
strings to be displayed.

Vista has a number of enhancements to the Task Dialog and has one absolutely
new control that is most useful in these types of dialogs-called the
CommandLink button. By combining the two, you can make extremely powerful, yet
user friendly and intuitive dialog boxes. And to help you in writing all, this
is a tool in the SDK called TDPad. This tool lets you design your task dialogs
using XML and once you are fine with what you want to create, you can have it
output C++ code for you. The task dialog in Windows Vista has a number of
different features. You can have headers, footers, progress, content, command
and expansion areas. Each area can be used to display information of different
types to the user. For instance, you can use the expansion area to put extra
information about the dialog's content, but this is not shown by default.

The CommandLink button, on the other hand, is a new control that can be used
to directly replace standard buttons that you see normally with ones that are
much more intuitive to use for the user. The CommandLink button is actually a
special case of a standard button under the hood, but it allows developers to
present a much clearer choice to the end user. The button consists of a minimum
of three parts-a small icon, the main command text and an optional command
explanation. So let us actually see all of this in action. Opening up TDPad, we
create the following XML code (see TDPad.txt on the CD).

TDHeader="TaskDialogs.h" IdRange="1000,1100">

This defines a dialog box similar to one that you see when exiting Notepad
without saving your work. Many such

dialogs are not very intuitive or clear to the user. So replacing the buttons
with CommandLinks in the code, we get (see New_TDPad.txt on the CD):

TDHeader="TaskDialogs.h" IdRange="1000,1100">

This shows a dialog box with CommandLink buttons that are very clear in their
intended function and make it easier for the user to understand what will happen
on clicking a particular button.

Using TDPad, you can quickly develop better task-oriented dialogs for your
applications that do not make the user think he requires a degree in Rocket
Science to be able to make a decision.

Instead of having a mundane Yes/No dialog box (bottom), you can add your own explanation to get a dialog box as shown on the top

Working with UAC

The UAC is a new security feature in Windows Vista that allows users to run as a
'normal' user without administrative access by default. Whenever a task that
requires admin access comes up, the user is prompted by a permission request.
Only when the user grants permission will that task run with admin privileges.
This, however, has some important implications for you. To illustrate this
point, let's create a small Windows application-a simple .NET Windows form
with two buttons, a textbox and a label control. The application allows the user
to type a small string into the textbox. By clicking on the first button, the
string is written into the registry at HKEY_LOCAL_MACHINE\Software\PCQ UAC
App\Test Key. When you click on the second button, the same value is read back
from the registry and displayed in the label control. The code for this
application looks like this (see UAC.txt on the CD).

Imports Microsoft.Win32

Public Class Form1

...

regKey.Close()

End Sub

End Class

Compile and run this code. As you will see, the application works fine and
you can write and read from the registry fine. Now open up regedit and browse
over to the same place. You'll find that you will not be able to reach the
above-mentioned key as it does not exist there at all! So how is the application
reading and writing to this when it doesn't exist? Before I answer this, try
something else.This time open the folder where the compiled EXE of the above
application sits and right click on the application EXE and select 'Run as
administrator'. Permit the application to run in the UAC

dialog. Perform the same task again-writing and reading from the registry. Now
try browsing to the same location and you will see that this time the key exists
in the specified location! Weird isn't it?

Actually what happens is that when Vista detects that you are not running as
the administrator on the machine (default), certain actions (such as read/write
to HKLM and to volume root, \Windows, \Program Files, etc) are not allowed.
However, for maintaining backward compatibility with legacy applications
Microsoft redirects these API calls to a 'Virtual Store'. The virtual store
for HKLM is actually HKEY_CLASSES_ROOT\VirtualStore. So if you browse to this
location you will find MACHINE\Software\PCQ UAC App\Test Key with the value you
entered last when you were running as non-admin. This will happen for many other
calls as well. So you should take a very good look at what your applications are
doing and if required, move such calls into non-admin privilege requiring calls.
For instance, if you are writing data files into the program's folder under
\Program Files, you should now move it to write to the current user's profile
folder instead and so on.

However, in case you do need to have admin privileges for the application, you
should mark it with a manifest file. In our sample above this can be done by
creating the following manifest file (which is named .exe.manifest)
as (see manifest.txt on the CD):

encoding="UTF-8" standalone="yes"?>



...

The 'requireAdministrator' clause specifies that the application requires
performing some admin level tasks and, therefore, needs permission from the user
to get the admin privileges.

Rebuild the application and run it. You will get a UAC prompt that tells you
that the application is trying to do something that needs administrator rights.
And only if you allow it, will it run.

The UAC is a powerful security feature in Vista and you. As far as possible,
run applications without requiring the user to grant you admin rights. But if
your application does require these, three things can happen. First, the API
call is redirected to a safe location as in the above scenario. Second, your
application gets an 'Access Denied' message from the system and won't have
access to do what it wants to do. Or finally, you mark the application using a
manifest and inform and request the user for admin rights.

As you can see, Windows Vista has a number of small but new and enhanced
development-related options that can be used for creating better and more secure
apps. We will continue with more Vista development articles in the coming
months.