Partager via


Legacy Applications in a Terminal Services Environment

The Windows 2000 Server operating environment has specific requirements for hosting Microsoft® MS-DOS®-based and 16-bit Windows-based applications. These requirements also apply to a Terminal Services environment. Any MS-DOS-based or 16-bit Windows-based application that does not run under Windows 2000 Server will not run under Terminal Services either. Terminal Services is, however, more sensitive to ill-behaved legacy applications than the traditional Windows 2000 Server because a single ill-behaved application can affect all of the users on the Terminal Services system.

Predicting which legacy applications will work well in a Terminal Services 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 a Terminal Services environment. However, there are some application behaviors and origins that typically create problems in a Terminal Services environment.

Application Issues
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 a Terminal Services environment.
Microsoft FoxPro®for MS-DOS-based applications These applications often do not run well in a Terminal Services 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 a Terminal Services 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 Services. 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 Services handles the standard functions properly for a multi-user environment.

Send comments about this topic to Microsoft

Build date: 2/21/2008