Revenera logo

Windows 7 is the latest operating system from Microsoft and it is a very popular platform.  It seems like every company that I visit is preparing to upgrade their computers to use Windows 7 sometime in the very near future.  One barrier to that, however, is getting all of the necessary applications to run on Windows 7.  You, as a software developer, can help, however, if you make a few changes to your application.  Here are a few things that I’ve personally observed that can make applications run better on Windows 7.

Use Embedded Application Manifests

Application manifests are XML files that describe how Windows should run an application.  If you set the “requestedExecutionLevel” in the manifest, the user account control dialogs will display appropriately, prompting for elevation only if necessary.  Furthermore, setting the requestedExecutionLevel will prevent Windows from writing files and registry data to the “virtual store”.

If you set the “compatibility” section in the manifest, you can tell Windows that the program is compatible with Windows Vista and Windows 7.  Including the compatibility section will prevent the Program Compatibility Assistant from appearing when an end user exits the program.

Below is a sample manifest file that sets the requestedExeuctionLevel and the compatibility level for an application.  You can use it as a template for creating your own manifest.

Listing 1: An Application Manifest

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<assemblyIdentity
version="1.0.0.0"
processorArchitecture="X86"
name="MyCompany.MyProgram"
type="win32"
/>
<description>My Program Description</description>
<trustInfo xmlns="urn:schemas-microsoft-com:asm.v2">
<security>
<requestedPrivileges>
<requestedExecutionLevel level="asInvoker" uiAccess="false">
</requestedExecutionLevel>
</requestedPrivileges>
</security>
</trustInfo>
<compatibility xmlns="urn:schemas-microsoft-com:compatibility.v1">
<application>
<!--The ID below indicates application support for Windows Vista -->
<supportedOS Id="{e2011457-1546-43c5-a5fe-008deee3d3f0}"/>
 
<!--The ID below indicates application support for Windows 7 -->
<supportedOS Id="{35138b9a-5d96-4fbd-8e2d-a2440225f93a}"/>
</application>
</compatibility>
</assembly>

Once you’ve created your application manifest, however, it is necessary to embed it in the application.  Microsoft Visual Studio 2010 automatically embeds manifests in applications, but if you’re using an older version like Visual Studio 6, you will need to embed the manifest in the executable after it is built.  One way to do this is with Manifest Tool, which is part of the Windows SDK.  For example, the command line to embed a manifest called “Program.exe.manifest” into an executable called “Program.exe” is:

mt.exe -manifest Program.exe.manifest -outputresource:Program.exe;1

Digitally Sign Your Application and Its Setup

Digitally signing an executable requires a digital certificate from a trusted certificate authority, such as VeriSign or Thawte.  The code signing certificates from these authorities allow you to sign your executable files to guarantee to your end users that the files have not changed since the time you compiled them.  Windows also displays the publisher name on the UAC elevation dialogs, so it reassures your end users that the program they’re about to run really did come from you.

It is also possible to sign the MSI setup for your application using the same code signing certificate that you use for the application files.  InstallShield 2011 has fields in the Release Wizard where you can specify the code signing certificate.

Modify the Application to Store User Data in the Right Locations

Many old Windows programs regularly wrote configuration data into files in the application’s installation directory, usually under the Program Files folder.  Beginning with Windows Vista and now Windows 7, most users should be running with “standard user” privileges, and these privileges don’t allow them to write to the Program Files folder.  That means that any programs they run should be writing configuration data and other settings to an appropriate application data directory.  The table below shows some of the common data locations.

Table 1: Common Data Locations on Windows

InstallShield icon

InstallShield

Create native MSIX packages, build clean installs, and build installations in the cloud with InstallShield from Revenera.

Directory Property Type of Data and Example
AppDataFolder

Per-user, roaming application data

C:UsersusernameAppDataRoaming

CommonAppDataFolder

Per-machine application data

C:ProgramData

LocalAppDataFolder

Per-user, non-roaming application data

C:UsersusernameAppDataLocal

PersonalFolder

User-specific documents

C:UsersusernameDocuments

Ideally, you will need to change your application to use these directories to store any application data.  If you use the registry, make sure that the application treats HKEY_LOCAL_MACHINE and HKEY_CLASSES_ROOT as read-only registry hives.  All user-specific registry data should be stored in HKEY_CURRENT_USER.

Use InstallShield 2012

InstallShield 2012 can help you use the directory properties shown in Table 1 to locate your data in appropriate locations.  InstallShield also has validation rules for Windows 7 that can help you identify files that need to be digitally signed or executables that need embedded manifest files.

If you happen to have AdminStudio, you can use the QualityMonitor to run the application with a standard user account while watching for errors writing to privileged locations.

Planning for the Future

All of the large corporate customers that I have visited during the last year intend to create a locked-down desktop environment, which means that most of their users will not be able to run applications with administrator privileges.  Applications that require administrator rights will be the sole domain of the IT department.  This means that all of their business applications will need to run with standard user privileges, either as a result of proper coding by the software vendor or as a result of repackaging the application with a setup that grants permissions to the appropriate files, folders, and registry keys.  You, as the software vendor, can make it easier for these IT departments and therefore prove the superiority of your product by taking the steps necessary to make your application work well in Windows 7 right from the start.