|
|
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. |
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.
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.
|
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). |
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.
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.
|
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.
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).
|
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.
|
|
