Looking for documentation on the “right” way to in

Question

I'm working with some legacy applications (10-15 years old), and am trying to find guidance on the "right" way to install and run them (and any user application) on Windows 7 without requiring full Admin privileges.

In other words, where executable/read-only should files go, where user-data/read-write should files go, where registry entries should go, to avoid issues with the UAC and Windows 7 file/registry virtualization during both installation and at run-time.

I seem to remember, years ago, a Microsoft white paper on this subject, but am unable to find any relevent information now. I have found information on the user side (how to get legacy applications to run on Windows 7 via compatibility tweaks), but none on the developer side (how to create/install applications to play nicely on Windows 7 natively).

Any pointers to such information would be most appreciated. Thanks.

Marc

Answer 1

The Windows 7 Training Kit has a big section on application compatibility, including playing nicely with UAC, installing to the proper folders, etc.

http://www.microsoft.com/downloads/en/details.aspx?familyid=1C333F06-FADB-4D93-9C80-402621C600E7&displaylang=en

If you are also looking to use the new features of Windows 7 and not just get your app compatible, there's a lot in the kit that can help.

Answer 2

You're thinking of the Windows Logo Requirements.

1. Install to the correct folders by default

Users should have a consistent and secure experience with the default installation location of files, while maintaining the option to install an application to the location they choose. It is also necessary to store application data in the correct location to allow several people to use the same computer without corrupting or overwriting each other's data and settings.

Windows provides specific locations in the file system to store programs and software components, shared application data, and application data specific to a user:

• Applications should be installed to the Program Files[16] folder by default. User data or application data must never be stored in this location because of the security permissions configured for this folder

[16] %ProgramFiles% for native 32-bit and 64-bit applications, and %ProgramFiles(x86)% for 32-bit applications running on x64 respectively

• All application data that must be shared among users on the computer should be stored within ProgramData

• All application data exclusive to a specific user and not to be shared with other users of the computer must be stored in Users\\AppData

• Never write directly to the "Windows" directory and or subdirectories. Use the correct methods for installing files, such as fonts or drivers

• In “per-machine” installations, user data must be written at first run and not during the installation. This is because there is no correct user location to store data at time of installation. Attempts by an application to modify default association behaviors at a machine level after installation will be unsuccessful. Instead, defaults must be claimed on a per-user level, which prevents multiple users from overwriting each other's defaults.

Next is that fact that you should not be writing to any location that requires administrative permissions.

Note: You can test all of this on a Windows 2000 or Windows XP simply by (as Windows 2000 Logo Requirements required) running as a standard user.

Since most applications ignored the logo requirements, and would fail when run with standard user privileges, Windows Vista included the ability to keep these buggy applications limping along by virtualizing writes to protected locations - rather than having them fail.

You can opt out of this compatibly hack by manifesting your application to RunAs Invoker:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0"> 
    ...
    <!-- Disable file and registry virtualization -->
    <trustInfo xmlns="urn:schemas-microsoft-com:asm.v2">
        <security>
            <requestedPrivileges>
                <requestedExecutionLevel level="asInvoker" uiAccess="false"/>
            </requestedPrivileges>
        </security>
    </trustInfo>
    ...
</assembly>

The logo guidelines talk about UAC and virtualization of writes to certain locations:

1. Follow User Account Control (UAC) Guidelines

Some Windows applications run in the security context of an administrator account, and many require excessive user rights and Windows privileges. Controlling access to resources enables users to be in control of their systems against unwanted 20 changes. The most important rule for controlling access to resources is to provide the least amount of access “standard user context” required for a user to perform his or her necessary tasks. Following UAC guidelines provides applications with the necessary permissions when needed, without leaving the system constantly exposed to security risks.

Most applications do not require administrator privileges at run time, and should be just fine running as a standard-user. Windows applications must have a manifest 21 (embedded or external 22 ) that defines their execution levels and tells the OS what privileges the application requires in order to run.

• For example,

• The main process of the application must be run as a standard user (asInvoker). Any administrative features must be moved into a separate process that runs with administrative privileges.

• A waiver is required for applications that run their main process 23 with elevated privileges (requireAdministrator or highestAvailable)

Waivers will be considered for the following scenarios:

• Administrative or system tools with execution level set to highestAvailable, and or requireAdministrator

Or

• Only Accessibility or UI automation framework application setting the uiAccess 24 flag to true to bypass the user interface privilege isolation (UIPI)

Then there was high-dpi. The Windows Logo requirements for a decade has required applications to respond appropriately to high (i.e. non-96dpi) displays. Since most applications break horribly if the user does use "Large Fonts", Microsoft gave up and, like virtualization of the file system, they also virtualize the dpi setting. Unless an application opts out of the compatibility hack: Windows will lie to you and tell you that you are 96dpi.

Only once you've written your app properly should you add an entry to your application's manifest to disable high-dpi scaling:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0"> 
    ...
    <!-- We are high-dpi aware on Windows Vista -->
    <asmv3:application xmlns:asmv3="urn:schemas-microsoft-com:asm.v3">
        <asmv3:windowsSettings xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings">
            <dpiAware>true</dpiAware>
        </asmv3:windowsSettings>
    </asmv3:application>
    ...
</assembly>

Anyway, it's all there, the Windows 7 Client Software Logo Program.

---

Note: If you were writing a Windows application 15 years ago (1995) i assume you were writing for:

• Windows 3.1, or
• Windows 95

rather than:

• Windows NT 3.1
• Windows NT 3.5
• Windows NT 4
• Windows 2000
• Windows XP

It's important to note that Windows NT was designed as a secure operating system. You are not allowed to arbitrarily do anything you want. This is a fundamental difference from:

• Windows 1
• Windows 2
• Windows 3
• Windows 3.1
• Windows 95
• Windows 98
• Windows Me

which had no security.

Writes to the Windows and Program Files folder requires administrator permission. This is because normally only administrators should install applications. But it regular users cannot modify, or damage, installed programs - or the installation of Windows itself, e.g.:

• deleting System32 is bad
• deleting WinSxS is bad