Legacy Applications in a Terminal Server Environment
[This is preliminary documentation and subject to change.]
The Windows NT Server operating environment has specific requirements for hosting MS-DOS®-based and 16-bit Windows-based applications. These requirements also apply to the Windows® -based Terminal Server environment. Any MS-DOS-based or 16-bit Windows-based application that does not run under Windows NT Server will not run under Terminal Server either. Terminal Server is, however, more sensitive to ill-behaved legacy applications than the traditional Windows NT Server because a single ill-behaved application can affect all of the users on the Terminal Server system.
Predicting which legacy applications will work well in the Terminal Server environment and which will not is difficult. In most cases, the only real way to determine a specific application's feasibility is to test the application in the Terminal Server environment. However, there are some application behaviors and origins that typically create problems in a Terminal Server environment:
-
MS-DOS-based applications that cycle on device input. MS-DOS-based applications that tightly loop for keyboard input, mouse activity, or other device input operations are often too CPU-bound to run effectively in the Terminal Server environment.
-
FoxPro® for MS-DOS-based applications. These applications often do not run well in the Terminal Server environment because they tend to be CPU interrupt-intensive and drain processor resources away from other user sessions.
-
MS-DOS-based print applications. Many MS-DOS-based applications use print techniques that are not compatible with the Terminal Server environment. However, 16-bit Windows-based applications that use the standard Windows printing functions work correctly.
-
MS-DOS and 16-bit Windows-based applications that internally mount NetWare drives. Programmatic NetWare drive mapping operations do not work under Terminal Server. In contrast, drive mapping using UNC names works correctly.
-
16-bit Windows applications that directly access .ini files. Older Windows applications that directly access .ini files instead of using the standard functions might not work if multiple users simultaneously access an .ini file. Terminal Server handles the standard functions properly for a multi-user environment.