Appendix B - Other Application Environments

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.

In addition to 32-bit applications designed for Windows NT, Windows NT supports applications designed for the following environments: Windows 3.x, MS-DOS, 16-bit OS/2, and POSIX.

This chapter provides information on these environments, including the following topics:

• How Windows NT runs applications

• The Windows 3.x environment

• The MS-DOS environment

• The OS/2 environment

• Setting up and starting applications

How Windows NT Runs Applications

Windows NT is a modular operating system that uses operating subsystems to run applications. Each subsystem provides a different operating environment for applications. Windows NT runs Windows 3.x, MS-DOS, 16-bit OS/2, and POSIX based applications in addition to 32-bit applications designed for Windows NT and most 32-bit applications developed for Windows 95.

The following table shows the Windows NT subsystems and the applications each subsystem supports.

Subsystem	Supports
Windows (16-bit)	MS-DOS, and Windows 3.x based applications
OS/2	16-bit character-based OS/2 applications (on x86-based computers only)
POSIX	POSIX applications compliant with IEEE Std 1003.1 and compiled using Windows NT

The Windows NT Executive is the portion of the operating system at the center of Windows NT that manages processes and memory. You can think of a process as a discrete set of computing tasks. When you run Windows 3.x-based applications, applications run by default as tasks within a single process.

Each process is protected. That is, the Executive makes sure that each process runs in its own area of the computer's memory so that processes cannot interfere with one another. If an application fails, that failure will not affect the rest of the system.

You can start any application from the Start menu, Windows NT Explorer, or from the command prompt without concern for the operating environment the application requires. This functionality enables full interaction among applications.

Supported Applications

Windows NT can run most Windows 95, Windows 3.x, MS-DOS, and 16-bit character-based OS/2 applications. Applications not designed for Windows NT or Windows 95 sometimes use device drivers that attempt to communicate with computer hardware directly. To protect the integrity of the operating environment, such drivers are prevented from being installed with the application. A device driver designed to run with Windows NT is required.

If you have an application that requires but does not supply a Windows NT-compatible device driver, contact the application's manufacturer for the availability of a Windows NT-compatible driver. In some cases, the manufacturer may have developed a version of the application that is fully compatible with Windows NT.

The following types of existing applications require either Windows NT-compatible device drivers or an application upgrade:

• Applications that directly communicate with hardware; for example, FAX cards, scanner cards, or terminal emulation cards

• Applications that rely on their own disk device drivers; for example, applications that increase hard disk capacity

• Applications that communicate directly with disk drives; for example, disk maintenance applications

• Applications that rely on their own graphics device drivers to communicate with the hardware; for example, applications that use private printer drivers

Windows 3.x Environment

Windows NT provides a complete operating environment for Windows 3.x-based applications. The environment is comparable to the enhanced mode environment in Windows 3.x.

On RISC-based computers, Windows NT provides a 486 emulator that runs applications designed for 286, 386, or higher processors.

Configuring the Windows 3.x Environment

When you install Windows NT, the Setup program checks to see whether a previous version of Windows NT or Windows 3.x is installed on the computer. If it is, you should install Windows NT in the same directory as Windows 3.x. Windows NT then configures its environment based on the existing environment, enabling Windows NT to support all the features of currently installed Windows 3.x-based applications.

Windows 3.x stores configuration information in the Win.ini and System.ini files. Windows NT stores configuration information in the registry. However, the Win.ini and System.ini files are retained in Windows NT for use by Windows 3.x-based applications. For more information about how Windows NT uses configuration files, see Appendix A, "Windows NT Registry."

If you installed Windows NT in the same directory as Windows 3.x, the first time you log on to Windows NT, Windows NT migrates any program groups that are not predefined for Windows NT and the settings that configure your desktop. The Windows 3.x program groups appear as folders on the Start menu.

If you later install a new application while running Windows 3.x, Windows NT does not automatically gather file association and object linking and embedding (OLE) information for the new application when you start Windows NT.

Running a Windows 3.x-Based Application in Separate Memory

When you start a Windows 3.x-based application, by default it runs in the same memory space as the first Windows 3.x-based application you started. If several Windows 3.x-based applications are running in the same memory space when one of the applications crash, all the applications become unavailable. You can, however, run each application in its own memory space.

Running a Windows 3*.x*-based application in a separate memory space prevents the application from affecting other Windows 3.x-based applications if the application crashes or hangs. However, the performance of Windows NT could be slower if several Windows 3.x-based applications are each run in their own memory spaces. Running Windows 3.x-based applications in separate memory spaces uses more memory.

Running a Windows 3.x-based application in a separate memory space also prevents the application from sharing memory with other Windows 3.x-based applications. Some applications rely on the shared memory space to work with other applications. However, cross-application communication using OLE or dynamic data exchange (DDE) still works if you run one application in a separate memory space.

For information about how to run a Windows 3.x-based application in its own memory space, or create a shortcut for a Windows 3.x-based application to run in its own memory space, see "Running a Windows 3.1 application under Windows NT in Help.

MS-DOS Environment

Windows NT provides a complete operating environment for MS-DOS applications.

• Expanded memory is emulated for applications that require it.

• On x86-based computers, character-based applications run either in a window or the full-screen mode. Applications that use graphics run in the full-screen mode.

• On RISC-based computers, character-based and graphics-based applications run in a window only. You can change the size of the window using the Properties command on the Control menu. Click the Layout tab.

Configuring the MS-DOS Environment

During system startup, Windows NT adds Path, Prompt, and Set commands from the C:\Autoexec.bat file to the Windows NT environment variables and then ignores the remainder of C:\Autoexec.bat and C:\Config.sys. (If these files are not present when you install Windows NT, the Setup program creates them.)

For a RISC-based computer, default Autoexec.nt and Config.nt files are created.

File	Use in Windows NT
C:\Autoexec.bat	Path and environment variables are added to the Windows NT environment at system startup.
C:\Config.sys	Not used by Windows NT.
Autoexec.nt and Config.nt in %SystemRoot%\system32	Used every time an MS-DOS- based application is run with the _Default.pif. (Custom *.nt files can be created and used when starting an application from another PIF.)

When you log on to Windows NT, the path and environment variables stored in the Autoexec.bat file are appended to the Windows NT path and environment settings. Because this portion of the operating environment is established when you log onto Windows NT, the values set for the path and environment variables are available to each application you use. If you change values in Autoexec.bat, Autoexec.nt, or Config.nt, you must log off and log on to Windows NT again so that the changes take effect.

Environment variables can also be changed using the System option in Control Panel. Click the Environment tab. For more information about environment variables, see "Using Environment Variables to Manage Workstations" in Chapter 3, "Managing User Work Environments."

When you start an application in a new command window, Windows NT reads the Config.nt and Autoexec.nt files to configure the environment for the application. If, for example, you change an application's driver in the Config.nt file, restarting the application puts the change into effect. You can edit the Config.nt and Autoexec.nt files just as you would CONFIG.SYS and Autoexec.bat. Config.nt and Autoexec.nt are located in the %SystemRoot%\system32 directory.

As with Windows 3.x, Windows NT enables you to customize the environment for each MS-DOS-based application with program information files (PIFs). However in Windows NT version 4.0, PIFs are only created when you create a shortcut for the application. For information about how to create PIFs, see "New PIF handling in Windows NT" in Help.

Commands Available in Config.nt

Windows NT supports the configuration commands shown in the following table. If you include commands in your Config.nt file that are not supported, Windows NT ignores them. For more information about Windows NT commands, see the online Command Reference.

Command	Function
country	Sets the language conventions for a specific country.
device	Loads an installable device driver. If necessary, you can load drivers that control memory, such as Himem.sys, or that control character-based display, such as Ansi.sys.
dos	Specifies how the upper memory area will be used.
dosonly	Prevents starting applications other than MS-DOS – based applications from the Command.com prompt.
echoconfig	Switches on the display of Config.nt and Autoexec.nt messages when you start an application.
fcbs	Sets the number of file control blocks (FCBs) that can be opened concurrently.
files	Sets the number of files that can be open at one time.
install	Loads a memory-resident program into memory.
loadhigh	Loads device drivers into the upper memory area.
ntcmdprompt	Runs the Windows NT command interpreter, Cmd.exe, rather than Command.com after running a terminate-and-stay-resident (TSR) application or after starting the command prompt from within an MS-DOS – based application.
rem	Marks lines in the Config.nt file as comments (remarks).
shell	Specifies the command interpreter. Only the Windows NT command interpreter is supported.
stacks	Sets the amount of RAM reserved for processing hardware interrupts.

Commands Available in Autoexec.nt

Windows NT supports a similar range of commands as MS-DOS for use in the Autoexec.nt file. For more information about Windows NT commands, see the Command Reference in Help.

Using Program Information Files

A program information file (PIF) provides information to Windows NT about how best to run MS-DOS applications. Windows 3.x, OS/2, and POSIX based applications do not use or require PIFs. When you start an MS-DOS application, Windows NT looks for a PIF to use with the application. If you have been using a PIF to run an application in Windows 3.x, you can continue to use it with Windows NT. For information about how to use PIFs, see "New PIF Handling in Windows NT" in Help.

To create, modify, and save PIFs, right-click the application file name in Windows NT Explorer. If you click OK after changing any of the settings in the Properties dialog box, you create a PIF (a shortcut) for the application. Typically, a PIF has the same file name as the associated application's main program file, except that a PIF has the .pif extension. You can change the PIF file name, but do not change the extension.

Some software manufacturers provide a PIF for an application. To determine whether a PIF has been supplied, contact the software manufacturer or search the disks for a file that has a .pif extension. For information about how to implement a manufacturer-supplied PIF file, see "Using a manufacturer-supplied PIF file" in Help.

Windows NT includes a PIF named _Default.pif, located in the %SystemRoot%* *folder. The _Default.pif file contains settings that work with most MS-DOS – based applications. Windows NT uses this PIF when it is the only one available for MS-DOS – based applications. You should not change the settings in the _Default.pif file because Windows NT uses this file for every MS-DOS – based application.

For information about how to create or edit a PIF and other PIF options, see "New PIF handling in Windows NT" in Help.

Using Multiple PIFs for an Application

You can create more than one PIF for an application. You can create several PIFs if you run an application differently under different circumstances.

For example, you can specify in a PIF how much EMS (expanded) memory an application has access to. By using two PIFs, you can give an application access to a large amount of EMS memory when you're using large data files but limit its use of memory when you are working with smaller files.

For information about how to set up two PIFs for an application, see "Creating two PIFs for an application" in Help.

Custom Startup Files

Windows NT enables you to create custom startup files that you can specify in an application's PIF. When you start the application, Windows NT reads the custom files you specify rather than the Config.nt and Autoexec.nt files. Specifying custom startup files enables you to create a custom MS-DOS environment for each application you use. For example, if one of your applications requires a memory-resident program when it runs, you can include the name of that program in a custom startup file. When you start the application using its PIF, Windows NT automatically starts the memory-resident program.

When you create startup files, base them on the Autoexec.nt and Config.nt files. That way, the basic information needed to configure the MS-DOS environment will already be included in your files. In configuration files, Windows NT uses the variable %SystemRoot% to represent the Windows NT directory. When processing the files, Windows NT automatically expands this variable.

For information about how to create custom startup files, see "Creating custom startup files for an MS-DOS program" in Help.

Running Memory-Resident Programs

Windows NT supports MS-DOS memory-resident programs, also called pop-up and terminate-and-stay-resident (TSR) programs. Like any MS-DOS – based application you run in Windows NT, memory-resident programs run in the window in which they are started and can be used only within that window. MS-DOS–based TSR programs can function reliably only when running alone or with other MS-DOS–based applications.

In general, you should not start memory-resident programs from your Autoexec.nt or Config.nt files. If you do, each time you start an application that reads the Autoexec.nt or Config.nt files, you will also start another copy of the memory-resident program, thereby wasting memory. Start the TSR-based application just as you would any other application in Windows NT.*** ***

If one of your applications requires a memory-resident program to work properly, start the memory-resident program and then start the application in the same command window. You can also create a custom startup file that starts the memory resident program, and then specify that startup file in the application's PIF. For more information about custom startup files, see "Custom Startup Files" earlier in this appendix.

When you quit an MS-DOS – based application, Windows NT returns to the Windows NT command interpreter, Cmd.exe. However, by default, when you run a TSR or temporarily suspend an MS-DOS – based application to return to the command prompt, Windows NT runs Command.com, the command interpreter for the MS-DOS environment. This preserves the MS-DOS environment, allowing you to use the TSR immediately. Because starting and running other types of applications from the Command.com prompt can disrupt a TSR or suspended MS-DOS – based application, Windows NT provides the dosonly command. The dosonly command enables only MS-DOS – based applications to be started from the Command.com prompt. You can include the dosonly command in your Config.nt file or the equivalent custom startup file in an application's PIF.

When Command.com is running, some features of the Windows NT command prompt, such as the Doskey display of command history, are not available. If you would prefer to run the Windows NT command interpreter after you have started a TSR or started the command prompt from within an MS-DOS – based application, you can use the ntcmdprompt command. However, keep in mind that the TSR may not be available for use when you are running Cmd.exe. You can include the ntcmdprompt command in your Config.nt file or the equivalent custom startup file in an application's PIF.

OS/2 Environment

Windows NT supports 16-bit character-based OS/2 applications on x86-based computers only. OS/2 bound applications (applications that can run under both OS/2 and MS-DOS) run on RISC-based computers using the MS-DOS subsystem.

Configuring the OS/2 Environment

When Windows NT starts for the first time, it checks the registry for OS/2 subsystem configuration information. If none is found, it looks for information in the original Config.sys file and adds the information to the registry. If the original Config.sys file does not exist or is not an OS/2 configuration file, the subsystem adds the following default information to the registry:

PROTSHELL=c:\os2\pmshell.exe c:\os2\os2.ini c:\os2\os2sys.ini 
%SystemRoot%\system32\cmd.exe
SET COMSPEC=%SystemRoot%\system32\cmd.exe

The subsystem updates the environment variable Os2LibPath with LIBPATH information found in the original Config.sys file. The updated Os2LibPath is %SystemRoot%\system32\os2\dll concatenated with the list of directories specified in the LIBPATH line of the original Config.sys file.

Windows NT supports the OS/2 configuration commands shown in the following table. If you use commands that are not supported, Windows NT ignores them.

Command	Function
protshell	Specifies the command interpreter. Only the Windows NT command interpreter is supported.
devicename	Specifies a user-defined Windows NT device driver used by OS/2 applications.
libpath	Specifies the location of OS/2 16-bit dynamic-link libraries.
set	Sets environment variables.
country	Sets a country code that defines country-dependent information such as time, date, and currency conventions.
codepage	Specifies which code pages your system is prepared to use.
devinfo=KBD	Specifies the information the keyboard needs in order to use a particular code page.

The libpath, set, and devicename commands are processed as follows:

• In Config.sys, libpath appends path information to the OS/2 library path in the Windows NT environment. At the command prompt, you can change the library path for OS/2 applications only for the current Command Prompt window by using the set os2libpath command.

• To change the OS/2 library path permanently, you must change the Os2LibPath system environment variable using the System option in Control Panel. For more information about environment variables, see "Using Environment Variables to Manage Workstations" in Chapter 3, "Managing User Work Environments."

• The following set commands are ignored in Config.sys:

  set vio_ibmvga	set vio_vga	set prompt
  set compspec	set video_devices

• devicename specifies a device driver compatible with Windows NT for use with an OS/2 application. The syntax of the command is:

  DEVICENAME=OS/2devicename [[path][NTdevicename]]
  

*Devicename* is the logical name OS/2 applications use to address the device. *Path* and *NTdevicename* specify the Windows NT device driver to which the OS/2 device name is mapped. If these are not specified, the device is mapped to \\DEVICE\\*os/2devicename*.

Changing OS/2 Configuration Information

Although the OS/2 configuration information is stored in the registry, you can edit that information just as you would edit an OS/2 Config.sys file. To edit the information, you must use an OS/2 text editor.

To change configuration information, you must be logged on as a member of the Administrators group. For additional information about how to change configuration information, see "Changing configuration information" in Help.

Setting Up and Starting Applications

Follow the manufacturer's instruction to install Windows 3.x, MS-DOS, OS/2, or POSIX based applications.

When you use the manufacturer's instructions to install an MS-DOS–based application, Windows NT either creates a PIF, uses the PIF that accompanies the application, or uses the _Default.pif file supplied with Windows NT. Windows 3.x, OS/2, and POSIX based applications do not use PIFs.

When you use the Run command on the Start menu to start an MS-DOS – based application, Windows NT searches for a PIF to use with the MS-DOS – based application:

• If it finds one, Windows NT starts the application using the PIF.

• If no PIF is available, Windows NT uses _Default.pif.

For more information about _Default.pif, see "Using Program Information Files" earlier in this chapter.

Using an Application's Own Mouse Cursor

Some MS-DOS–based applications use a mouse cursor that cannot be synchronized with the system mouse pointer used by Windows NT. If the system mouse pointer does not work as you expect with an MS-DOS–based application, you can hide the system pointer which returns control of the mouse cursor to the application.

For information about how to hide and display the system mouse pointer, see "Hiding the system mouse pointer" in Help.

Starting an Application

You can start applications for all supported application environments using the Run command on the Start menu, Windows NT Explorer, or the command prompt.

When you start an MS-DOS–based application at the command prompt, Windows NT uses _Default.pif to establish the MS-DOS environment. The following PIF settings in _Default.pif are used to establish the environment:

Expanded (EMS) memory	Application shortcut key
Extended (XMS) memory	Custom MS-DOS initialization files
Miscellaneous Multitasking Options (such as Windows shortcut keys)	Compatible Timer Hardware Emulation

To start an MS-DOS–based application at the command prompt using its PIF, use the start command. For example, to start Myapp.exe using Myapp.pif, type start myapp. The first MS-DOS–based application started at the command prompt establishes the MS-DOS environment for all MS-DOS–based applications run in that window.

In a few cases, Windows NT may not recognize that a program is MS-DOS based. If an MS-DOS – based application fails to start, try starting it using the forcedos command. For example, to start a program called MYPROG in the \Oldapps directory, type forcedos \oldapps\myprog at the command prompt.

If a Subsystem Does Not Start

If services or subsystems do not start properly, use the Services or Devices options in Control Panel to check their status. You can try to start services using the Services option and start a device with the Devices option. Also, check the system log in Event Viewer for entries relating to the problem. Event Viewer is in the Administrative Tools (Common) folder.

Interoperability with Windows for Workgroups

When setting up your network, check the issues to ensure smooth interoperability between Windows NT and Windows for Workgroups.

• Browsing is not available if you log on to a Windows for Workgroups computer whose workgroup name is the same as the name of a Windows NT Server domain or if the user name and password are not valid for the domain. If you want to browse the domain, log on with another user name and password that are valid in the domain.

• Guest accounts should remain enabled on domain controllers. Instead of removing guest accounts to restrict access to certain services, just remove any unwanted guest account rights in User Manager for Domains.

• Avoid duplicate user names on different domains. If a user name is duplicated across different domains, logging on produces different results on the Windows NT network and the Windows for Workgroups computer.

• If you seem to have password problems logging on to Windows for Workgroups, delete your passwords list (the .pwl file with your username in the Windows directory). The next time you log on, you will be asked for your password, and a new list will be created.

Running Windows 3.x-based Mainframe Connectivity Software

Some Windows 3.x-based software for connecting to mainframe computers requires a memory-resident program to operate correctly. Such software includes Access for Windows 3270 from Eicon Technology, Extra! for Windows from Attachmate, and Rumba from Wall Data.

When these programs run under 16-bit Windows 3.x, they add a command to Autoexec.bat to start the memory-resident program, or they require the user to start the memory-resident program through a batch file that must be run manually before starting Windows.

To run any of these memory-resident programs with Windows NT Server, add the command for starting the program to the Autoexec.nt file. To find the command used to start the memory-resident program, check Autoexec.bat or the batch file used to start the program under MS-DOS.

Autoexec.nt is stored with other Windows NT Server program files, usually in the %SsystemRoot%\system32 directory. Add the line with the command for starting the memory-resident program after the line containing Redir.exe in Autoexec.nt. Then restart your computer before starting the connectivity application.