This document contains information concerning 16-bit, 32-bit, and DOS-based applications. Links to tuning utilities are also provided.

WARNING! Using Registry Editor incorrectly can cause serious problems that may require you to reinstall your operating system. Citrix cannot guarantee that problems resulting from the incorrect use of Registry Editor can be solved. Use Registry Editor at your own risk.

Problems With DOS Applications

It is common for DOS-based applications to use 100% of the system CPU. Use the DOSKBD utility to to tune the MS-DOS keyboard polling detection algorithm for a specific MS-DOS window.

DOSKBD works exactly as it did in WinFrame. The tuning parameters you had with DOSKBD in WinFrame can be used with MetaFrame.

DOSKBD

DOSKBD tunes the DOS keyboard polling detection algorithm for a specific DOS execution environment (window). When optimum values are selected for the application, you can set up a batch file that automatically runs before the application starts.

Given a chance, most DOS applications use nearly 100% of the system CPU. Most DOS applications constantly look for keyboard input even while they appear to be doing nothing. Even when they are doing useful work, many check for keyboard input during the operation to be responsive to the user.

To maximize the number of concurrent users in the system, an aggressive DOS keyboard polling algorithm was implemented. This support attempts to take the CPU away from a DOS application if it checks the keyboard frequently enough during a single system timer tick. System defaults are set up; however, the optimal settings depend on the specific DOS application that you are running. This document explains how to use the DOSKBD utility to tune the DOS keyboard polling algorithm. Change the default settings only if you are trying to solve a problem.

Syntax

doskbd /defaults [/q]
doskbd [/detectprobationcount:nnn] [/inprobationcount:nnn] [/
msallowed:nnn] [/mssleep:nnn] [/busymsallowed:nnn] [/
msprobationtrial:nnn] [/msgoodprobationend:nnn] [
/detectioninterval:nnn] [/startmonitor [appname] | /stopmonitor] [/q]

Parameters and Options

The valid range for all values represented by nnn is 0 to 32767.

/defaults
Resets all tuning parameters to their default values.

/detectprobationcount:nnn
Specifies the number of peeks per system tick that are required to force the application into the probation state and to put the application to sleep (default value: 80).

/inprobationcount:nnn
Specifies the number of peeks per system tick that are required to put the application to sleep when the application is in the probation state. This value should be less than or equal to the detectprobationcount value (default value: 35).

/msallowed:nnn
Specifies the number of milliseconds the application is allowed to be in the probation state before the system puts the application to sleep (default value: 0).

/mssleep:nnn
Specifies the number of milliseconds that the application is put to sleep (default value: 100).

/busymsallowed:nnn
When the application is detected as "busy," the application cannot be put into the probation state for this number of milliseconds (default value: 60).

/msprobationtrial:nnn
When the application is in probation, detectprobationcount is used instead of inprobationcount every msprobationtrial milliseconds (default value: 2500).

/msgoodprobationend:nnn
When the application is in probation, it must avoid being put to sleep for this number of milliseconds to be removed from probation (default value: 2500).

/detectioninterval:nnn
Specifies the time interval (in timer ticks) used to count the number of polling events.

/StartMonitor [appname]
Executes appname and gathers polling statistics.

/StopMonitor
Stops gathering application statistics.

/q
Suppresses the display of information about the actions being performed.

DOSKBD Remarks

The DOSKBD command changes the default settings for a single DOS session. Each DOS session can have its own settings. To find out the current tuning settings (the system default settings), type DOSKBD at a command prompt.

The poll-detection algorithm is affected by how many keyboard polls happen within a detection interval. All units of time are rounded to a detection interval. If too many keyboard polls happen within a detection interval, the application is put into probation state and made eligible to be paused for some amount of time. When the application is on probation, the algorithm can be set up to pause the application after a smaller number of polls. Applications can perform actions that cause the system to mark the application as busy; that is, take it out of the probation state. When the application is determined to be busy, it is awakened. The application is also taken off probation. Examples of things that cause the application to be busy include (but are not limited to) screen updates, file I/O, and keyboard or mouse input.

If an application polls detectprobationcount number of times within a given detection interval and busymsallowed number of milliseconds have elapsed since the last time the application was detected as busy, the application is put into probation. If the application exceeds the allowed number of polls within a detection interval after it is in probation for msallowed milliseconds, it is put to sleep for mssleep number of milliseconds.

While the application is on probation, the number of polls it is allowed is reduced to inprobationcount from detectprobationcount. If it
exceeds the allowed number of polls and if msallowed milliseconds have elapsed since the application was first put on probation, it is put to sleep.

The application is taken off probation if msgoodprobationend milliseconds have elapsed since the application was last put to sleep. Also, every msprobationtrial milliseconds, the allowed number of polls in a detection interval increases to detectprobationcount. As long as the application is not put to sleep, the allowed number of polls stays at the higher level. If the application exceeds that level, the allowed level of polls is reduced to inprobationcount.

If DOSKBD is invoked with no parameters, the current tuning values are displayed.

DOSKBD Examples

When adjusting the parameters, consider the current behavior of the application with the current settings. To observe this, start an inactive system with a user on the console and a remote user close to the console. Only you and these users should be running on the system. Set up Performance Monitor to display total system CPU% every second. You can also use DOSKBD to generate polling statistics to give baseline values for detectprobationcount, inprobationcount, and detectioninterval by using the /startmonitor option (DOSKBD /STARTMONITOR).
[appname] start gathering polling statistics. Run Performance Monitor on the console and the DOS application remotely. Set up Performance Monitor to display the total system CPU% every second.

Example #1

In this example, the DOS application runs well for a single user but the system slows down when more users employ the application. In this scenario, it is possible that the polling detection is not aggressive enough to put the application on probation. Note how much CPU the application is using when doing nothing and when doing common operations. Exit the application and use DOSKBD to refine the polling parameters. The new parameters apply to the command line from which you have just run DOSKBD. Changing parameters by about 30 percent per try is recommended.

This scenario more aggressively takes the CPU away from the application. First, try lowering detectprobationcount and inprobationcount. If that does not help or does not help enough, try lowering busymsallowed by 10 milliseconds per try. The default of msallowed is already zero. If polling is detected, the CPU should be significantly below 100 percent. At this point, it is important to make sure that the application is still responsive in all the ways that it will be used. If it is not responsive, you changed the settings too much and you must raise the values of one or more of them. To further reduce the amount of CPU used, increase mssleep. Use caution when increasing mssleep because some applications become unresponsive or jerky if this value is increased too much.

Now that you reduced the amount of CPU that the application is using (while ensuring that the application is still responsive), the system can support more concurrent users. Some applications can use close to 100 percent CPU regardless of how aggressive you make the polling detection. These applications are probably not polling the keyboard or they are doing something that causes the application to be marked busy very frequently.

Example #2

In this example, an application does not get enough CPU and the application is not responsive. It is also possible that the default polling detection parameters work for 99 percent of an applications use but occasionally you do something that does not work well with the polling detection. In that case, it is probably a mistake to change the polling parameters for all usage of the application because the change could significantly affect how many concurrent users are supportable. Instead, create a special icon/autoexec file for the infrequent scenario. This enables maximum productivity on your system.

If an application does not get enough CPU, the polling detection is probably too aggressive or the application needs more time to run before being put to sleep. You can increase detectprobationcount and inprobationcount to lengthen the time it takes to detect that the application is polling. You can also increase msallowed from zero to give the application additional execution time before it is put to sleep for being on probation. Another way to give the application more CPU while it is being put to sleep is to reduce the value of mssleep. All these possibilities increase the amount of CPU that the application gets, which may reduce the number of users who can simultaneously work on the system.

Strategies for the DOSKBD Utility

Each application is different, so defining the optimal solution requires some work. Use Performance Monitor to track CPU utilization while changing the DOSKBD parameters.

1. Start with the default DOSKBD settings to see what effect this has, then proceed with the following.

2. On the second attempt, try the following decimal values:

/DetectProbationCount:1
/InProbationCount:1
/msSleep:10,000
/BusymsAllowed:1

3. On the third attempt, reverse the direction of the values used in the second attempt:

/DetectProbationCount:10,000
/InProbationCount:10,000
/msSleep:1
/BusymsAllowed:10,000

Keep in mind the main idea behind this strategy is to determine which direction (up or down) each of the above parameters will begin to lower the overall CPU utilization. For example, if the application begins to use less CPU time by using the values in Step 2, you know that those particular values need to be decreased or increased from the default values. This process can take some time.

Notes and Additional Tips

You can use the PIF editor to create an icon to start a specific DOS application. The Windows NT button on the main PIF editor screen brings up a Windows NT Options dialog box. For information concerning this, create a PIF and check the Help under Advanced Options for the preferred settings.

You can specify a custom Autoexec.bat file that runs DOSKBD, optimizing the application without the user having to type any extra commands.

Contact the application manufacturer to determine if there is anything specific the application requires to perform under standard Windows NT 3.51/4.0 to work correctly; for example, DOS settings like BUFFERS= or FILE= that can be set in the Autoexec.nt or Config.nt files.

Use the START command at a command prompt to start the application with a higher priority in the system.

CAUTION: This can have severe effects on overall performance of the system processor; be extra cautious when using these parameters. This might be used if the only application to be run on the Citrix system is the DOS-based application.

Is the application calling another process or executable to run correctly; for example, BTrieve? Which version? Is NLM on the NetWare server or the Breqnt.exe running on the Citrix server?

Is the application a Cobol run-time based DOS application? Have they tried the following?

Set the compatibility bit to have WinFrame return the username instead of the computername. The delay may be because the application is doing some locking to prevent two users from modifying the same record.

WARNING! Using Registry Editor incorrectly can cause serious problems that may require you to reinstall your operating system. Microsoft cannot guarantee that problems resulting from the incorrect use of Registry Editor can be solved.

Create a key under HEY_LOCAL_MACHINE\SOFTWARE\Citrix\Compatibility\Applications.

Use the application name for the key name (without the application extension).

Create a value under that key called Flags (type REG_DWORD) and set the value to 0x1C.

Full-screen DOS applications do not open within an ICA session. Full-screen DOS mode is not supported through a session on Windows 2000. This is also true for RDP connections.

Some applications that perform normally on Windows NT 4.0, Terminal Server Edition consume 100% of the CPU resources under Windows 2000 with Terminal Services. Microsoft removed the "bad app" detection from Windows 2000. Check with Microsoft for hotfixes for specific applications on Windows 2000.

From the Windows 2000 help:

Title: Application Performance

Windows 2000 Server is a 32-bit environment and Windows 3.11 is a 16-bit environment. Windows 2000 Server runs 16-bit programs through a process called Windows on Windows (WOW), translating 16-bit programs in enhanced mode. This process causes 16-bit programs to consume additional system resources. Running 16-bit programs on a Terminal Server can reduce the number of users a processor can support by 40 percent and increase the memory required for each user by 50 percent. For this reason, use 32-bit versions of programs whenever possible.

Other application considerations:
Some video active applications can decrease performance. Turn off the video effects of an application for better performance. MS-DOS applications are not recommended because they can consume all of the available CPU. Application features that are always on and run in the background, such as automatic spelling and grammar checking in Microsoft Word, require more system resources.

Microsoft does not specifically test or support any DOS-based application for use with Terminal Server and recommends that you replace any DOS-based application with 32-bit Windows-based applications.

DOSKBD Is not Available Under Windows 2000

There is no such utility for Windows 2000 and the Windows NT 4.0 version does not work in Windows 2000. The current solution for problems that normally would necessitate using DOSKBD is to use Windows NT Server 4.0, Terminal Server Edition. For more information, see Microsoft Article: Q257966

Improving Performance for Clipper-Based Applications

The files included in this archive are intended to patch Clipper 5.x programs so that they do not poll the keyboard excessively. This keyboard polling tends to "hog" the CPU; in other words, one instance of a Clipper program may use 100% of the CPU on a WinFrame or WinView server. This in turn decreases performance for all WinFrame or WinView users.

This patch was developed by Datapac Australia, Ltd., now a part of Citrix Systems, Inc.

Datapac developed a patch for Clipper that inserts a "Release CPU" call to the keyboard loop. The "Release CPU" call is added to the idle procedure in the Clipper keyboard loop. This means that whenever a WinStation is idle at a screen prompt, Clipper makes a call to free the CPU.

This call is INT 2F Function 1680. This call is supported under DOS (5.0+), OS/2 (WinView), and Windows NT (WinFrame). With this call inserted in the Clipper code, Clipper gives up CPU time so other tasks can run.

WARNING: Before running PATCHA, BACK UP THE ORIGINAL PROGRAM !!!

To install the patch, a PATCHA script was developed. You run the PATCHA script over any Clipper program and PATCHA modifies your Clipper executable.

This software is made available "as is;" in no event will Citrix or its suppliers be liable for any damages arising from the use of this software or documentation.

Instructions for Patching Your Clipper Executable

WARNING: Back up your original Clipper Executable before proceeding!!! The Clipper executable is modified by this procedure, so make sure you have a copy of the original!

1. Download the Clip2F.exe utility from: FTP://ftp.citrix.com/Utilities/Clip2F.exe

2. You must edit the Clip2f.pat file to specify the name of your Clipper executable. Edit line 14 of Clip2f.pat to read:

load Program.exe

where Program.exe is the name of your Clipper executable

3. Save Clip2f.pat and execute the following command at a prompt:

PATCHA CLIP2F

This modifies your Clipper executable, inserting the "Release CPU" call.

Improving Performance for Advanced Revelation Version 3.1

Follow the installation procedure in the Advanced Revelation 3.1 manuals and installation documentation. The default DOS keyboard polling detection does not prevent Advanced Revelation 3.1 for DOS from trying to use all the available CPU in the system. Before running Advanced Revelation, run AREVFIX in the DOS window in which you will run Advanced Revelation. AREVFIX is a TSR that prevents Advanced Revelation from using all the CPU in the system. An Advanced Revelation Pif file can be set up to point to a custom Autoexec.nt file that runs AREVFIX before running Advanced Revelation so that a Windows icon can be used.

Guidelines to Improve FoxPro-Based Application Performance on WinFrame 1.x

Installation

1. At a command prompt, type change user /install before installing FoxPro.

2. Follow the installation procedure in the FoxPro for Windows manuals and installation documentation.

3. When installation is complete, at a command prompt, type change user /execute.

Usage

FoxPro for Windows does not perform like a true Windows application because it does not utilize basic Windows displays such as buttons and dialog boxes to create its screen display. It acts more like a DOS application because its display window is actually a bitmap in a video buffer. When any changes are made to the bitmap, the entire bitmap is sent to the display. This can cause some dialog boxes to paint slowly. The Foxpfix.exe utility is used to fix this problem. Follow the steps below to troubleshoot FoxPro for Windows application performance problems.

1. Run Foxpfix.exe with the /Q option to query the state of the executable. To see the effect on performance, try the enabled mode first and then the disabled mode.

2. Test the performance of FoxPro for Windows on the server and the client device.

3. If the performance problem is a client issue, it is probably related to video or screen updates. For WinFrame to compensate for this behavior, the screen design guidelines below are suggested:

• Keep screens as simple as possible. Limit colors and color changes.

• Limit actions to 25% of the active screen area. For example, if an action changes a field or a background, make sure that the changes are kept within the same 25% of the screen area.

• Do not overrun the area in which you are working. If you are working with a 640x480 screen, do not let your screen displays stray outside of this area. Document windows must fit entirely within the main window.

4. If the performance problem is a server issue, use Performance Monitor to verify CPU utilization. If CPU utilization is high, try disabling the Foxpfix utility by executing foxpfix/disable. For additional information, see "Application Performance Tuning" in the WinFrame Readme (Wfreadme.hlp).

Problems with 16-bit Applications

The 16-bit subsystem hasnt changed from WinFrame to MetaFrame, so the same issues and solutions are valid. For example, if two 16-bit applications are running in the same session and one crashes, it could bring down the other. You can avoid this by selecting the Run In Separate Memory Space option. If the two applications are running in different sessions, 16-bit applications do not interfere with each other.

Windows NT is a Win32 (32-bit) environment and Windows 3.x for DOS is a Win16 (16-bit) environment. Windows NT runs Win16 applications through a process called WOW (Win16 on Win32), translating 16-bit applications in enhanced mode. This process causes Win16 applications to consume additional system resources, which reduces the number of users per processor by 20% and increases the memory required per user by 25%. For this reason, use 32-bit versions of applications whenever possible. If you intend to run 16-bit applications, adjust your processor and memory requirements accordingly.

Tuning Windows 16- and 32-Bit Applications

One of the simplest ways of increasing application performance is to use Terminal Connection Configuration to disable background wallpaper. Published applications automatically disable background wallpaper.

ICA Client Keyboard and Mouse Queues

The Citrix ICA Client queues buffer keyboard and mouse data to reduce the number of packets sent. On a slow WAN link, this increases bandwidth utilization by reducing the number of small packets sent. However, on a fast network connection, turning off the keyboard and mouse queues can increase application responsiveness.

NOTE: Turning off keyboard and mouse queues increases the number of packets sent. This is not desirable over WAN links that incur per-packet charges.

You can toggle keyboard and mouse queues individually for each connection in Remote Application Manager.

To turn off keyboard and mouse queues for a connection entry:

1. Run the Citrix ICA Client Remote Application Manager.

2. Highlight the desired connection entry.

3. From the Entry menu, click Properties.

4. On the Connection Options tab, clear the Queue mouse movements and keystrokes check box.

5. Click OK.

Compatibility Bits

Change compatibility bits only if an application is not working properly. Several compatibility bits can be set for an application, registry path, or INI file to change how WinFrame handles the merging of application initialization data when a session is in execute mode. These compatibility bits are set in the registry under:

For WinFrame:

\HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\Compatibility

For MetaFrame:

\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WindowsNT\ CurrentVersion\TerminalServer\Compatibility

There are three separate keys for applications, INI files, and registry path. The default settings work for most applications but can be further tuned using the compatibility bits described below.

See Q186628 and Q198060

The first set of compatibility bits indicates the version of the application that the settings are for. Not all combinations are useful; for example, a DOS application will never make any registry calls. Because the path to the file is not specified and multiple applications can use the same filename (for example, Setup.exe and Install.exe are now regularly used for installation programs), specifying the application type helps ensure the compatibility settings do not affect other applications that have the same filename.

Add together the values of the bits you want to set to get the String value. For example, to return the username instead of the computername for both 16- and 32-bit versions of Myapp.exe, create a key \\HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\Compatibility\Applications\MYAPP.

- Or -

Create a key \\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WindowsNT\ CurrentVersion \TerminalServer\Compatibility\Applications\MYAPP.

Add a value called Flags of type REG_DWORD containing the hex value of 11C (add 0x4 for 16-bit Windows applications, 0x8 for 32-bit Windows applications, 0x10 to return username instead of computername, and 0x100 to disable registry mapping).

Compatibility Keys, Applications

For WinFrame:

\HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\Compatibility\Applications\appname

For MetaFrame:

\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WindowsNT\ CurrentVersion\TerminalServer\Compatibility\Applications\appname

where appname is the name of the applications executable file (for example, if the executable file name for an application is Prog1.exe, appname would be Prog1).

WinFrame provides the following registry entries for Windows application tuning. The entry names and default values are:

FirstCountMsgQPeeksSleepBadApp = 0xF
MsgQBadAppSleepTimeInMillisec = 0x1
NthCountMsgQPeeksSleepBadApp = 0x5
Flags = 0x8

NOTE: A copy of these values is in \Compatibility\Applications\SETUP Key.

Registry Entry Names and Descriptions

FirstCountMsgQPeeksSleepBadApp. The number of times the application monitors the message queue before it decides that it is ill-behaved. Decreasing this value puts the application to sleep more often so it uses less CPU time.

MsgQBadAppSleepTimeInMillisec. The number of milliseconds the application is put to sleep once it is determined that it is ill-behaved. Increasing this value causes the application to use less CPU time.

NthCountMsgQPeeksSleepBadApp. The number of times the application monitors the message queue after it is determined that it is an ill-behaved application for it to be put to sleep again. Decreasing this value causes the application to use less CPU time.

Flags. Controls the type of application to which the bad application flags apply. Set Flags to 0x8 for 32-bit applications only, 0x4 for 16-bit applications only, or 0xC for both 16- and 32-bit applications.

DOS application 0x1
OS/2 application 0x2
Windows 16-bit application 0x4
Windows 32-bit application 0x8
Return username instead of computername 0x10
Return Citrix build number 0x20
Disable registry mapping for this application 0x100
Do not substitute user WINDOWS directory 0x400

Use the "Return username instead of computername" flag for applications that use the computer name as a unique identifier. This returns the users name to the application, thereby giving each user of the application a unique identifier. Use the "Disable registry mapping for this application" to retain only one global copy of the registry variables used by the application. The "Do not substitute users \Windows directory" bit, when set, retains the \SystemRoot directory for GetWindowsDirectory API calls. The default action if this bit is not set is to replace all paths to the \Windows directory with the path to the users \Windows directory.

INI Files

For WinFrame:

\\HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\Compatibility\IniFiles\inifile

For MetaFrame:

\\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WindowsNT\ CurrentVersion\TerminalServer\Compatibility\IniFiles\inifile

where inifile is the name of the INI file (for example, if the INI file name for an application is Prog1.ini, inifile is Prog1):

Windows 16-bit application 0x4
Windows 32-bit application 0x8
Synchronize user INI file to system version 0x40
Do not substitute user WINDOWS directory 0x80

The "Synchronize user INI file to system version" bit, when set, adds new entries from the system master INI file when the application is started, but does not delete any existing data in the users INI file. The default action if this bit is not set is to overwrite the users INI file if it is older than the system master INI file.

The "Do not substitute users \Windows directory" bit, when set, retains the \SystemRoot directory for file paths in the INI file when the system master version of the INI file is copied to the users \Windows directory. The default action if this bit is not set is to replace all paths to the \Windows directory with the path to the users \Windows directory.

Configuration

16-bit Windows applications do not use the registry as 32-bit Windows applications do; they use *.INI files that are in the \Windows directory for Windows 3.x. To maintain compatibility with 16-bit Windows 3.x applications, WinFrame also uses *.INI files to run these applications. WinFrame looks for *.INI files in the User Environment Profile home directory. You can define where to put this directory by selecting Advanced Server User Manager from the Administrative Tools group. Highlight the users name and select Properties from the user menu. Click the Profile button at the bottom of the User Environment Profile dialog box. In the Home Directory section, click Local Path for your local hard drive or Connect to use a network drive. Enter the path and click OK. Click OK in the User Properties dialog box to save your changes.

Citrix strongly recommendeds that all WinFrame users have a home directory. This can be either a directory on the WinFrame server or it can be a network directory. User profiles can be configured either on the local WinFrame server or on a network domain-wide basis on a domain server.

The user must have a home directory path available if WinFrame is to load the application correctly. By default, WinFrame assigns the directory \Users\Default on the local drive where WinFrame is installed. If you have problems with Windows 3.x applications, make sure that the *.INI files are in this directory. If a user-global install of the application was done, the .INI files are copied into the users home directory as the application calls for them.

NOTE: You can read *.INI files with a text editor but DO NOT save any changes. Important information may be lost or damaged.

Network applications that run on Windows 3.x cannot load their own network protocol drivers because WinFrame has its own. These can be configured in Setup or under Network in the Control Panel. If your network application asks which type network transport you are using, you must choose Sockets. This allows your application to use WinFrames network protocol.

Registry Paths

For WinFrame:

\HKEY_LOCAL_MACHINE \SOFTWARE\Citrix\Compatibility\RegistryEntries\pathname

For MetaFrame:

\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WindowsNT\ CurrentVersion\TerminalServer\Compatibility\RegistryEntries\pathname

where pathname is the registry path under the key \\HKEY_CURRENT_USER\SOFTWARE (for example, if the registry variable path for an application is \\HKEY_CURRENT_USER\SOFTWARE\BrandX\Prog1, pathname would be Brandx\Prog1).

Windows 32-bit application 0x8
Disable Registry mapping for application 0x100

The "Disable Registry mapping for application" bit, when set, adds new entries from the system master registry image when the application is started, but does not delete any existing data in the users registry. The default action if this bit is not set is to delete and overwrite the users registry data if it is older than the system master registry data.

The flags below are individual place values; they are not related to each other directly. Each of the eight flags in the 0x0 means something specific. When more than one flag is set, they must be taken collectively.

0x4 sets the 0x? flag, which controls the application type (4 = 16 bit).
0x40 sets the 0x?0 flag, which controls ini sync (4 = ini sync ON).
0x100 sets the 0x?00 flag, which controls Registry mapping (1 = OFF).
0x44 means that this is a 16-bit application with ini sync ON.
0x104 means that registry mapping is off for a 16-bit application.
0x144 means that registry mapping is off for a 16-bit application but ini sync is ON.

A list has not yet been posted of what every flag (place value) does or what the values mean.

The same thing is true for the values to which you can set these places. Values for these flags (when used in the last position) are 1, 2, 4, 8, C, and F.

1 is 0001 in binary
2 is 0010 in binary
4 is 0100 in binary <16-bit>
8 is 1000 in binary <32-bit>
C is 1100 in binary <16- and 32-bit>
F is 1111 in binary

So C (when used in the last position) is both 16-and 32-bit; you know that C is 1100. 16-bit applications are 4 and 32-bit applications are 8. When you add the value for 16-bit (0100) and the value for 32-bit (1000), you get 1100 or C (both 16- and 32-bit).

Other Application Tuning Utilities

DPAKBD. DPAKBD is a TSR that attempts to put errant DOS applications that poll the keyboard incessantly to sleep, thus enabling the CPU to service the rest of its process queue. It must be executed in the same NTVDM as the application but before the application is executed. It is available here: ftp://ftp.citrix.com/utilities/dpakbd.zip

NOTE: This utility is used by customers to improve application efficiency. Direct questions about these products to the product manufacturers.

TAME. This clever product helps your multitasker allocate resources more efficiently, so that applications that need resources get them. When an application is "tamed," it does not allocate CPU cycles from other applications unless it really needs them. Available here: http://www.tamedos.com