Terminal Server Architecture

Archived content. No warranty is made as to technical accuracy. Content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

By Ted Harwood

Archived content - No warranty is made as to technical accuracy. Content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

Chapter 3 from Windows NT Terminal Server and Citrix MetaFrame, published by New Riders Publishing

It is time to begin your exploration of the core architecture of the Terminal Server operating system. Because Terminal Server is based on Windows NT Server 4.0 you will find that, for the most part, their architecture is very similar. For those who are already familiar with the intricacies of Windows NT Server 4.0, the chapter begins with a discussion of the main differences between Windows NT Server 4.0 and Terminal Server. You will learn how, in the Terminal Server Edition, key components of NT Server 4.0 have been rewritten to support a multiuser environment.

For those who want more, this discussion is followed by a much more detailed coverage of Terminal Server architecture. This information is fundamental to your understanding and administration of the Terminal Server product.

On This Page

Architectural Differences Between Terminal Server and NT Server 4.0
Windows NT Design Goals
Components of the Terminal Server Architecture

Architectural Differences Between Terminal Server and NT Server 4.0

Before you get into the details of both NT Server 4.0 and Terminal Server 4.0 architecture, spend a moment learning the differences between the two. The fundamental difference is that Terminal Server architecture supports multiple sessions or desktops running at the same time, whereas NT Server 4.0 supports only one—the console. Each session running on Terminal Server must be isolated from the actions of all other sessions. Terminal Server handles this need by assigning each new session a unique Session ID. The Session ID is used to keep track of and keep separate each session's resources.

Although many components of the NT Server 4.0 architecture have been modified in Terminal Server, the three most significant components that have changed are the Object Manager, Win 32 subsystem, and the Virtual Memory Manager.

Differences in the Object Manager

The Object Manager is responsible for creating, managing, and deleting operating system and application objects. In the multiuser environment of Terminal Server each session must keep its objects separate from those of the other sessions. To keep them separate, Terminal Server appends the Session ID onto the end of each object that is created within the session.

Using the query object Terminal Server command, you can actually see this process in action. The query object command shows you a list of all current objects on the system. The list is usually rather long so you may need to dump it to a text file (query object > objects.txt).

The following output shows two of the many objects in the object list. Note the :1 and :0 that have been appended to the object names. These are the Session IDs of the sessions that these objects belong to. Had Terminal Server not kept these identical object names unique, using the Session ID number, they could not have been created.

C:> query object

.....

\BaseNamedObjects\NDDEAgent:1 Semaphore

\BaseNamedObjects\NDDEAgent:0 Semaphore

......

Differences in the Win 32 Subsystem

The Win 32 subsystem mainly handles graphical display requests and other Win 32 API calls for applications running on Terminal Server. On NT Server 4.0, a single instance of this subsystem is created, when the server is first booted, by the Session Manager (smss.exe). This instance handles the graphical display of the NT Server console desktop. Because Terminal Server must keep track of multiple desktops simultaneously, each session created on it must be assigned its own Win 32 subsystem.

As with the Object Manager, Terminal Server distinguishes the processes running in the different Win 32 subsystems using the Session ID. In this way, Terminal Server is able to keep all of the desktops running on it separate.

Real-World Tip: Gaining a Deeper Understanding with NT Utilities

Many of the concepts of Terminal Server architecture can be difficult to grasp and remember unless you can actually see them in action. Fortunately, there are several utilities, such as the query utility included with Terminal Server, that help you see what is actually going on inside. Not only are these invaluable learning tools, but they double as great troubleshooting tools. From time to time I will highlight where you can use a particular tool to gain a deeper understanding of the topic at hand.

Creating the Separate Win 32 Subsystems

Much like NT Server 4.0, when Terminal Server first boots, the Session Manager (smss.exe) starts a Win 32 subsystem for the console. Under Terminal Server, the console is always assigned Session ID 0. After the console processes are started, the Terminal Server service (termsrv.exe) instructs the Session Manager to start up two idle instances of the Win 32 subsystem to wait for client connections.

By going into the Task Manager on your Terminal Server (Ctrl+Alt+Del, Task Manager) and selecting the Processes tab, you can actually view the instances of the Win 32 subsystem that have been loaded (see Figure 3.1). The key user mode process in the Win32 subsystem is the Client Server Run-Time Subsystem process (csrss.exe). The CSRSS handles some of the non-graphical Win 32 API functions. Every instance of CSRSS also starts an instance of the WINLOGON process (winlogon.exe), which is responsible for the initial handling of the client logon. Note in Figure 3.1 that there are multiple instances of the CSRSS and WINLOGON processes and that each is assigned its own Session ID (ID column).

Differences in the Windows Manager and Graphics Device Interface

The Windows Manager and Graphics Device Interface (GDI) are the kernel mode portions of the Win 32 subsystem responsible for windows management and the handling of Win 32 API graphics calls. They both run as part of the win32k.sys system file. Because they are both part of the Win 32 subsystem, there is a separate instance of them running for every session.

The main difference between NT Server 4.0 and Terminal Server is with the GDI. Under NT Server 4.0, the GDI interacts directly with the video display driver for the server console. Suppose you are running Microsoft Paint at the server console. When you draw something in Paint, the Paint program makes a Win 32 API call to display what you are drawing onto the screen. This API call is eventually passed to the GDI. The GDI then instructs the video driver what to display by using standard video driver interface commands.

Figure 3.1: Processes in Task Manager.

Although this technique works fine for server console display on Terminal Server, it does not work for remote terminal sessions. On Terminal Server, the GDI display commands must be packaged and sent across the network for display on the remote terminals. Terminal Server and MetaFrame both handle this through virtual display drivers. Both the RDP and ICA protocols have their own virtual display driver. Each remote session on Terminal Server runs its own instance of one of these drivers. The driver captures the video driver interface commands from the GDI. These commands are packaged up by the protocol and sent across the wire for display on the remote client.

Differences in the Virtual Memory Manager

The final major difference between NT Server 4.0 and Terminal Server 4.0 is in the Virtual Memory Manager. The Virtual Memory Manager maps virtual addresses used by processes into actual physical locations in the computer's memory. Each process running on Terminal Server is given up to a 2GB virtual address space within which to work. Because each process's space is kept track of separately, this NT Server 4.0 architectural convention works well with Terminal Server.

The difference occurs within the 2GB virtual address space used by the operating system itself. Because all processes running on server need access to certain areas of this operating system memory, the processes would conflict in a multiuser environment. The main culprit is actually the kernel mode component (win32k.sys) of the Win 32 subsystem. NT Server 4.0 was designed to run only one instance of this subsystem, which it loaded into the operating system memory space so that processes running on the console could have access to it. Because the arrangement of much of the operating system memory space was fixed, Terminal Server had to use a special technique to run multiple instances of the Win 32 subsystem.

To solve this problem, Terminal Server assigns each session its own virtual Session Space. Any memory calls to the Win 32 subsystem memory range by a particular session are redirected to that session's Session Space by Terminal Server. This redirection keeps each session's Win 32 subsystem memory separate from that of the other sessions.

Note for WinFrame Administrators: User and Kernel Mode

For those familiar with the architecture of NT Server 3.51 and WinFrame 1.x, it may seem strange to talk about user and kernel mode components of the Win 32 subsystem. Under NT 3.51 and WinFrame the Win 32 subsystem ran entirely in user mode. One of the main architectural differences between NT 3.51 and NT 4.0, and thus between WinFrame 1.x and Terminal Server, is that significant portions of the Win 32 subsystem have been moved to kernel mode to improve efficiency.

Windows NT Design Goals

For those who want to know more about Terminal Server architecture, you will note that this section starts at the beginning, with the development of the operating system it is based on. The design goals of the NT operating system are a large part of the reason why NT was originally chosen by Citrix for its multiuser product WinFrame, and why Terminal Server, which evolved from WinFrame, is possible.

When the development team for Windows NT was first formed in 1989, its mission was to design an operating system to meet the following design goals:

• Extensibility For an operating system to be extensible, it must be modular with well-defined interfaces for applications to plug into. The extensible nature of NT is what makes Terminal Server possible.

• Robustness An operating system must protect itself and other running applications from applications that "misbehave." This is especially important in the multiuser environment of Terminal Server, in which several users can be running several applications at once on the same system.

• Scalability For an operating system to be used by major corporations, it must be scalable. You should be able scale from serving a handful of users to several hundred users on one server, by simply adding more hardware (processors and memory).

• Portability The operating system must work with multiple hardware architectures and be able to be easily ported to new ones.

• Compatibility NT must work with applications from several different operating systems, including OS/2, POSIX, DOS, and Windows 16-bit.

• Performance Although feature-laden, the operating system still must maintain a competitive level of performance.

These design goals were met by using a highly modular architecture. The next section shows how Terminal Server takes advantage of this modularity to work within a multiuser environment.

Components of the Terminal Server Architecture

The goal of this section is to provide a thorough understanding of the underlying structure of Terminal Server. You will find that a thorough understanding of the operating system's operation at this level will help you to better troubleshoot Terminal Server and optimize its performance.

This section starts with the Terminal Server architecture diagram shown in Figure 3.2, and as you proceed through this section, the function of each part of the diagram is explained. As each part is described, refer back to the architecture diagram to see how a specific part fits in with the whole architecture.

Figure 3.2: Terminal Server architecture.

Components of the Terminal Server operating system run in one of two modes: user or kernel:

• Kernel mode In kernel mode, an application has direct access to the hardware. Examples of kernel mode applications are the HAL, Microkernel, Virtual Memory Manager, and device drivers. Because the applications are running in kernel mode, the system is not protected from them, and as a result, they must be written and tested very carefully. One poorly written application can lock up or crash the entire system.

• User mode In user mode, an application can access hardware and operating system resources only through the Win 32 subsystem. This layer of isolation provides a great amount of protection and portability for applications. Examples of applications running in the user mode are DOS applications, Windows 3.x (16-bit), Windows 32, POSIX, and OS/2. If a user mode application crashes, the crash affects only the process the application is running in. By using Task Manager, you can simply delete the frozen process. All other applications continue to run without interruption.

The underlying difference between kernel and user mode has to do with the processor privilege level. Kernel mode is often referred to as privileged mode. On most modern processors, including Intel and Alpha, you can run an application at different privilege levels. On the Intel processors, there are four privilege levels or rings in which applications can run: 0–3. In reality, kernel mode refers to programs that run at privilege level 0. These programs have unrestricted access to all hardware and memory in the system. Programs running at privilege level 0 can set the privilege level for programs that they call. In contrast, user mode refers to applications and subsystems that are set by the kernel to run in privilege level 3. In this mode, applications are "boxed-in." The processor allows them to work only within their own memory areas. The processor also restricts them from directly accessing I/O, such as disk drives, communications ports, and video and network cards. To access these devices, applications must make a special gated call to a kernel mode program that handles the hardware.

Kernel Mode Components

A description of the components that make up Terminal Server must start at the heart of the operating system and work outward. The following sections first describe the Microkernel and HAL in detail and their relation to each other. These are the core components of the operating system. Next the Executive Services, which run in kernel mode, are covered.

Microkernel

Notice in Figure 3.2 that many of the modular components of the Terminal Server operating system are built around a Microkernel. The Microkernel is a small and very efficient program that handles the core functions of the operating system.

The Microkernel's primary job is managing the operating system's workload. As a manager, the Microkernel takes the tasks assigned to it by the applications and divides the work between the server's microprocessors. In a multiprocessor system, the efficiency of the Microkernel is critical. Without an efficient Microkernel, some processors become overburdened while others remain idle.

The Microkernel actually resides in either ntoskrnl.exe or ntkrnlmp.exe in the SYSTEM32 directory. The ntkrnlmp.exe file is the multiprocessing version of ntoskrnl.exe. It is specially written to handle multiprocessor synchronization.

Processes and Threads

Terminal Server applications and the operating system itself divide their work between processes and threads. An understanding of the basics of how applications, processes, and threads interact is key to understanding how the Microkernel works. This knowledge is also important when administering Terminal Server. You need to know what processes and threads are when you use tools such as Performance Monitor, Task Manager, and the Terminal Server Administrator.

• Processes A process is a program under control of the NT operating system that in essence is given its own room in memory and resources to work with by the operating system. When a process is started, an address space is set up for it. A process has its own variables and can request from the operating system its own access to the hardware below it. The operating system keeps track of what each process is doing by assigning it a unique process ID. Furthermore, Terminal Server keeps track of the processes that each session is running by assigning them Session IDs.

  When an application is run, it can request that the operating system start up as many processes as it needs to do its tasks. Most applications run with one or two processes.

• Threads For processes to get any work done, they divide their work into threads and have the operating system execute them. A thread is a piece of executable code that can be run on a single processor. The Microkernel works by dispatching these threads to the processors based on their priorities.

HAL

The Hardware Abstraction Layer (HAL) is what the Microkernel communicates through when it needs to send threads to the processors or I/O devices. The HAL shields the Microkernel from the differences in the hardware below it. Suppose you are using a Micro Channel Bus instead of a standard PC bus, or various types of multiprocessor arrangements. For each of these machine specific setups, a HAL is written, normally by the manufacturer. The HAL translates the standard HAL requests that the Microkernel makes into code that the processors and I/O devices can understand. In this way, the HAL provides a uniform interface for the Microkernel to use the capabilities of different hardware platforms.

The HAL is also used by many device drivers to access the hardware. The HAL shields these drivers from the differences in the structure of the hardware below them by providing a uniform interface.

Real-World Tip: Processes in Action

One of the many ways to see processes in action is to use the query process utility:

1. Log on as administrator to Terminal Server.

2. Go to the command line and run query process *.

You will see a list of all processes running on the system, to whom they belong, and what their process IDs and session IDs are.

Run your favorite program and look at the processes again using the query process command. Notice the new processes that are created when your program opens.

You can also see processes in action by using the Terminal Server Administrator tool (described in Chapter 12, "Administering the Desktop and Server") and Task Manager (as shown in the earlier "Differences in the Win 32 Subsystem" section). You can also measure many performance parameters of the operating system by process by using Performance Monitor (described in Chapter 13, "Measuring Performance").

Real-World Tip: Viewing Available HALs with UPTOMP

The HAL is implemented in the hal.dll. Notice on the Terminal Server CD under the I386 directory that several files start with HAL (HAL*.*). When you first install Terminal Server, you have the option of picking your processor. At this point, the appropriate HAL is expanded, renamed hal.dll, and put in your SYSTEM32 directory.

If you have the NT Server 4.0 Resource Kit, available from Microsoft, run the Uni to Multiprocessor utility (uptomp.exe) from the Start menu, by selecting Resource Kit 4.0, Configuration. By using this utility, you can view a description of the various HALs on your install CD.

Executive Services

There are seven primary Executive Services. These are the basic kernel mode components that the applications running in user mode use through the Win 32 API:

• Object Manager

• Security Reference Monitor

• Process Manager

• Virtual Memory Manager

• Local Procedure Call Facility

• I/O Manager

• Windows Manager and Graphical Device Interface

Refer to Figure 3.2 for a general idea of how these components relate. The Executive Services are all kernel mode components that provide the operating system services that are used by the applications running on Terminal Server. The following sections describe each of the kernel mode components in detail.

Object Manager

One of the most important components in the Executive Services suite is the Object Manager. Because Windows NT is an object-oriented operating system, most of its resources are treated as objects. The Object Manager is in charge of creating, tracking, protecting, and deleting system objects. The Object Manager is responsible for objects used in both kernel mode and user mode. As described in the section "Differences in Object Manager," the Object Manager keeps track of both global objects that are used by all sessions and session-specific objects that applications running in a particular session create.

To truly appreciate the importance of the Object Manager, you must understand what objects are. Nearly every time an application accesses a file, displays something on the screen, communicates with a device, or accesses most operating system resources, it does so through an object. Objects have three main components: properties, methods, and handles.

• Properties Used to provide information to applications and users about the object.

• Methods Used for controlling objects.

• Handles Used by the operating system to identify which object an application is referring to.

The following are examples of some of the objects under Windows NT:

• Port objects

• Memory objects

• Process objects

• Thread objects

• File and directory objects

Suppose an application needs to access a file on the hard drive. The application would access the file through a file object, as shown in Figure 3.3, which has properties such as file name, file size, date of creation, current status, and attributes. These properties allow the application to gather information about the object. To do something with the object, the application must use a method. Examples of file methods are create file, delete file, open file, read file, and close file. To keep the file object unique, the operating system assigns it a handle. The handle is used by any applications that reference the file object.

Security Reference Monitor

For an operating system to be secure, not every application or user can have access to all resources on the system. This is especially important with Terminal Server, in which several users can access the same resources remotely. For example, if the operating system is not protected, a single Terminal Server user could accidentally delete a critical system file that everyone needs. The Security Reference Monitor provides both authentication and auditing services to protect your server from instances like this.

NT security works through access control lists (ACLs) and security IDs (SIDs).

• Every user and group in the security database has a unique identifier called a SID. An example of a typical SID is S-1-15-50-101. This unique number is associated with the user or group until it is deleted. Even if another user or group is created with the same name the newly created user or group is assigned a different SID.

• Every Windows NT object has an access control list (ACL). An ACL is made up of access control entries (ACEs). The ACE contains the SID of a user or group, along with their security rights to this object.

When a user logs on to Terminal Server, an access token object is created for him that lists his SID, the SIDs of all the groups that he belongs to, and special privileges such as the ability to set system time.

In Figure 3.4, you see the access token object for the fictitious user John.Smith. Note that the object contains all of the SIDs for all of the groups that John.Smith belongs to. This object acts like a set of keys to unlock the system resources. When John.Smith tries to access the Office 97 directory, the Security Reference Monitor retrieves the ACL for this directory, compares it to the SIDs in John.Smith's access token object, and grants him Read and Execute rights to that directory.

Figure 3.3: Accessing a file through the file object.

Figure 3.4: Access tokens and ACLs.

Another example is an accounting database file with an ACL that allows the Accounting group full access, but restricts the Management group to read access. When someone in the Management group logs on, she receives an access token object that includes the SID for the Management group that they are in. When she tries to access the accounting database file, the Security Reference Monitor checks the ACL for the file and finds that the Management group has only read access to the database. The user is then allowed to open the database with read-only access. If the user tries to write to or delete the database, the Security Reference Monitor prevents this action.

Another important function of the Security Reference Monitor is auditing. Suppose the accounting database in the preceding example is set up for strict auditing. When someone tries either successfully or unsuccessfully to access the file, such as an attempt to delete it, the Security Reference Monitor records the attempt.

Process Manager

In the earlier discussion about the Microkernel, processes are described as being part of applications and having threads. The Process Manager keeps track of all processes running on the system and their associated threads. The Process Manager also handles the opening and closing of processes and threads.

Every process is assigned a security access token when it first starts. The Process Manager works closely with the Security Reference Monitor to ensure that the process goes through security checks before accessing protected objects.

Virtual Memory Manager

The applications that run on your Terminal Server need memory to hold their data and code. The Virtual Memory Manager is responsible for keeping track of this memory and assigning it to your programs.

In older operating systems such as MS-DOS, there was a set amount of memory available and only one program was loaded into it at a time. Under Terminal Server there can be several users simultaneously running multiple applications at the same time on the same server. For these applications to work together properly, they are each given their own block of virtual memory. Applications are allowed to access only their own memory and are blocked from accessing others' memory. In this way, each application runs in its own protected space in the Terminal Server's memory.

Each process running on your Terminal Server is allocated 4GB of virtual memory. The first 2GB block is for user programs and the second 2GB is reserved for operating system storage. This is a lot of memory. Few machines will have even close to this amount available. The magic of the Virtual Memory Manager is that although you may not actually have this amount of memory, to your applications it appears as if this amount is available. If you have a program that runs out of room, the Virtual Memory Manager swaps other portions of memory to the hard disk to make room for the running application. To your application, the memory still appears as one contiguous space.

Although the memory assigned to your program appears contiguous, the actual physical locations in memory where the program is stored does not have to be. The Virtual Memory Manager divides the memory and hard drive space available into 4KB pages It handles assigning these 4KB pages to your programs to actual physical memory locations, as shown in Figure 3.5. Because programs are starting and stopping all the time on your server, without the Virtual Memory Manager there would be gaps of available memory left unused after a program releases it. The Virtual Memory Manager fills in these gaps when programs make new requests for more memory.

The Virtual Memory Manager also provides very important performance information to your system. On Terminal Server, having the right amount of memory to handle all users and applications is critical. If there is not enough memory, the response time slows down tremendously for all users because the Virtual Memory Manager must swap out memory to disk to make room. In Chapter 13, you learn how to use Performance Monitor to effectively monitor how much memory you are using, and how much you need.

Figure 3.5: The Virtual Memory Manager.

Local Procedure Call Facility

The Local Procedure Call Facility (LPC) handles the client/server communication between applications and subsystems and between processes. It handles only those calls that occur locally. The actual request is sent to the Win 32 subsystem, which in turn sends the request to the appropriate Executive subsystem for display. This level of complexity is hidden from the application, which must only call the procedure and receive a response.

Terminal Server makes extensive use of LPCs. The Terminal Server service (termsrv.exe), which handles most of the background administration necessary on Terminal Server, uses LPCs to communicate with other processes. For example, when new connections need to be made, the Terminal Server service calls the Session Manager (SMSS) to create idle connections that wait for new users who need to log on.

I/O Manager

The I/O Manager handles all input and output to your system's devices, and as such it is probably one of the busiest subsystems. I/O Manager handles data input and output from all of the following and more:

• Hard drives using NTFS or FAT

• CD-ROMs

• Floppy drives

• SCSI devices such as scanners, or removable storage such as a JAZ drive

• Serial and parallel ports

• Tape drives

• Mouse and keyboard

• Network cards

The I/O Manager includes a cache manager that handles caching all disk and network input/output. Caching can improve performance greatly during heavy disk access by caching or copying data that it reads from the disk drive into memory. The next time this data is accessed, it is taken from memory instead of the disk, which results in much quicker access. Caching is also beneficial during writes. A process can write to the cache by using the lazy write service. Rather than the process having to wait for the disk to finish processing before sending it more data to the disk, the process simply writes additional data to the cache. The next time the processors are not busy, the cache is written to disk; meanwhile, the process can carry on uninterrupted.

Whether you are connecting your clients to the Terminal Server via the network, serial ports, or modems, the I/O Manager is the main Terminal Server subsystem that they will interact through. Because of this, it is important that you keep up with new releases of I/O drivers so that you always have the most up-to-date and efficient versions.

Windows Manager and Graphical Device Interface

The Windows Manager and Graphical Device Interface (GDI) are responsible for handling all Win 32 API video requests by applications. They are the kernel mode components of the Win 32 subsystem. These components are covered in detail in earlier section "Differences in the Win 32 Subsystem."

How the Windows Manager and GDI relate to the Win 32 subsystem is diagrammed in Figure 3.2. Note that there is one instance of the Windows Manager and GDI (win32k.sys) for every session running on Terminal Server.

User Mode Components

So far, the discussion has focused on kernel mode components. The applications the users are running are in user mode. For Terminal Server to support as many types of applications as it does, it has subsystems that emulate the native environments that these applications would run in. There are environment subsystems for DOS, Windows 16-bit, POSIX, and text-based OS/2 applications. All of these subsystems are designed to basically convert the foreign application's calls into calls that Terminal Server's native environmental subsystem, the Win 32 API, can understand.

Win 32 Subsystem

The Win 32 subsystem handles most Win 32 API calls. All user mode applications communicate with the Terminal Server operating system through this API. Because Terminal Server is a strictly controlled operating system, all interaction between applications and hardware must occur through the Win 32 API. Applications that try to improperly bypass the operating system and access hardware directly are shut down or stopped by Terminal Server. This level of application security brings a great amount of stability to the operating system. Even poorly written applications do not have the ability to lock up the entire operating system with an improper direct hardware call, such as a direct disk write. This is very important for Terminal Server because it typically is running several applications at once for several users.

The Win 32 API, supported by the Win 32 subsystem, is an object-oriented set of functions and procedures that allows the application to control all aspects of the operating system. Because the Win 32 API for NT is very similar to the one for 95, in general, Win 32 applications can run on either API without modification. One of the main advantages of an API is the layer of isolation it provides to the operating system. As long as the Win 32 API stays the same, the entire kernel can be rewritten, and Win 32 applications would still run.

The Win 32 subsystem can be divided into two subsystems: the Executive and the Console. The Executive subsystem resides in the kernel mode; it is made up of the Windows Manager and GDI. The Executive handles the majority of the graphics related Win 32 API calls. The Console runs in the user mode and provides text window support, hard-error handling, and shutdown. The system file that makes up the Console is Client Server Runtime Subsystem executable (csrss.exe).

DOS and Windows 16-bit Applications

To run DOS applications, you need a converter to take the application's device calls and convert them to Win 32 API calls that Terminal Server can understand. The module that does this is the NTVDM or NT Virtual DOS Machine. The NTVDM simulates a DOS environment for DOS applications. It provides simulation for the following:

• Standard DOS 21 Interrupt services

• ROM BIOS calls

• Device calls, such as to the keyboard or video

When a DOS application runs on Terminal Server, it is assigned three threads. The first thread is the one in which the application runs. The second thread provides a heartbeat to simulate timer interrupts for the MS-DOS applications. Many DOS applications rely on the timer interrupt to time various procedures and to control the execution of programs. The third thread is for console I/O.

Although you can run DOS applications on terminals attached to Terminal Server, there are disadvantages:

• You can expect a 10–25% decrease in performance of a typical DOS application due to the Win 32 translation. This extra processing time for translation reduces the amount of processing time available for other users of the Terminal Server. You cannot run as many users concurrently if all users are running DOS applications.

• Users cannot run DOS applications full screen unless they are using the DOS-based client. Because Terminal Server comes with only Windows-based clients, you cannot run DOS applications full screen unless you purchase the MetaFrame add-on and use the DOS-based client.

• 16-bit Windows was originally designed to be basically a graphical operating system that runs on top of DOS. Because it was designed to run on top of DOS, many Windows 16-bit applications rely on DOS system calls, such as interrupt 21. For 16-bit Windows applications to run under Terminal Server, Terminal Server runs them on top of the NTVDM. This provides the DOS environment that they need. Consequently, you face the same decrease in performance with Win 16 applications as you do with DOS.

• Windows 16-bit applications must also make Windows API calls, such as to manipulate graphic objects on the screen. To do this, Win 16 applications must use a converter to convert Win 16 API calls to Win 32 API. That conversion is performed by the Win 16 on Win 32 or WOW exec. Like the NTVDM, the WOW takes its effect on system performance. You still must have more memory and processing speed to run 16-bit Windows applications than for a similar Win 32 applications. Because of the significant performance hits, it is not recommended to run DOS or Win 16 applications with Terminal Server, if you have the choice.

About The Author

Ted Harwood is a senior network engineer for Davocom One in Miami, Florida. He specializes in the design and implementation of LAN, WAN, and thin-client solutions. Harwood is a Microsoft Certified Systems Engineer (MCSE), Novell Master Certidfied NetWare Engineer (MCNE), and a Certified Citrix Administrator.

Copyright © 1999 by New Riders Publishing, Pearson PTR

We at Microsoft Corporation hope that the information in this work is valuable to you. Your use of the information contained in this work, however, is at your sole risk. All information in this work is provided "as -is", without any warranty, whether express or implied, of its accuracy, completeness, fitness for a particular purpose, title or non-infringement, and none of the third-party products or information mentioned in the work are authored, recommended, supported or guaranteed by Microsoft Corporation. Microsoft Corporation shall not be liable for any damages you may sustain by using this information, whether direct, indirect, special, incidental or consequential, even if it has been advised of the possibility of such damages. All prices for products mentioned in this document are subject to change without notice.

International rights = English only.

Click to order