Microsoft Corporation
September 1997
Microsoft® Windows NT® "Hydra" is the codename for a project that gives the Windows NT Server operating system the capability to serve 32-bit Windows® operating system–based applications to terminals and terminal emulators running on PC and non-PC desktops. The Hydra environment is, by definition, a thin-client, 100 percent server-centric architecture. Because Hydra terminal-emulator clients will be available for many different desktop platforms (Apple® Macintosh®, UNIX, and others), Hydra provides access to 32-bit Windows–based applications from virtually any desktop. Hydra allows you to roll out 32-bit Windows–based applications to a heterogeneous set of desktops while transitioning to a pure 32-bit desktop environment.
Unlike the traditional client/server environment, an application runs only on the server in the Hydra environment. The Hydra client performs no local processing of applications. The Hydra server operating system transmits only the application presentation—the Graphical User Interface (GUI)—down to the client. Each user logs on and perceives only his or her session, which is transparently managed by the server operating system and is independent from any other client session.
From an application development perspective, one of the biggest benefits of Windows NT Hydra is that the majority of existing 16- or 32-bit application programs run "as is"—no programming changes are required to run them on a Hydra server. This does not, however, mean that all existing 32-bit applications run equally well under Hydra. As with the addition of any new operating system service, understanding how to design applications that take advantage of new capabilities is important. It's also important to understand how this new service can magnify the negative results of bad programming habits, and to point out specific areas to watch for.
Note that following these guidelines does not limit or compromise an application's ability to function in the traditional client/server Windows NT environment: Hydra-optimized applications work well in both environments.
In addition to providing a means to serve Windows-based applications to terminals and other thin-client devices, Windows NT Hydra extends the current multiuser capabilities of Windows NT Server. Of course, Windows NT Server is inherently multiuser in the following ways:
In some ways, Windows NT Hydra is analogous to terminal-based, centralized host, or mainframe environments. Under the central-host architecture, "dumb" terminals provide a simple, character-oriented conduit between the users and the host. Users can log on, run application programs, read and write to shared files, direct output to shared printers, and access shared databases. Furthermore, each user's terminal session functions independently of other terminal sessions because the arbitration between shared resources is performed deep inside the host operating system.
Windows NT Hydra differs somewhat from the centralized host architecture. One of the biggest differences is the graphical nature of the Windows environment. Host environments have traditionally been character-oriented, which requires only a small amount of traffic to travel the communication lines between the host and the terminal or terminal emulator. Under Windows NT Hydra, all of the graphical screen output and related input/output (for example, from a mouse or keyboard) must flow between the desktop client (that is, the Windows-based terminal or terminal emulator) and the Windows NT Hydra server. This means for highly graphical and animated applications, a lot of information travels over the network down to the client device. Fortunately, the display protocol that operates between the Hydra client and the server optimizes this transmission and is completely transparent and irrelevant to the application developer. Additional information on T.Share, the Microsoft display protocol used by Hydra, can be found at the Microsoft Windows NT Server 4.0 Web site (http://www.microsoft.com/ntserver).
Another important difference between the host environment and the Windows NT Hydra environment is the design of applications that run in these environments. In a centralized host environment, applications are designed specifically to run in that environment. Under Windows NT Hydra, applications designed for a Windows-based PC work without being developed explicitly for the Hydra environment. Applications that run on Windows NT today will run on Hydra without modification.
This is important when you consider the implications of multiple users sharing a common Windows NT system concurrently. Instead of having different users running applications using their own local hardware resources (such as CPU, memory, and disk) and local software resources (such as registry settings, preference files, and dynamic-link libraries[DLLs]), users in the Windows NT Hydra environment share the same hardware and software resources. For example, if two users run the same application in a Windows NT Hydra environment, two copies of that application are started in the same system, each operating under a different user context. All of this is managed transparently by the operating system.
Having multiple users access the same set of applications in a common system can create a number of areas of contention, however. These areas include:
Sizing the Windows NT Hydra system with sufficient CPU, memory, and disk resources to handle the client demand can mitigate many of these points of contention. For example, a multiple processor configuration can maximize CPU availability. Installing extra physical memory can maximize memory availability. Finally, configuring multiple small computer system interface (SCSI) channels and distributing your operating system and application loads across different physical drives can maximize disk-access performance. Properly configuring a Hydra server is a critical element of perceived application performance. Deployment guidelines for Hydra system administrators will be available with the product release.
Although hardware sizing is an important part of creating a scalable Windows NT Hydra environment, the software considerations are equally important. In fact, fine-tuning an application often can do a lot to reduce resource competition and improve perceived application performance. With this in mind, the next section of this paper presents simple suggestions that you can implement to create programs that are optimized for the Hydra environment.
This section presents a list of guidelines and suggestions that will allow you to fine-tune your applications for Windows NT Hydra. These guidelines and suggestions are divided into two categories. The first category includes core practices that an application must conform for proper operation under Windows NT Hydra. The second category includes suggestions for optimizing applications for the Windows NT Hydra environment.
The following guidelines describe programmatic behavior that is necessary for an application to operate efficiently and effectively in the Windows NT Hydra environment.
In the Windows NT Hydra environment, each user receives a HKEY_CURRENT_USER registry hive at logon time that corresponds to the user's "real" user hive; however, all users share the HKEY_LOCAL_MACHINE hive. This means that any information placed in the HKEY_LOCAL_MACHINE hive affects all users, while information placed in the HKEY_CURRENT_USER hive affects only one user session.
Some applications make the assumption that one machine equates to one user, and they store user information in the HKEY_LOCAL_MACHINE hive. This practice can create serious problems in a multiuser environment. With this in mind, applications should properly separate global registry information from local (user) registry information, and store information in the correct hive.
In addition to separating global and local information in the registry, global and local file-based data constructs should also be maintained separately. For example, user preference files should not be stored under the system directory (for example, WinNT) or program directory (for example, Program Files) structures. Instead, preference files or other user-specific local data constructs should be stored in the user's home directory or a user-specified directory.
This consideration also applies to temporary files used to store interim information (such as cached data) or to pass data on to another application. User-specific temporary files must also be stored on a per-user basis.
Applications must use locking when accessing databases and all files. This level of locking is essential when multiple users access the same data structures. Any data structure (database or file) that can be changed must be locked while a change is taking place.
The danger of memory leaks is intensified in the Windows NT Hydra environment. A memory leak in an application program running in the traditional client/server Windows NT Server environment will eventually cause trouble. In the Windows NT Hydra environment, that same application can be run multiple times by multiple users, thus rapidly magnifying the effect of a memory leak.
In the traditional distributed client/server Windows NT Server architecture, one user is logged on to one computer at a time; therefore the computer name or Internet Protocol (IP) addresses assigned to either a desktop or a server machine equates to one user. In the Windows NT Hydra environment, each client terminal or terminal emulator has a separate IP address visible only to the Hydra server. The application can only see the IP address of the Windows NT Hydra server.
Applications that use the computer name or IP address for licensing or as a means of identifying an iteration of the application on the network will not work properly in the Windows NT Hydra environment because the server's computer name or IP address can equate to many users.
If your application is composed of a server component (such as a service) and client components (such as foreground applications) that talk to the server component, make sure that the server component can differentiate between multiple clients residing on the same system. To accomplish this, clients should establish communication with the server component through a well-defined global interface (for example, remote procedure calls (RPC) or named pipes) and the server and client should negotiate a different communication channel for each user session.
This same client/server consideration applies to client applications running in the Windows NT Hydra environment that need to establish connections to server components over the network. In this case, the client/server connection should use protocols that easily support this type of operation—such as Transport Control Protocol/Internet Protocol (TCP/IP) where a different socket connection can be used for each client application. Applications should not assume that a single system connection equates to a single user session.
Many applications can be customized at installation time to include or exclude specific features or components. This approach does not work in the Windows NT Hydra environment, because users typically access a common set of applications program files and libraries. Therefore, if the administrator excludes a component during the initial setup of the application on the Hydra server, all users will be prevented from accessing that component.
A better way of addressing customization—in both Windows NT Hydra and the traditional client/server Windows NT Server—is to enable feature selection through user profiles. To adopt this approach, determine feature selection or deselection at run time based on settings in the current user's registry hives. Then create a template file for the Systems Policy Editor so an administrator can configure which features are available for which users.
The Windows NT Hydra environment supports traditional serial, parallel, and sound ports attached to the server, but not serial, parallel, and sound ports that are integrated into the client desktop system (except for keyboard and mouse). This means that the hardware environment can appear different to the application when it runs in different user contexts.
If an application performs output, the application should get a description of the client device environment for the current user context. By examining the client device environment for the current user, the application can verify if sound or printing or other peripherals are supported and determine what serial/parallel ports are available for use. For example, local client printing or drive access is not available in the first release of the Hydra T.Share client, thus print or file access to or from the client must use network redirection.
An application program can detect if it is being installed in or is running in the Windows NT Hydra environment. Once that determination is made, the application can then optimize its behavior, based on the suggestions presented in this section.
You can check to see if your application is running in the Windows NT Hydra environment by using the product suite concept that was added to Windows NT 4.0 Service Pack 3. A set of product suite application programming interfaces (APIs) will be added to the Win32® API suite starting with Windows NT 5.0. In the meantime, Appendix A contains an example function, called ValidateProductSuite, which can be used to determine if a particular product suite has been installed. If Hydra is installed, the product suite registry entry will contain the string "Terminal Server." Using the example function, a Windows NT Hydra system can be detected with the following code:
BOOl fIsHydra;
fIsHydra = ValidateProductSuite( TEXT("Terminal Server") );
Background tasks provide a mechanism for handling low-priority tasks in a single-user environment. In the Windows NT Hydra environment, the scheduler is optimized for interactive responsiveness of foreground tasks (more like Windows NT Workstation than Windows NT Server). Also, the demands of running many interactive sessions on a single server required some architectural changes to the kernel, which resulted in a small system cache. This means that one user's background task will compete for CPU cycles with another user's foreground tasks. When multiple users are running both foreground and background tasks, the CPU demands are much higher than when all users are running only foreground tasks. To maximize CPU availability for all users, create efficient background tasks that are not resource-intensive.
Threads provide a convenient way of allowing an application to maximize its usage of CPU resources in a system, especially in a multiple processor configuration. When this same technique is used in a Windows NT Hydra environment, the thread demands are intensified. In the Hydra environment, multiple users are running multi-threaded applications, and all of the threads for all of the users compete for the central CPU resources of that system. With this in mind, you should tune and balance application thread usage for the multiuser, multiprocessor Windows NT Hydra environment.
Splash screens—graphical product or company information that displays while an application is starting—work well in local video environments because of the speed of delivery. When that same splash screen is transmitted to a Hydra desktop client over the network, the transmission consumes extra network bandwidth and forces the user to wait before accessing the application. Limit the use of splash screens to speed up the application start-up process and to enhance the end-user experience.
When a program uses on-screen animation, that animation consumes both CPU time and video bandwidth. This has several ramifications in the Windows NT Hydra environment. First, the resource consumption of animation affects other users; while one user is staring at an animated icon on his screen, he is depriving other users of CPU access and network bandwidth. Second, the actual effect of the animation is compromised because the video output is being rerouted over the network. Therefore, to decrease network activity and to improve the user's perception of the application, keep the use of animation to a minimum.
Many programmers are accustomed to the speed of a local video subsystem—a local subsystem is typically fast enough to prevent the user from seeing multiple images or windows being overlaid on the screen. This is not the case when the video stream flows over a network connection. In this case, the user will see (and be frustrated by) the amount of time it takes to render the final screen.
Applications should avoid direct input or output to the video display. If an application needs to read bits from the screen, it should maintain a separate, off-screen copy of the video buffer. Similarly, if an application needs to do elaborate screen output—for example, if it needs to overlay several images to arrive at a final composite screen—the application should do that work in an off-screen buffer, and then send the results to the actual video buffer.
User input and prompts should be handled by foreground applications and not by services called by those applications. In the Windows NT Hydra environment, if a user runs an application that calls a service that requests console input, the application will appear to stop (hang) until the input is satisfied from the server console and not the desktop.
The automated setup procedure for many existing applications assumes that the application is installed for a single user, and it therefore updates the registry hive and desktop environment for one user. If additional users need to access that application, either the entire package must be installed again or an administrator must manually copy information from the registry and desktop of one user to the other users.
The Windows NT Hydra environment, however, assumes that more than one user will access an application on a system. Therefore it is appropriate to install applications into the default user environment common to all users when installing under the Hydra environment.
The MFC library has a long list of tried-and-true classes for performing a wide variety of tasks. Most of these classes work well in the Windows NT Hydra environment—usually much better than do re-engineered solutions. A good example is the class available to provide context-sensitive, pop-up help text (text that appears on-screen when the cursor hovers over a button or menu item). If an application uses the MFC implementation to provide this feature, it will work reasonably well on the desktop system. But if the application implements this feature using dialog boxes or an alternate approach, the final result may not function well in the multiuser Windows NT environment.
The Windows NT Server operating environment has specific host requirements for MS-DOS®–based and 16-bit Windows–based applications. These requirements also apply to the Windows NT Hydra environment—any MS-DOS or 16-bit Windows–based application that does not run under Windows NT Server will not run under Windows NT Hydra. Windows NT Hydra is, however, more sensitive to ill-behaved legacy applications than the traditional Windows NT Server client/server environment is because a single ill-behaved application can affect all of the users on the Windows NT Hydra system.
Predicting the legacy applications that will work well in the Windows NT Hydra environment and those that will not is difficult. In most cases, the only real way of determining a specific application's feasibility is to test it in the Windows NT Hydra environment. However, there are some application behaviors and origins that are not conducive to the Windows NT Hydra environment:
The amount of work to bring an application in line with the Windows NT Hydra guidelines will vary from one application to another. If an application was designed to operate in a multiuser network environment, chances are it will take very little tweaking to turn it into an application that is optimized for Windows NT Hydra. Single-user applications may pose a few more difficulties.
This document has presented a variety of guidelines and suggestions for fine-tuning applications for Windows NT Hydra environment. All of these guidelines and suggestions should be taken into consideration when you develop 32-bit applications; however, the three main points you should remember about the Windows NT Hydra environment are:
By taking these points into consideration, developers can ensure their applications are better behaved in both the traditional client/server Windows NT Server environment and in the Windows NT Hydra environment.
Please refer to the Microsoft Win32 Web site (http://www.microsoft.com/win32dev) section "Guidelines," for additional information on porting 16-bit applications to the 32-bit Windows environment.
For the latest information on Windows NT Server and Hydra, see the Microsoft Windows NT Server 4.0 Web site (http://www.microsoft.com/ntserver).
For additional information on application behavior in the Citrix WinFrame environment, please refer to the Citrix article entitled "Application Considerations in a WinFrame MultiUser Environment" at the Citrix Systems Inc. Web site (http://www.citrix.com/), by selecting the "Technology" link.
The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication.
This article is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS DOCUMENT.