DOCUMENT:Q186498 11-JUN-2002 [winnt] TITLE :Terminal Server Application Integration Information PRODUCT :Microsoft Windows NT PROD/VER:winnt:4.0 OPER/SYS: KEYWORDS: ====================================================================== ------------------------------------------------------------------------------- The information in this article applies to: - Microsoft Windows NT Server version 4.0, Terminal Server Edition ------------------------------------------------------------------------------- IMPORTANT: This article contains information about modifying the registry. Before you modify the registry, make sure to back it up and make sure that you understand how to restore the registry if a problem occurs. For information about how to back up, restore, and edit the registry, click the following article number to view the article in the Microsoft Knowledge Base: Q256986 Description of the Microsoft Windows Registry SUMMARY ======= This article describes the process of installing applications for multiuser use on a Terminal Server computer. This article includes guidelines for application integration, descriptions of installation and execution modes, and registry settings for application control. MORE INFORMATION ================ Log on as an Administrator to the Terminal Server computer, to install applications. Back up the SYS and DLL files in your SystemRoot directory (SystemRoot is the directory you selected to install the Terminal Server) operating system and in %SystemRoot%\System32 directories before installation, because some applications attempt to put their own DLL files into these directories. If it is not possible to back up these files, type the following commands DIR\%SystemRoot%\System32 > LPT1: -OR- DIR\%SystemRoot% \System32 > Sys32dir.txt -AND- DIR\%SystemRoot%\System32 > LPT1: -OR- DIR \%SystemRoot% > Winntdir.txt If the installation replaces any of the original Terminal Server files that specifically address the Terminal Server operating system, it could be the source of application problems. After the installation is complete, compare the directories and, if necessary, copy back some of the files. Application Integration ----------------------- When you integrate an application into a Terminal Server environment, your primary areas of consideration are: - Application installation and configuration - Application network communications - Application video performance Some applications have characteristics that, although relatively benign in a single-user environment, may lead to decreased performance, or application incompatibilities, in a Terminal Server multiuser distributed presentation environment. Understanding and avoiding (if possible) these characteristics helps ensure the smooth integration of an application into a Terminal Server environment. As a rule, follow the application guidelines below when selecting or developing applications: - Win32 (32-bit Windows) applications are preferred over Win16 (16-bit Windows) applications. Terminal Server runs Win16 applications through a process called "Win16 on Win32," which causes Win16 applications to consume about 20 percent more resources than comparable Win32 applications. - The Windows INI files must be accessed using the proper Windows NT APIs so that the INI file synchronization features of Terminal Server work properly. - Applications (primarily MS-DOS applications) that poll a hardware device or the keyboard, rather than waiting for an event can have an adverse effect on system performance. You can use the DOSKBD command to tune MS-DOS applications that perform excessive keyboard polling. Use the Windows NT APIs instead of building custom code, whenever possible. Many Windows NT APIs have Terminal Server MultiWin enhancements to seamlessly support a multi-user environment. - Avoid hard-coding paths and network identifiers. - NetWare applications must be able to run in bindery mode. - MS-DOS graphics are not supported on Terminal Server clients. - Avoid using bitmaps in graphics. Use vector-based graphics instead. Use the raster operator to brush graphics on the screen for best performance. - VxDs are not supported in a Windows NT or Terminal Server environment. The following sections discuss some of these guidelines in greater detail. Application Installation and Configuration ------------------------------------------ In a multiuser environment such as Terminal Server, it is essential that all users be able to make use of the same applications concurrently, without interfering with each other's preference settings or data. The first and most important step is to assign each user a unique home directory (for example, C:\Users\%Username%). Although a default home directory is automatically created for each user in the user's profile, this can cause the user's profile to grow tremendously, slowing the logon process, and increasing system resource use. To avoid this problem, and to allow applications to work properly, use User Manager for Domains to assign a separate home directory to each user. To configure existing users to use separate home directories, perform the following steps: 1. Log on as an Administrator and start User Manager for Domains. 2. If you are logged on to the domain and want to change local users, on the User menu, click Select Domain, and then type in the name of the Terminal Server computer the user accounts are on. 3. Select the users you want to change. To select multiple users, press and hold the SHIFT key while using the up and down arrow keys. To select all users in a specific group, on the User menu, click Select Users. 4. On the User menu, click Properties. 5. Click Profile. 6. Click the option button next to Local Path and type drive:\Users\%Username% where "drive" is the drive on which Terminal Server is installed (usually drive C), and "Users" is the directory created by the system for home directories. NOTE: Although Users is the directory created for home directories, any directory can be created and used. 7. Click OK to return to the User Properties dialog box. 8. Click OK to return to the User Manager for Domains main screen. MS-DOS and OS/2 text applications can generally be installed and used without modification. MS-DOS applications that perform keyboard polling may need tuning with the DOSKBD command to avoid excessive resource consumption. Windows applications often use Windows features, such as the system registry and INI files. Some of the information in these files is common to all users, and some information is user-specific, which may require some application customization. There are two ways to install 16-bit or 32-bit Windows applications in a Terminal Server environment: user-specific and user-global. User-Specific Installation -------------------------- User-specific means that a specific user installs the application for his or her own use. The default installation is user-specific. Any INI files or other files that the application tries to place in the default Windows directory are installed to that user's home Windows directory. Even if the application is installed to a network or shared directory, other users may not have access to all the DLL and INI files needed to run the application. The user must do a user-specific installation. In short, a separate installation must be done for each user who wants to use the application. If an application is installed using the user-specific method, no special considerations regarding the storage and retrieval of data are needed. However, because each application must be completely installed for each user, this method can consume a large amount of disk space, and adds to administrative overhead in larger environments. Some applications offer the option of doing a network installation. This process copies the installation disks or CD-ROM files to a common directory on the network from which individual users can then run a setup or installation utility. This copies the required INI files to their home Windows directory. Although this process uses less space on the Terminal Server computer than multiple user-specific installations, it still requires that a separate process be run for each user. User-Global ----------- Microsoft recommends using the user-global method of installing Windows Applications. With this method, an application is installed one time by an Administrator, and can be run by anyone who logs on to that Terminal Server computer. To perform a user-global installation, use the Control Panel Add/Remove Programs tool, or type "change user /install" (without quotation marks) at the command prompt to place the session into installation mode. Either of these methods will ensure that any INI files are installed to the Terminal Server system directory, instead of the user's home Windows directory. When the installation is complete, click FINISH if you used the Add/Remove Programs tool, or use the Change User or Execute command, to place the session back into execute mode. When a user starts the application for the first time, the required user-specific files are automatically copied to the user's home directory. Most Win32 applications install in a pseudo user-global fashion by default, even when the session is not in installation mode. These applications make use of Terminal Server's registry, where each user can have a unique set of registry settings. Win16 applications use INI files for configuration settings. They must be installed using installation mode so that multiple users have separate copies of these files. It is recommended that you always install any Windows application, whether 16-bit or 32-bit, using installation mode. NOTE: The most common mistake in application installation is to insert an application compact disc, let it start with AutoRun, and bring up its installation options, and then install it from the CD's startup options. This installs the application only for the currently logged on user. Reinstall the application using one of the two methods that follow. Microsoft recommends installing applications through the Control Panel Add/Remove Programs tool. To perform a user-global installation using the Add/Remove Programs tool, complete the following steps: 1. Log on to the Terminal Server computer as an Administrator. 2. Click Start, point to Settings, click Control Panel, and then double-click Add/Remove Programs. 3. Click Install to start the installation process. It will automatically look for a setup program. If the Add/Remove Programs tool cannot find it, you can browse and select the setup program on your hard disk, compact disc, network share, and so forth. You will get the option to install for all users, or just for the currently logged on user. Installing for All Users places the system in installation mode and allows Terminal Server to keep track of the user-specific application registry entries, INI files, and DLL files that the application adds to the Terminal Server system, during installation. 4. Install the application according to its instructions. If you are prompted to type your name during the installation process, you may want to give a generic name, because the name will be the default for all users. Configure any default program settings you want all users to have. 5. When installation is complete, click FINISH in the Add/Remove Programs tool, which returns the system to execute mode. It is okay to shut down and restart the server if you are prompted to. When the server restarts, it always starts in execute mode. Proceed to step 6, below. To perform a user-global installation using the command prompt, complete the following steps: 1. Log on to the Terminal Server computer as Administrator. 2. Click the START button, point to Programs, and then click Command Prompt. 3. At an MS-DOS command prompt, type the following command: change user /install This command places the system in installation mode and allows Terminal Server to keep track of the user-specific application registry entries, INI files, and DLL files that the application adds to the Terminal Server system, during installation. 4. Install the application according to its instructions. If you are prompted to type your name during the installation process, you may want to give a generic name, because the name will be the default for all users. Configure any default program settings you want all users to have. 5. After the installation is complete, switch to the MS-DOS command prompt and type the following command: change user /execute This command returns the system to execute mode. It is okay to shut down and restart the computer if you are prompted to. When the server restarts, it always starts in execute mode. Proceed to step 6, below. Steps Common to Both Installation Modes: 6. Verify that any icon groups that the application created are located in the All Users profile (the equivalent of common groups in Citrix Winframe or Windows NT 3.51), which is located in the %SystemRoot%\Profiles directorySpecifically. Check that the icons were created in the Profiles\All Users\Start Menu\Programs directory. Icons created here will appear in the lower (common) portion of the user's Program menu on the START menu. Icons created in the user's profile, or in the Default User profile, appear in the upper (personal) portion of Programs menu on the START menu. Some applications are hard-coded to write to the user's profile only. Simply copy the icons to the All Users profile. 7. Log off and log back on as a user to verify that the application works correctly. Make sure that any shared resources, such as network drives or printers, are set up for each user, before you run the application. Check the software documentation for any notes that may apply to the installation or the use of the application. 8. Write-protect the application's directory from all non-Administrator users. This allows users to read the program files, and protects them from inadvertent changes or deletion. NOTE: If you installed to an NTFS partition, the security options in Windows NT Explorer allow you to set the security for a wide array of Options. They restrict access only to specific users or groups. If the application was installed on a FAT partition, you can use the ATTRIB command to mark the files and directories as read-only, but you cannot use the advanced security features of NTFS. For this reason, it is recommended that you install Terminal Server, and all applications, on NTFS partitions. Although using NTFS is not a requirement, it does provide a wider range of security options. If the applications reside on a NetWare file server, use the FILER program to set the security options. If you need to determine whether the system is in execute or installation mode, type the following at the MS-DOS command prompt: change user /query You can tune the exact actions performed when a user-global application is started and optimized by creating and setting compatibility bits in registry variables associated with the application. The following sections describe what happens in installation mode and execute mode. Installation Mode ----------------- Putting a user's session in installation mode before installing an application causes the application to be installed in the %SystemRoot% directory, rather than in the user's home directory. Whenever a user's session is in installation mode, all changes made to an application's INI files are written to this central location. Placing the session in installation mode allows Terminal Server to keep track of the user-specific application registry entries and any INI files that the application may install during installation. This allows Terminal Server to automatically propagate these registry keys and files to each user as they are needed by applications while in execute mode. After an application has been installed, return the user's session to execute mode. This avoids writing user-specific data to the initial user-global installation. When a session is in installation mode, the following happens when installing an application: WARNING: If you use Registry Editor incorrectly, you may cause serious problems that may require you to reinstall your operating system. Microsoft cannot guarantee that you can solve problems that result from using Registry Editor incorrectly. Use Registry Editor at your own risk. - All registry entries that are created for the current user are shadowed in the following subkey: HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT \CurrentVersion\Terminal Server\Install NOTE: The registry path above is one address. It has been wrapped for readability. - Registry keys added by an application to the HKEY_LOCAL_MACHINE hive are copied in the following subkey: HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT \CurrentVersion\Terminal Server\Install\Machine NOTE: The registry path above is one address. It has been wrapped for readability. - If an application queries the WINDOWS directory using the GetWindowsDirectory API, Terminal Server returns the %SystemRoot% Directory. If any INI file entries are added using the WritePrivateProfileString API, they are added to the INI files in the %SystemRoot% directory. - If the application does not use these APIs for modifying INI files, the results will be unpredictable, and can cause performance or usability problems. Execute Mode ------------ Execute mode is the default mode when a user logs on. Terminal Server compares the INI files in %SystemRoot% to the INI files in the user's home Windows directory. What happens when a %SystemRoot% INI file is newer than the INI file in the user's home directory is controlled by the 0x00000040 bit of the registry value for the file, which is located in the following subkey: HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion \Terminal Server\Compatibility\IniFiles NOTE: The registry path above is one address. It has been wrapped for readability. If the bit is 0 (zero), or the value does not exist, the user's INI file is over-written with the newer version of the INI file in %SystemRoot%. If the bit is 1, the user's INI file is merged with the newer %SystemRoot% INI file. The user's previous version of the INI file is renamed to Inifile.ctx, where Inifile is the name of the INI file. WARNING: You can read INI files with a text editor but do not save any changes. Terminal Server has no way of knowing that the file has been updated. The changes may be lost and the file may be damaged. The user's registry values are loaded from his or her user profile (or from the default profile, if no user profile exists for them), and are stored in HKEY_USERS\SID, where SID is the security identifier for the user's account. The values are then compared with the system values stored in the following subkey: HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT \CurrentVersion\Terminal Server\Install NOTE: The registry path above is one address. It has been wrapped for readability. If the user's keys are older, they are deleted and replaced with the system versions. Registry mapping is disabled if the 0x00000100 bit of the registry value is set to 1 for the following subkey: HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion \Terminal Server\Compatibility\Applications NOTE: The registry path above is one address. It has been wrapped for readability. HKEY_CURRENT_USER will point to the HKEY_USERS path for the current user, when there are multiple users on the Terminal Server computer. While an application is running, the following occurs: - When an application tries to read a registry entry under HKEY_CURRENT_USER that does not exist, Terminal Server checks for the key in the following location: HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion \Terminal Server\Install If the requested key exists, the key and its subkeys are copied to the appropriate location in HKEY_CURRENT_USER. - When an application uses the GetPrivateProfileString API to read an INI file that does not exist in the user's home Windows directory, Terminal Server checks for the INI file in %SystemRoot%. If the INI file exists in %SystemRoot%, the INI file is copied to the user's home directory. When an application queries the Windows directory path using the GetWindowsDirectory API, Terminal Server returns the user's home directory. Controlling Application Execution in Execute Mode ------------------------------------------------- Several compatibility bits can be set for an application, registry path, or INI file to change how Terminal Server handles the merging of application initialization data, when a session is in execute mode. These compatibility bits are set in the registry in the following subkey: HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT \CurrentVersion\Terminal Server\Compatibility NOTE: The registry path above is one address. It has been wrapped for readability. There are three separate keys for applications, INI files, and registry entries under this registry path. The default settings work for most applications, but can be further tuned, using the compatibility bits described below. WARNING: These compatibility bits should only be changed if an application is not working properly. The first set of compatibility bits indicates the version of the application that the settings are for. Not all combinations are useful; for example, an MS-DOS application will never make any registry calls. Because the path to the file is not specified, and multiple applications may use the same filename (for example, Setup.exe and Install.exe are now regularly used for installation programs), specifying the application type will help ensure that the compatibility settings do not affect other applications that have the same filename. Add the values of the bits you want to set, to get the String Value. For example, to return the user name instead of the computer name for both 16- bit and 32-bit versions of Myapp.exe, create a registry key in the following location: WARNING: If you use Registry Editor incorrectly, you may cause serious problems that may require you to reinstall your operating system. Microsoft cannot guarantee that you can solve problems that result from using Registry Editor incorrectly. Use Registry Editor at your own risk. 1. Start Registry Editor (Regedt32.exe), and go to the following subkey: HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion \Terminal Server\Compatibility\Applications\Myapp 2. On the Edit menu, click Add Value and type the following information: Value Name: Flags of Type: REG_DWORD Type the hex value of 11C (add 0x00000004 for 16-bit Windows applications, 0x00000008 for 32-bit Windows applications , 0x00000010, to return the user name instead of the computer name, and 0x00000100 to disable registry mapping). Applications ------------ The compatibility bits below affect the application when it is running. They are located in the following registry subkey: HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion \Terminal Server\Compatibility\Applications\Appname NOTE: Appname is the name of the application's executable file (for example, if the executable file name for an application is Prog1.exe, the appname would be PROG1). Compatibility Bits: - DOS application: 0x00000001 - OS/2 application: 0x00000002 - Windows 16-bit application: 0x00000004 - Windows 32-bit application: 0x00000008 - Return user name instead of computer name: 0x00000010 - Return Terminal Server build number: 0x00000020 - Disable registry mapping for this application: 0x00000100 - Do not substitute user Windows directory: 0x00000400 Use the "Return user name instead of computer name" flag for applications that use the computer name as a unique identifier. This returns the user's name to the application, thereby giving each user of the application a unique identifier. Use "Disable registry mapping for this application" to retain only one global copy of the registry variables used by the application. The "Do not substitute user 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 user's Windows directory. INI Files --------- The compatibility bits below are located in the following registry path. They control INI file propagation. HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion \Terminal Server\Compatibility\IniFiles\Inifile NOTE: Inifile is the name of the INI file (for example, if the INI file name for an application is Prog1.ini, the Inifile would be PROG1) Compatibility Bits: - Windows 16-bit application: 0x00000004 - Windows 32-bit application: 0x00000008 - Synchronize user INI file to system version: 0x00000040 - Do not substitute user Windows directory: 0x00000080 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, and does not delete any existing data in the user's INI file. If this bit is not set, the default action is to overwrite the user's INI file, if it is older than the system master INI file. When set, the "Do not substitute user Windows directory" bit retains the SystemRoot directory for file paths in the INI file when the system master version of the INI file is copied to the user's Windows directory. If this bit is not set, the default action is to replace all paths to the Windows directory, with the path to the user's Windows directory. Registry Paths -------------- The compatibility bits below are located in the following registry subkey, and control registry propagation. HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion \Terminal Server\Compatibility\RegistryEntries\Pathname NOTE: Pathname is the registry path in the HKEY_CURRENT_USER\Software key (for example, if the registry variable path for an application is HKEY_CURRENT_USER\Software\BrandX\PROG1, the pathname would be Brandx\PROG1). Compatibility Bits: - Windows 32-bit application: 0x00000008 - Disable registry mapping for application: 0x00000100 When set, the "Disable registry mapping for application" bit adds new entries from the system master registry image, when the application is started. It does not delete any existing data in the user's registry. If this bit is not set, the default action is to delete and write over the user's registry data if it is older than the system master registry data. Required API Usage for Application Compatibility ------------------------------------------------ To fully use the user-global installation feature of Terminal Server, an application must use the proper APIs to read and write INI file and registry information. 16-bit Applications ------------------- The 16-bit applications must use the GetPrivateProfileString API to read an INI file, and the WritePrivateProfileString API to write to an INI file. 32-bit Applications ------------------- The 32-bit applications must use the registry APIs to update registry keys. These APIs include: RegOpenKeyEx RegCloseKeyEx RegEnumKeyEx RegDeleteKeyEx RegQueryValueEx RegSetValueEx Using these APIs in installation mode will time stamp the entry and cause an update of each user's registry settings on his or her next logon attempt. Manually editing the registry does not change the time stamp for the registry entry, and the changes will not be propagated to users when they log on. Application Network Integration ------------------------------- In addition to the Windows NT environment requirements, the following considerations may apply to network-aware applications in a Terminal Server environment: Unique network addresses Gateways NetWare NDS requirements Unique Network Addresses ------------------------ Some applications are designed to require a unique network interface card (NIC) address, for each instance of the application. An example of this design is a client/server application that requires a unique IP address for each client connecting to a server. An application designed to communicate in this way allows only one concurrent instance of its client to run on a Terminal Server computer. For an application to properly communicate in a Terminal Server MultiWin environment, the application must be able to negotiate a unique socket. The ability to negotiate a unique socket is a key component in the design of a compatible network application. Hard-coding any part of the address scheme may lead to incompatibilities. If two applications try to communicate through the same address, incorrect operation and application failure may result. TCP/IP ------ Some applications that use the TCP/IP protocol to communicate use the IP address as a hard-coded identifier of the client. Multiple instances of these applications will not run in a Terminal Server MultiWin environment. For an application to properly communicate in a MultiWin environment, the application must be able to negotiate a private socket. This allows the client and server to communicate using a unique IP/PORT/SOCKET address. IPX --- Some applications that use IPX use a hard-coded socket for communications, relying on a NIC address as the unique identifier. These applications will not run in a Terminal Server MultiWin environment, because all users communicate over the same NIC address, causing incorrect program operation. NetBEUI and NetBIOS ------------------- Some applications that use NetBEUI or NetBIOS use a specific name as the unique identifier. These applications will not run in a Terminal Server MultiWin environment, because all users communicate using the same specific name, causing incorrect program operation. Gateways -------- Some mainframe connectivity products use the network address of the NIC as a session and user identifier. These products are limited to one concurrent user on a Terminal Server. In these cases, the only solution is to use a data communications gateway between the Terminal Server and the minicomputer. The terminal emulator can then use a virtual socket-based protocol (for example, IPX) to communicate with the gateway, allowing multiple users on the Terminal Server to use the product. Novell NetWare NDS Requirements ------------------------------- Terminal Server users can be authenticated by, and use resources in, a NetWare NDS (NetWare 4.x) environment. Most applications running in the NDS environment do not use the NDS-specific APIs. They run exactly as they would if they were in a NetWare bindery (NetWare 3.x) environment. Applications running on a Terminal Server computer must be able to operate in a NetWare bindery environment, because NDS-specific APIs are not supported. Other Networking Considerations ------------------------------- For best performance, do not install the server component of client/server software, such as Microsoft SQL Server, on the Terminal Server computer. These components are very resource-intensive and may affect the performance of multiple Terminal Server user sessions. Terminal Server is tuned to run multiple user environments rather than a server environment. It may be helpful to think of Terminal Server as a collection of virtual computers running Windows NT Workstations. For example, computers running Windows NT Workstation allow processes only a few cycles of CPU time before switching to other waiting processes. This enhances the multitasking of user applications. Terminal Server is tuned to handle processes the same way that Windows NT Server is tuned differently, allowing server application (for example, SQL Server or Microsoft Exchange Server) processes to use the CPU for much longer periods of time before switching to other queued processes. If you use a COM server application for Terminal Server clients, the server portion of the application cannot be installed on the same Terminal Server computer to which clients connect. It can be placed on other Terminal Servers (if necessary), or on other non-Terminal Server resources, which is recommended. The limitation of COM applications is that the client and server portions cannot run on the same Terminal Server computer. Terminal Server RDP Client and Citrix ICA Clients ------------------------------------------------- Microsoft's Remote Desktop Protocol (RDP) client and Citrix ICA clients have many common features. Both are designed for high-performance Windows presentation services over low-bandwidth connections. Microsoft's RDP client and Citrix ICA clients include the following: - Graphical Windows application screen presentation - Keyboard and mouse input - Session control - Error detection and recovery - Encryption - Data compression - Multiple security levels - General purpose Terminal Server browsing Citrix ICA clients add the following: - Full-screen text presentation - Framing for asynchronous connections - File system redirection - Print redirection - COM port redirection - Multiple generic virtual channels - Cut and paste across clients and servers - Multiple operating system platforms, including MS-DOS, Windows 3.1, Macintosh, UNIX To use the Citrix ICA client with Terminal Server, install the Citrix add- on service, code-named Metaframe, currently in beta. Metaframe also allows administrators to define SPX, NetBEUI, and asynchronous connections in Terminal Server Connection Configuration. The initial release of Terminal Server uses only a TCP/IP connection (RDP is encapsulated, using TCP for transport and connecting at port 3389). Both the RDP and ICA clients are designed to efficiently transmit keyboard, mouse, and video information. Microsoft and Citrix recommend the following guidelines for graphics: Graphics and Font Considerations: - Use vector graphics instead of bit-mapped images for graphics. - Use the raster operator to brush graphics to the screen. Bitmaps require more bandwidth than vector graphics, because all of the image data for each unique bitmap must be transmitted from the server at least one time. RDP and ICA clients compensate for this by caching each unique bitmap on the client system. When a bitmap is to be displayed, it is compared with the client's locally cached bitmaps. If the displayed bitmap matches one that is already cached at the client, a command is sent telling the client to redisplay the local copy instead of sending the image over the network. The use of TrueType fonts is preferred because these fonts are stored on the client. If an application must use custom or Adobe fonts, make sure the fonts are configured as embedded Windows NT fonts to allow faster display. More font technology is now being embedded in the Windows NT kernel; this will improve performance in future versions of Terminal Server. For RDP clients, fonts are the reason why full-screen MS-DOS mode has been disabled. To enable full-screen MS-DOS, an entire font set must be downloaded, because TrueType fonts cannot be used. This would cause performance to degrade severely, so the feature has been disabled. Blinking cursors cause unnecessary bandwidth use, because every blink requires data packets to be transmitted. Applications that do not use a blinking cursor, or that allow the blinking cursor to be disabled, are preferred. This can be configured with the Control Panel tool. Additional query words: ====================================================================== Keywords : Technology : kbWinNTsearch kbWinNT400search kbWinNTSsearch kbWinNTS400search kbNTTermServ400 kbNTTermServSearch Version : winnt:4.0 Issue type : kbinfo ============================================================================= THE INFORMATION PROVIDED IN THE MICROSOFT KNOWLEDGE BASE IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND. MICROSOFT DISCLAIMS ALL WARRANTIES, EITHER EXPRESS OR IMPLIED, INCLUDING THE WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. IN NO EVENT SHALL MICROSOFT CORPORATION OR ITS SUPPLIERS BE LIABLE FOR ANY DAMAGES WHATSOEVER INCLUDING DIRECT, INDIRECT, INCIDENTAL, CONSEQUENTIAL, LOSS OF BUSINESS PROFITS OR SPECIAL DAMAGES, EVEN IF MICROSOFT CORPORATION OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. SOME STATES DO NOT ALLOW THE EXCLUSION OR LIMITATION OF LIABILITY FOR CONSEQUENTIAL OR INCIDENTAL DAMAGES SO THE FOREGOING LIMITATION MAY NOT APPLY. Copyright Microsoft Corporation 2002.