Team LiB
Previous Section Next Section

Compatibility Flags

Different compatibility flags in the registry provide the terminal server with specific data for optimum handling of certain applications, registry paths, or .ini files. The flags are set in the HKLM\Software\Microsoft\Windows NT\CurrentVersion\Terminal Server\Compatibility registry hive.

Several entries already exist right after a terminal server’s system installation and affect frequently used standard applications or .ini files. Administrators can add new entries or modify existing ones to achieve a certain system behavior.

Note 

There is no standard graphical tool to view or change these entries. You always need to use the registry editor or third-party tools. However, you should make changes only if applications do not function properly. Use utmost caution when modifying the registry.

Applications

You can control the execution of an application on terminal servers via compatibility flags in a special section in the registry. They are located in the HKLM\Software\Microsoft\Windows NT\CurrentVersion\Terminal Server\Compatibility\Applications\App hive. App is the name of the executable file of the corresponding application.

Supplementing existing entries is relatively easy. You just need to create a new key with the application’s file name (excluding the .exe ending) as a character string. You can now add values with data to this key.

Click To expand
Figure 6-10: Microsoft Access compatibility flags.

The Flags Value

Probably the most important value is known as flags and has the DWORD data type. Entries are bit masks and therefore allow combining several defaults for the application. However, the number of possible combinations—as shown in Table 6.8—is a problem. For each application, you need to find out which flags will solve possible runtime problems.

Table 6.8: Compatibility Flags for Applications in the Terminal Server Registry

Value (DWORD)

Description

0x00000001

DOS-based application. This entry helps the system unambiguously identify the application characteristics for DOS platforms.

0x00000002

OS/2-based application. This entry helps the system unambiguously identify the application characteristics for OS/2 platforms.

0x00000004

Windows-based 16-bit application. This entry helps the system unambiguously identify the application characteristics for platforms under 16-bit Windows.

0x00000008

Windows-based 32-bit application. This entry helps the system unambiguously identify the application characteristics for platforms under 32-bit Windows.

0x0000000C

Windows-based 16- or 32-bit application (combination of the flags 0x00000004 and 0x00000008, hexadecimal sum).

0x00000010

The terminal server responds to the GetComputerName API command with %UserName% instead of %ComputerName%. This function is needed for applications that identify with the computer name when they communicate with each other. When these applications run on a terminal server, conflicts occur. For this reason, identification occurs via the user name.

0x00000040

Ini mapping: synchronizes the user’s .ini file in the %UserProfile%\Windows directory with the system version of the .ini file in the %SystemRoot% directory. This is needed particularly for 16-bit applications to function properly.

0x00000080

Ini mapping: Prevents replacement of the system-wide \Windows directory for the user by the corresponding directory in the user’s profile path or basic directory.

0x00000100

Disables registry mapping of mirrored data from HKLM to HKCU for application registry keys. If a user starts this type of application, the mirrored registry values are used, but not written to HKCU.

0x00000200

Normally, objects are also marked with the user’s connection identification. If this flag is set, the corresponding application is declared as system-wide. In this case, the application behaves like an operating system component. This option is needed for some server applications installed on the terminal server.

0x00000400

The terminal server responds to the GetWindowsDir command with the system’s %SystemRoot% directory instead of the user’s \Windows directory. This is required for applications that need to have read access to global files from the %SystemRoot% directory.

0x00000800

Responds to the GlobalMemoryStatus command by limiting the return value for physical memory. The given application can request only reduced memory below the default value of 32 MB. In this way, the application does not affect other applications.

0x20000000

Prevents application freezing in case of unsuccessful keyboard polling (only for 16-bit Windows-based applications).

Bad Applications Values

In addition to the Flags value, you can set three other application values to optimize it for the terminal server. All value names contain the BadApp character string, which indicates an adaptation of bad applications. The MsgQ character string represents a connection to the message queue, which is responsible for transmitting system commands to the applications.

  • FirstCountMsgQPeeksSleepBadApp (default value: 0xF): This value determines how many times an application will try to read the message queue before the terminal server deems it a bad application. If you lower this value, the application “sleeps” more frequently, thus using less CPU time. If you increase the value (for example, to 0xFF), the application usually becomes faster.

  • MsgQBadAppSleepTimeInMillisec (default value: 0x1): If the terminal server deems an application bad, the application is put to sleep for the number of milliseconds defined here. If you increase the value, the application uses less CPU time. If you set the value to zero, the query recognition related to the message queue is switched off, often improving application speed.

  • NthCountMsgQPeeksSleepBadApp (default value: 0x5): If the system deems the application bad, this value defines how many times the application will retry to access the message queue before it is “put to sleep” again. If you lower this value, the application uses less CPU time. If you increase the value (for example, to 0xFF), the application usually becomes faster.

While you are adjusting these parameters, make sure to check the results using the System Monitor, because processor use has been changed. Improved application response time generally results in more intense use of processor resources.

Note 

Compatibility flags similar to the message queue also exist for the clipboard. However, there is currently no official information available on ClipboardFlags, OpenClipboardInMilliSecs, and OpenClipboardRetries flags. The only thing you can do is experiment—for example, by using the Microsoft Excel (program name: Excel.exe) compatibility flags.

Registry Paths

The following compatibility flags control the use of registry options in particular. They are located in the HKLM\Software\Microsoft\Windows NT\CurrentVersion\Terminal Server\Compatibility\Registry Entries\RegPath hive. RegPath is a key under HKCU\Software.

Table 6.9: Compatibility Flags for Registry Paths

Value (DWORD)

Description

0x00000008

Windows-based 32-bit application. This entry helps the system unambiguously identify the application characteristics for platforms under 32-bit Windows.

0x00000100

Disables registry mapping of mirrored data from HKLM to HKCU for application registry keys. If a user starts this type of application, the mirrored registry values are used but not written to HKCU. No registry values are deleted for the user, even if they no longer exist system- wide.

The typical value of an entry for disabling registry mapping of a preset path is 0x108.

Note 

If an application’s registry entries are not located directly under HKCU\SOFTWARE but in its own key hierarchy that starts here, this structure is also evidenced in the compatibility flags. For instance, if an application’s parameters are saved under HKCU\SOFTWARE\Directory\Application, the path name for registry options is also \Directory\Application.

.ini Files

The following compatibility flags stipulate the use of .ini files, and they are located in the HKLM\Software\Microsoft\Windows NT\CurrentVersion\Terminal Server\Compatibility\IniFiles\IniFile file, in which IniFile is the name of the .ini file (without the .ini suffix).

Table 6.10: Compatibility Flags for .ini Files

Value (DWORD)

Description

0x00000004

Windows-based 16-bit application. This entry helps the system unambiguously identify the application.

0x00000008

Windows-based 32-bit application. This entry helps the system unambiguously identify the application.

0x00000040

Synchronizes the user’s .ini file in the %UserProfile%\Windows directory with the system version of the .ini file in the %SystemRoot% directory. New entries in the central .ini file are mapped to the user-specific .ini file without deleting any entries there. By default, the user-specific .ini file is completely overwritten if it is older than the central .ini file. This is particularly needed for 16-bit applications to function properly. This flag is often called INISYNCbit.

0x00000080

Prevents replacement of the system-wide \Windows directory for the user by the corresponding directory in the user’s profile path or basic directory.

Typical values for the changed synchronization behavior related to a 16-bit application .ini file are 0xC4 or 0x44.

If an application tries to read from an .ini file that does not exist in the user’s home directory, the terminal server looks for the file in the system’s root directory. If the .ini file is there, it is copied to the \Windows subdirectory of the home directory (%UserProfile%\Windows). If the application queries the Windows directory, the terminal server returns the home directory’s \Windows subdirectory.

When a user logs on, the terminal server checks to determine if the system .ini file is more recent than the individual .ini files. If the system version is more recent, the user’s .ini file is replaced with the newer version, or the more current entries in the system version are integrated in the user-specific .ini file. Which of the two procedures is used depends on whether the 0x40 INISYNC bit is set for this .ini file. The older version of the user-specific file is renamed; the file name becomes Inifile.ctx. If the system’s registry values under the \Terminal Server\Install key are more recent than the version saved under HKCU, the version of that key is deleted and replaced with new keys under \Terminal Server\Install.


Team LiB
Previous Section Next Section