Interix in a Multi-User Windows TSE Environment

Operating System
Interix Technical Note


This paper is for customers who wish to use INTERIX subsystem technology in conjunction with Windows NT® Server, Terminal Server Edition (TSE) or Windows® 2000 Terminal Services. Earlier releases of the INTERIX subsystem technology product do not run on systems with Terminal Services. The incompatibility is due to the multi-user model used by TSE, which is different from the multi-user model used by INTERIX and UNIX systems. However, changes in services for Unix 3.0/Interix and Windows 2000 now allow for running on Windows 2000 Terminal Services.

TSE creates a whole new virtual execution space for every new user that logs into the server. While the Win32®-based subsystem has been enhanced to accommodate running multiple iterations of itself on a single server, the INTERIX subsystem is still unable to replicate itself multiple times over a single executing kernel.

On This Page

Multi-user Models Multi-user Models
Integrating the Models Integrating the Models
For More Information For More Information

Multi-user Models

The multi-user models used by Windows NT® Server 4.0, Terminal Server Edition and INTERIX make use of system resources in very different ways.

Multi-User Windows

The Windows® operating system has traditionally been a single-user operating system. It hosts a complete execution environment for a single user, but hasn't traditionally provided for alternative environments. Each system can only be used by one person for running interactive Windows applications on the system's desktop. Even Windows NT, although it is a multi-user system, has not provided for multiple Windows sessions simultaneously.

Windows NT Terminal Server Edition (and other multi-users Windows systems from companies such as Citrix) allow a single server to host multiple login sessions from other personal computers, Windows terminals or even non-Windows environments. By keeping the execution of applications and the Windows session itself on a single powerful server, customers can implement easy-to-administer "thin client" strategies for their client systems.

The multi-user Windows systems provide a separate Windows session for each login. Conceptually, this is similar to a traditional multi-user UNIX system hosting multiple X Window terminal sessions. However, the underlying technology is very different from the model used by UNIX.

On TSE and multi-user Windows systems from Citrix and others, the Windows NT kernel is substantially modified to allow each session to create a complete virtual machine execution space for each new session. This means the entire Win32®-based subsystem gets "cloned" for each new session and a dedicated section of memory and other resources are reserved for each new session. Each user runs their session in a protected virtual machine on the server and has access to their own virtual memory and devices.

While the virtual machine concept is technically viable, there are issues with resource consumption. Since each user needs their own virtual memory space, typically a minimum of 20-40 megabytes of RAM is required for each session that is hosted on the server. If the user is running large memory intensive applications, even more can be required.

The result is that most large installations of TSE run with what has come to be known as "server farms." Companies install multiple systems with TSE and load-balance users across the multiple networked servers. As more users join the network, additional servers can be added to take up the load.

The obvious disadvantage is the tremendous cost in system resources.

Multi-User UNIX

Since the multi-user model on UNIX systems evolved before the days of cheap computers, it's not quite so resource-intensive. UNIX systems have three main methods for providing multi-user access to a single server.

  • For character-based applications, the user can connect through serial terminals to a serial port or a network terminal server and log into a UNIX server that hosts the session.

  • Users can also log into the system over the network using telnet or rlogin and have a character-based session on the UNIX server.

  • For graphical UNIX applications, users can connect to the UNIX server over the network using X terminals or other systems that have X display software. Users can remotely use a single application or have a complete remote session with multiple applications.

Since UNIX was developed from the beginning as a multi-user system, it has been optimized to run multiple sessions on a single server. On UNIX, each new user session requires minimal overhead and the only additional load on the system is the load from each application that is run. With techniques such as shared library support, application resource consumption is reduced even more, since each user can share application memory for "public" parts of the application.

The INTERIX system uses the UNIX multi-user model for hosting multiple users on a Windows NT server. As a result, Windows NT can host a similar number of users running UNIX applications to what would be expected on a similar system running stand-alone UNIX.

The Conflict

The INTERIX subsystem is not yet capable of replicating itself multiple times over a single running kernel. (Even the Windows subsystem required significant changes before it was possible.) Attempting to invoke multiple versions of INTERIX on a particular Windows NT4.0 TSE server will not work. While Interix from Services for Unix 3.0 is able to run on Windows 2000 TSE and Windows Server .NET, this document presents a methodology for using Interix 3.0 in a Windows NT 4.0 environment.

Integrating the Models

The solution for running INTERIX in a multi-user Windows NT environment is to extend the concept of the "server farm" to also include dedicated INTERIX servers for running UNIX system applications on Windows NT. An example of this configuration is shown in the graphic below. In this model, one of the servers in the "farm" is an INTERIX server, just as the other servers are Win32-based servers.


An architecture for running multi-user UNIX and Windows applications in a Windows NT environment

With this methodology, administrators install a dedicated Windows NT server with INTERIX subsystem technology and use that machine for running all multi-user UNIX applications. This server and its data and resources can be accessed from any other machine in the network, including servers running TSE.

In order to run an X Window application, a user needs to run a Win32-based X Server (e.g. the Hummingbird Exceed X Server that comes bundled with INTERIX subsystem technology) on one of the TSE machines to display a graphical UNIX application that executes on the INTERIX server. If the X Server is running on the thin client machine, the X applications can use the IP address of the thin client machine.

If the user needs to run a character-based application or needs a shell session, then they can telnet from a TSE session to the INTERIX server and run the application in a telnet session.

Both of these methods can be easily scripted for the end user in such a way that the user does not need to know that their UNIX applications are running on a different machine from their Windows applications.

The INTERIX subsystem can also be used to host UNIX applications for connected character terminals, X terminals and other telnet or X based systems.

X Windows Applications

Handling X Windows applications will depend upon whether the thin client machine is a PC or just a terminal.

If the client machine is a PC, then it can run the X Server software itself. X applications can use the IP address of the thin client machine. (This is available using the Win32 IPCONFIG.EXE program.) This is certainly the preferred way to configure the system.

If the thin client cannot run the X Server itself, the problem is different, and we are continuing to test different configurations. The integration of the Win32 X Server software with TSE is the key; our last information is that all Win32 sessions on a single TSE server share the same IP address; in order for the X Server to handle display information correctly, it must be TSE-aware. We will update this document as we learn more.

It may also be possible to run the X Server on the TSE server and let it handle the redirection of the display to the client machine. However, we suspect performance will be poor. Again, the X Server may need to be TSE-aware.

Character-Based Applications

To run a character-based application, the user of the TSE client machine can telnet into the INTERIX server.

The only issue with this is the quality of the telnet implementation. Win32-based telnet clients often have problems with dropped characters. (The INTERIX telnet client doesn't have this problem because it's built from the UNIX system source.) Certainly we have seen this problem in the telnet client distributed with Windows NT.

A client machine that is a PC can install INTERIX Workstation Lite and have a reliable telnet client. The user can telnet into the INTERIX server and run the application, whether it's a shell script or a binary.

If the client machine is a Windows PC, we find the telnet client called WinQVT to be better than the default one shipped with Windows NT. Information on it is available at


Setting up the multi-user application environment in this way has a number of advantages:

  1. Only one machine needs a copy of INTERIX subsystem technology. This saves on the cost and administration of the software.

  2. Only one machine needs to be configured with the required UNIX applications.

  3. Applications are available to any user on the network – both local and remote.

  4. Using the same domain user and security system for both Windows and UNIX applications simplifies user accounts and administration.

  5. Segregation of multi-user Windows and UNIX applications allows for better tuning of system resources and potentially better performance.

  6. Data files and printers can still be shared across any of the Windows NT Server systems.

Variations of the above scenario are possible.

For More Information

For more information about Interix subsystem technology, see the Interix Web site at: