Adjusting Your Applications for Windows

Upgrading to the latest DataFlex revision is the first step to preparing your applications for Windows 7 and higher. The second step is to verify that your application operates correctly.

Most applications, when upgraded to DataFlex 2008 or higher, should have very few, if any, issues related to Windows 7. UAC-related issues are by far the most likely type of issue that you might experience when running on Vista and higher.

If your legacy application operates correctly as a Standard User on Windows XP, and you have migrated to the most current DataFlex version, it’s very likely that you will not need to adjust your application logic for UAC. In general, running with UAC is very similar to running as a Standard User on Windows XP.

If your application performs any tasks that require Administrator privileges on Windows XP, you may need to adjust your application to operate appropriately with UAC. Examples of tasks that require elevated Administrator privileges in Vista and higher are:

Windows registry manipulations, especially under the HKEY_LOCAL_MACHINE and/or HKEY_CLASSES_ROOT branches
File manipulations under the standard %ProgramFiles% directory

It’s recommended that you inspect your application code to see if it’s performing any file or registry manipulations and classify them as to whether they will require elevated Administrator privileges.

Note

If you are using the cRegistry class and even if you're only reading from HKEY_LOCAL_MACHINE or HKEY_CLASSES_ROOT, make sure that the pfAccessRights property is set accordingly to KEY_READ. The property is by default set to KEY_ALL_ACCESS, which means that your application will not be able to open registry keys in HKEY_LOCAL_MACHINE or HKEY_CLASSES_ROOT without elevated Administrator privileges.

As mentioned above, unless your application is protected from File and Registry Virtualization, any access to protected areas of the registry and file system will virtualize. File and Registry Virtualization creates user-specific local versions of the specified file and registry keys. This means that the changes will only be seen by that user.

In most cases, File and Registry Virtualization is not desired, and it’s disabled by default for any new programs created in DataFlex 2008 and higher, as well as any existing programs migrated using the Workspace Migration Wizard.

To verify that File and Registry Virtualization is disabled for your programs, ensure that there is a program-name.manifest file in the same folder as the .exe (usually the workspace Programs folder). Then open the specified manifest file in an editor, such as DataFlex Studio, and verify that it contains the following information (usually near the end of the file):

The presence of the <requestedExecutionLevel level="asInvoker" uiAccess="false" /> configuration disables File and Registry Virtualization. Without this setting, any code in your program modifying certain file system folders and registry locations will virtualize, resulting in individual user settings instead of machine-wide settings as was probably intended. Changes to files and registry keys that are virtualized can only be seen by that particular user, as each user will have their own copy of the virtualized files and registry keys.

If you suspect that your application is using file or registry virtualization, you should check the following locations:

C:\Users\User_name\AppData\Local\VirtualStore
HKEY_CURRENT_USER\Software\Classes\VirtualStore

Note that even if you have disabled file and registry virtualizations, it’s possible that your application may have created files in these locations before the application was protected. It’s also possible that some other application (where file and registry virtualization has not been disabled yet) has created files or registry keys in these locations.

Administrator Privileges

Most applications should not require elevated Administrator privileges. If your application doesn’t require write-access to protected registry keys or file system locations such as %ProgramFiles%, HKEY_LOCAL_MACHINE, or HKEY_CLASSES_ROOT, then most likely your application does not require elevated Administrator privileges.

However, if your application has some kind of administrator settings or installation-related tasks that require Administrator privileges on Windows XP, those will require elevated Administrator privileges on Windows Vista and higher. Common examples of Administrator-related tasks include, but are not limited to:

Explicit modifications of any registry keys other than under the HKEY_CURRENT_USER branch. This includes changes to HKEY_LOCAL_MACHINE and HKEY_CLASSES_ROOT.
Explicit modifications to system-defined file system locations, such as %ProgramFiles% and %WinDir%.
In some cases, file modifications to areas other than the user’s home directory, which have not been explicitly granted the appropriate permissions, can be restricted.
Registering ActiveX controls and other COM DLL and EXE files. Registering COM controls requires write-access to HKEY_CLASSES_ROOT, which normally requires elevated Administrator privileges.

Note that not all Administrator-level tasks will fail with an error message when you run the program without sufficient permissions. In many cases, the code may fail silently. It’s therefore crucial that you actually inspect your application code and not just rely solely on running and testing your application.

If your application is performing tasks that require elevated Administrator privileges, then you should first see if you can change the file/registry locations, e.g., moving registry settings from HKEY_LOCAL_MACHINE to HKEY_CURRENT_USER.

If you cannot move the registry settings or files to user-specific areas, then see if they can be configured at installation time instead of when running your application. Installation programs usually execute with elevated Administrator privileges, so that ActiveX controls can be registered, and registry settings in HKEY_LOCAL_MACHINE can be set up, etc.

If operations requiring elevated Administrator privileges must be performed in your application, then you should try to see if you can isolate and extract those operations into a separate administrator program, thereby minimizing the extent of running your application with elevated Administrator privileges.

Running with Elevated Administrator Privileges

To run a program with elevated Administrator privileges, you must mark it as such in the program manifest file. Remember that you cannot temporarily elevate permissions in your program code. Permissions are elevated when the process is started by the operating system and remain in effect for that program’s entire duration. Elevated permissions are also isolated to that process (and any child processes it creates), so elevating permissions for one process does not affect another unrelated process.

To mark your application as requiring elevated Administrator privileges, change the program manifest file as follows:

<requestedExecutionLevel level="requireAdministrator" uiAccess="false"/>

When launching the program, the user will now be prompted with the UAC Credential (User Consent) dialog before the program starts with elevated Administrator privileges.

Note that you cannot debug a program with elevated Administrator privileges unless you also run the Studio itself with elevated Administrator privileges. See the Studio Changes section for more information.

To run the program programmatically, you must use the RunProgram Shell. If you use the RunProgram command without the Shell parameter, the program will not run as you must specify the Shell parameter to enable the operating system to display the UAC Credential (User Consent) dialog. So, for example:

RunProgram Shell "myprog.exe" "arg1 arg2"

Inter-process Communication (IPC)

Most IPC (Inter-process communication) mechanisms sometimes used in DataFlex applications, such as sending Windows messages to other processes, should work the same in Vista. With one exception: when sending Windows messages between a process running with elevated Administrator privileges.

As of Vista, Windows includes a new security-related feature, which is somewhat loosely related to UAC, called User Interface Privilege Isolation (UIPI). UIPI, among other things, essentially prevents programs from sending messages to other programs running with elevated Administrator privileges.

UIPI actually divides processes into different integrity levels: low, medium, and high. Processes running with elevated Administrator privileges are classified with the high integrity level, whereas processes running with Standard User privileges are classified with the medium integrity level. Sending Windows messages from a medium or low integrity process to a high integrity process is not allowed by default.

If you have a program that runs as a Standard User and another program that runs with elevated Administrator privileges, you will not be able to send certain Windows messages to the program running with elevated Administrator privileges.

Remember that this is only an issue if you have a program that requires elevated Administrator privileges. You can still send any Windows messages between two programs where both are running with Standard User privileges.

The best solution is to try to lower the process with high integrity level to medium integrity level, if possible. This basically means removing the need for the process to run with elevated Administrator privileges.

If you cannot change the program so it doesn’t require elevated Administrator privileges, you can in some cases configure the specific Windows message to be allowed. See the ChangeWindowMessageFilter() API for Vista.

File Drag and Drop to Programs Running with Elevated Administrator Privileges

Standard Windows file drag and drop operations are not permitted in Vista between a medium/low integrity level process and a high integrity level process. This affects the DataFlex built-in OnFileDropped event, used to handle file drag and drop in DataFlex applications.

Remember that this is only an issue if you use the OnFileDropped event and your application is running with elevated Administrator privileges. You can still use OnFileDropped if your program is running with Standard User privileges.