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.