Subject: Guide to Win95 support for DOS app's To: GUISPEAK@LISTSERV.NODAK.EDU Content-Type: text I found two more excerpts about DOS sessions under Windows 95 that I think are worth sharing. One is from the Windows 95 Reviewer's Guide, and the other is from the Windows 95 Resource Kit. Together, they explain the concepts and variables regarding support of DOS applications by Windows 95. Since Windows screen readers are still catching up to their DOS counterparts, the information is helpful for configuring a computer system to continue efficient DOS applications while incorporating innovative GUI ones. ---------- >From the Windows 95 Reviewer's Guide: 1 CHAPTER6 Support for Running MS-DOS Support for MS-DOS based applications, device drivers, and TSRs is maintained in Windows 95. In fact, Windows 95 offers better compatibility for running MS-DOS based applications than Windows 3.1 does, including applications that are hardware- intensive, such as games. Like Windows 3.1, Windows 95 allows users to launch an MS-DOS command prompt as an MS-DOS VM. The functionality supported in an MS-DOS VM is the same as that available under the latest version of MS-DOS, allowing users to run the same intrinsic commands and utilities. 95 delivers great support for running MS- based applications and enables even applications that would not run under Windows 3.1 to run properly. This support allows MS-DOS based applications to coexist peacefully with the rest of the Windows 95 environment. Summary of Improvements over Windows 3.1 Improvements made to the system provide the following benefits for running MS-DOS-based applications in the Windows 95 environment: Zero conventional memory footprint for protected-mode components Improved compatibility for running MS-DOS-based applications Improved robustness for MS-DOS-based applications Better support for running MS-DOS-based games, including in a window Support for running existing MS-DOS-based applications without exiting Windows 95 or running MS-DOS externally Consolidated attributes for customizing the properties of MS-DOS-based applications The availability of the Toolbar when running an MS-DOS-based application in a window, providing quick access to features and the functionality for manipulating the window environment A user-scaleable MS-DOS window through the use of TrueType fonts The ability to gracefully end an MS-DOS-based application without exiting the application The ability to specify local VM environment settings on a per-application basis through the use of a separate batch file Support for new MS-DOS commands, providing tighter integration between the MS-DOS command line and the Windows environment Zero Conventional Memory Footprint Components Windows 95 helps make the maximum amount of conventional memory available for running existing MS-DOS-based applications. Some MS-DOS-based applications did not run under Windows 3.1 because by the time MS-DOS-based device drivers, MS-DOS- based TSRs, MS-DOS-based networking components, and Windows 3.1 were loaded, not enough conventional memory was available. Windows 95 replaces many of the 16-bit real-mode components with 32-bit protected-mode counterparts to provide the same functionality while improving overall system performance and using no conventional memory. 32-bit virtual device drivers are provided to replace their 16-bit real-mode counterparts for Chapter 6 Support for Running MS-DOS 3 functions such as those listed in the table on the facing page. The memory savings that results from using 32-bit protected-mode components can be quite dramatic. For example, if a PC were configured with the NetWare NETX client software and used a SCSI CD- ROM drive, SMARTDrive, the MS-DOS mouse driver, and DriveSpace disk compression, the conventional memory savings that would result from using Windows 95 would be over 262 KB! Functions Carried Out by 32-Bit Device Drivers in Windows Convention Description Saved Microsoft NetworkNET.EXE95 KB client software(full)3 KB PROTMAN35 KB NETBEUI8 KB EXP16.DOS (MAC) Novell NetWareLSL5 KB client softwareEXP16ODI9 KB (MLID)16 KB IPXODI.COM30 KB NETBIOS.EXE48 KB NETX.EXE47 KB VLM.EXE MS-DOS extendedSHARE.EXE17 KB file sharing and locking support Adaptec SCSI driverASPI4DOS.SY5 KB S Adaptec CD-ROMASPICD.SYS11 KB driver Microsoft CD-ROMMSCDEX.EXE39 KB Extensions SmartDrive diskSMARTDRV.EX28 KB caching softwareE Microsoft MouseMOUSE.COM17 KB driver MicrosoftDRVSPACE.BI37 KB DriveSpace diskN compression driver Chapter 6 Support for Running MS-DOS 5 Try It! Test Conventional Memory Savings 1. similar to one that now runs Windows 3.1. For example, use PCs with SCSI drivers, network drivers, and system support files, such as SMARTDRV, MSCDEX, or SHARE. 2. loaded on both machines, type mem /c at a command prompt command under Windows 3.1 and under Windows 95. Notice the memory savings under Windows 95 for the same configuration. Compatibility Improvements For a number of reasons, some MS-DOS-based applications wouldn't run properly under Windows 3.1.For example, some MS-DOS-based applications required that lots of free conventional memory be available and thus were prevented from running in an MS-DOS VM by large real-mode components, such as network drivers or device drivers. Other MS- DOS-based applications wouldn't run under Windows 3.1 because they required direct access to the computer hardware and conflicted with Windows internal drivers or other device drivers. The MS-DOS support goal of Windows 95 is to be able to run the ``clean'' MS-DOS-based applications that ran under Windows 3.1 and the ``bad'' MS-DOS-based applications that tried to take over the hardware or required machine resources unavailable under Windows 3.1. Many MS-DOS-based games assume that they are the only application running on the system and access and manipulate the underlying hardware directly, thus preventing them from being run in an MS-DOS VM under Windows 3.1. Games are the most notorious class of MS-DOS-based applications that don't get along well with Windows 3.1. Some of these applications write to video memory directly, manipulate hardware support resources such as clock timers, and take over hardware resources such as sound cards. A number of strategies have been used to provide better support for running MS-DOS-based applications that interact with the hardware, including better virtualization of computer resources such as timers and sound devices. In addition, the use of 32-bit protected-mode device drivers benefits MS-DOS-based applications by providing more free conventional memory than was available under Windows 3.1, so that memory- intensive applications run properly. Different MS-DOS-based applications require varying levels of support from both the computer hardware and from the operating system. For example, some MS-DOS-based games require close to 100 percent use of the CPU to perform properly, and other MS-DOS-based applications modify interrupt addresses and other low-level hardware settings. Windows 95 provides several different levels of support for running MS-DOS-based applications. These levels of support take into account that different applications interact with the hardware in different ways, and that some behave well, whereas others expect exclusive access to the PC system and hardware. By default, MS-DOS-based applications are preemptively multitasked with other tasks running on the system and can run either full-screen or in a window. (CPU-intensive MS-DOS-based applications may not perform well in a window but can be run in full- screen mode to get the best response level.) APPS.INF Windows 95 provides an INF file that contains program settings for many of the popular MS-DOS- based applications. These program settings are based on results from testing of Windows 95 and specify and special configuration-related settings that are necessary to allow the application to run under Windows 95. The APPS.INF file is processed when the user attempts to execute an MS-DOS-based application from the Windows 95 user interface. If a program information file (PIF) doesn't exist for the MS- DOS-based application, the APPS.INF file will be examined by the system for information about the specified MS-DOS-based application. If the application is listed in the APPS.INF file, the system will read the contents and create a PIF Chapter 6 Support for Running MS-DOS 7 that will be used when the application is executed. MS-DOS Mode To provide support for the most intrusive set of MS-DOS-based applications that work only under MS- DOS and require 100 percent access to the system components and system resources, Windows 95 provides a mechanism that is the equivalent of running an MS-DOS-based application in real-mode MS-DOS. This mechanism, called MS-DOS mode, provides an ``escape hatch'' for applications that run only under MS-DOS. In this mode, Windows 95 removes itself from memory (except for a small stub) and provides the MS-DOS-based application with full access to all the resources in the computer. Relatively few MS-DOS-based applications need to run in single MS-DOS application mode because of the improved compatibility support provided by Windows 95. To run an MS-DOS-based application in this mode, the user sets the MS-DOS Mode property on the Advanced Program Settings dialog (from the Advanced button on the Program tab) of the MS-DOS property sheet for the application. To create a unique environment tailored to an application's needs and system requirements, the user can also specify a CONFIG.SYS or AUTOEXEC.BAT file to run for the application. When the user runs an MS-DOS- based application in this mode, Windows 95 asks whether running tasks can be ended. With the user's approval, Windows 95 ends all running tasks, configures the machine to use the CONFIG.SYS and AUTOEXEC.BAT files for the MS-DOS mode session, restarts the computer, loads a real- mode copy of MS-DOS, and launches the specified application. This process is like exiting Windows 3.1 and then running the specified MS-DOS-based application under MS-DOS. When the user exits the MS-DOS-based application, Windows 95 restarts and returns the user to the Windows 95 shell. This solution is much more elegant than requiring users to dual-boot between different operating systems in order to run desired applications. Some entries in the APPS.INF file contain setting information that instruct Windows 95 to run an MS- DOS-based application in MS-DOS mode. For these applications, they will only run in MS-DOS mode due to problems they have running in the protect- mode environment of Windows 95, or due to assumptions they make about the environment (e.g., addressing of extended memory for loading their information) that prevent them from running under Windows 95. Try It! Run an MS-DOS 1. know does not run under Windows 3.1, and run it under Windows 95. 2. know runs under Windows 3.1 full-screen but not in a window, and run it under Windows 95 in a window. Support for Graphic-Intensive MS-DOS Windows 95 improves the support for running graphic-intensive MS-DOS-based applications in the Windows environment. MS-DOS-based applications that use VGA graphic video modes can now be run in a window; they no long have to be run in full- screen mode as with Windows 3.1. Users can still choose to run graphic-intensive MS-DOS-based applications in full-screen mode for the best level of performance. Memory Protection To support a higher level of memory protection for running MS-DOS-based applications, Windows 95 includes on the Program property sheet a global memory protection attribute that allows the MS-DOS system area to be protected from errant MS-DOS- based applications. When the global memory protection attribute is set, the MS-DOS system area sections are read-protected so that applications can't write to this memory area and corrupt MS-DOS support and MS-DOS-based device drivers. In addition to system area protection, enhanced parameter validation is performed for Chapter 6 Support for Running MS-DOS 9 file I/O requests issued through the MS-DOS Int 21h function, providing a higher degree of safety. This option is not enabled by default for all MS- DOS-based applications because of the additional overhead associated with providing improved parameter and memory address checking. Users can set this flag if they constantly have difficulty running a specific MS-DOS-based application. Better Defaults for Running MS-DOS By default, Windows 3.1 ran MS-DOS-based applications full screen and disabled the ability of MS-DOS-based applications to run in the background. To change this default behavior for a specific MS-DOS-based application, users had to use the PIF Editor (PIFEDIT) application to modify or create a program information file (PIF) for the application. By default, Windows 95 runs MS-DOS-based applications in a window and enables the background-execution setting, allowing the application to continue to run when it is not the active application. This change in default behavior provides better integration of running MS-DOS-based applications and Windows-based applications without requiring users to change or customize the state of the system. Consolidated Customization of MS-DOS Each MS-DOS-based application has different characteristics and mechanisms for using machine resources such as memory, video, and keyboard access. Both Windows 95 and Windows 3.1 understand how to run Windows-based applications because requests for system services are handled through the use of the Windows API. However, MS-DOS-based applications include only minimal information about their requirements in the format of their .EXE headers. To provide additional information about their requirements to the Windows environment, PIFs are used to specify the necessary configuration settings. Under Windows 3.1, the PIF Editor application, shown in Figure 39, was used to create or change properties associated with running MS-DOS-based applications. Problems associated with the PIF Editor and the PIF creation process included difficulty in accessing the PIF Editor and PIF settings, the lack of association for new users between PIF properties and the MS-DOS-based application, the lack of a single location for storing PIF files (other than placing them all in the Windows directory), and less-than-intelligent defaults for running MS-DOS-based applications. Figure 39. The PIF Editor in Windows 3.1 Windows 95 enhances the ability to define properties for running MS-DOS-based applications by consolidating PIF files into a single location (the PIF directory where Windows 95 is installed), providing easy access to property information for an application (right-clicking the application's icon or window), and providing better organization of properties (through the use of a tabbed property sheet, shown in Figure 40). By means of these improvements, Windows 95 provides greater flexibility and control for running MS-DOS-based applications. Chapter 6 Support for Running MS-DOS 11 Figure 40. The property sheet for configuring an MS-DOS Try It! View the Property Sheet for an MS-DOS Application 1. application, and choose Properties. 2. based application, and choose Properties. Toolbars in MS-DOS Windows In addition to providing compatibility enhancements to better support the running of MS- DOS-based applications, Windows 95 makes using MS- DOS-based applications in the Windows environment even easier than Windows 3.1. Many Windows-based applications provide one or more toolbars for quickly accessing common features and functionality, Windows 95 extends this simple but powerful feature to provide easy access to the functionality associated with an MS-DOS-based application, as shown in Figure 41. Figure 41. A toolbar in a windowed MS-DOS box Optionally, users can enable the display of a toolbar in the window of a running MS-DOS-based application to provide the user with quick access to the following functionality: Simpler access to cut, copy, and paste operations for integrating text or graphic MS- DOS-based applications with Windows-based applications Easy switching from windowed to full-screen mode Quick access to property sheets associated with the MS-DOS-based application Access to MS-DOS VM tasking properties, such as exclusive or foreground processing attributes Easier access to font options for displaying text in a windowed MS-DOS VM Scaleable MS-DOS Windows Windows 95 supports the use of a TrueType font in a windowed MS-DOS VM, which allows users to scale the MS-DOS window to any size. When the font size is set to Auto, the contents of the MS-DOS window are sized automatically to display the entire window within the user-specified area. Figure 42 shows the size of the MS-DOS command prompt window being made smaller. Chapter 6 Support for Running MS-DOS 13 Figure 42. Because of TrueType font support, the contents of this MS-DOS window will be scaled to fit the smaller size of the window so that they are still displayed in their entirety. Try It! Scale an MS-DOS Window 1. the property sheet, and check that the font size is set to Auto. 2. corner of the window, change the size of the window, and notice how the window's contents are rescaled. (This functionality is more noticeable when performed at higher resolutions.) Ending MS-DOS Applications Gracefully Windows 95 provides support for gracefully closing an MS-DOS VM through a property sheet setting that is available on an application-by-application basis. When this setting is enabled, users can close the MS-DOS-based application just as they would a Windows-based application--- Close Window button. In addition to gracefully ending an MS-DOS-based application, robustness improvements made to the Windows 95 system ensure that system clean-up is completed properly and that all allocated resources are freed. As a result, memory used by an MS-DOS-based application running under Windows 95 is deallocated properly and made available for use by other applications (unlike under Windows 3.1, which didn't properly free DPMI memory). Local Virtual Machine Environment Settings When Windows 3.1 started, it used the MS-DOS environment specified before it started as the default state for each subsequently created MS-DOS VM. Any TSRs or other memory resident software that was loaded before Windows started was replicated across all MS-DOS VMs, whether the VM needed it or not. With Windows 3.1, users could not run a batch file to set the VM environment before starting a given MS-DOS-based application. (Actually, users could run a batch file under Windows 3.1, but when the batch file finished processing the command statements, the MS-DOS VM was closed.) Under Windows 95, a batch file can be optionally specified for a given MS-DOS-based application, allowing customization of the VM on a local basis before running the MS-DOS-based application. The batch file is specified on the Program tab of the MS-DOS-based application's property sheet, as shown in Figure 43. Using a batch file allows MS- DOS environment variables to be set or customized for individual MS-DOS-based applications and for TSRs to be loaded in the local VM only. This mechanism is like having different AUTOEXEC.BAT files for different MS-DOS-based applications. Chapter 6 Support for Running MS-DOS 15 Figure 43. Specifying a batch file on the Program tab of the MS-DOS Support for Accessing Network Resources with UNC Pathnames Windows 95 makes accessing network resources from the MS-DOS command prompt easier by supporting the use of universal naming conventions (UNC). UNC provides a standard naming scheme for referencing network servers and shared directories. It uses the following syntax: \\servername\sharename[\pathname] The Windows 95 shell allows users to browse and connect to network servers without mapping a drive letter to the network resource. Windows 95 supports the same functionality at an MS-DOS command prompt and allows the user to do the following: View the contents of shared directories on network servers from both Microsoft Network servers and Novell NetWare servers by typing dir \\servername\ Copy files from the contents of shared directories on network servers from both Microsoft Network servers and Novell NetWare servers by typing copy \\ destination Run applications from shared directories on network servers for both Microsoft Network servers and Novell NetWare servers by typing \\ New MS-DOS Prompt Commands The MS-DOS command processor and utilities have been enhanced to provide better integration between MS-DOS functionality and the Windows environment. Commands that manipulate files have been extended to support long filenames, and some new commands have been added to Windows 95 to provide access to new capabilities supported by the system. For example, the start following syntax: start < allows users to start an MS-DOS or Windows-based application from the command prompt in one of the following ways: Start an application by specifying the name of a document to open, and Windows 95 launches the application associated with the given file type. For example, typing start myfile.xls starts the application associated with the specified file, if there is a valid association. Start an MS-DOS-based application in a different MS-DOS VM instead of the current one. Start a Windows-based application from an MS- DOS command prompt. Typing the name of a Windows-based application is essentially the same as typing start . Try It! Launch an Application from the MS-DOS Command Prompt 1. Chapter 6 Support for Running MS-DOS 17 2. application in another VM. 3. Windows-based application in minimized form. Support for Long Filenames Many MS-DOS intrinsic commands and utilities have been extended to support the use of long filenames. For example, the following commands are among those that have been extended to support long filenames: The dir filenames in the directory structure, along with the corresponding 8.3 filename. Also, the dir users can display additional file details by typing dir /v. The copy mixing of long and short filenames in copy operations. For example, typing copy myfile.txt ``this is my file'' long filename. 19 ---------- From the Windows 95 Resource Kit: Application Support Configuring MS-DOS-Based Applications Windows 95 configures conventional memory in the same way as earlier versions of MS-DOS, allowing MS-DOS-based applications to run smoothly in Windows 95. For more information about how Windows 95 makes system memory available to MS-DOS-based applications, see Performance Tuning. Application Support Configuring MS-DOS-Based Applications Changing MS-DOS-Based Application Properties (PIF Files) You can set unique properties for individual MS-DOS-based applications. You may want to do this to customize the way an application runs or if the default properties that Windows 95 uses do not work correctly. An application's settings are recorded in its application information file (PIF). Windows 95 has no separate PIF Editor. To configure an application, right-click the application's executable file, and then click Properties. Any settings you change in the Properties dialog box are recorded in the PIF file. When you replace Windows 3.1 with Windows 95, PIFs are upgraded to the Windows 95 format. All existing settings should be preserved, but you may want to verify that they have been. Windows 95 first searches for a PIF in the directory that contains the executable file you are starting. If Windows 95 cannot find a PIF there, it searches the Windows PIF directory. If there is no PIF in the Windows PIF directory, Windows 95 searches the path specified in the AUTOEXEC.BAT file. If no PIF is found, Windows 95 searches the APPS.INF file for a match. If Windows 95 does not find an entry for an application in the APPS.INF file, it uses default settings for the application. If you replace Windows 3.1 with Windows 95, a _DEFAULT.PIF file remains in the directory. In this case, Windows 95 uses information in the _DEFAULT.PIF file to create a PIF for the application. If you do not have a _DEFAULT.PIF file and want to create one, you can do so by copying the DOSPRMPT.PIF to _DEFAULT.PIF. Regardless of how the settings for an application are initially established, you can change them by right-clicking the application's executable file, and then clicking Properties. For more information, see the section Understanding the APPS.INF File. Note You can run a batch file using that batch file's settings by typing its name directly at the command prompt or in the Run dialog box. To run a batch file using the settings of the command prompt (COMMAND.COM), precede the name of the batch file with command /c; for example, command /c myfile.bat. Application Support Configuring MS-DOS-Based Applications Changing Memory Settings for MS-DOS-Based Applications Windows 95 provides a flexible environment for running MS-DOS-based applications, even those applications that must have exclusive access to system resources. Almost all MS-DOS-based applications should run under Windows 95. For MS-DOS-based applications that need sole access to computer resources, Windows 95 offers MS-DOS Mode. When an MS-DOS-based application starts in MS-DOS Mode, Windows 95 removes itself from memory (except for a small stub) and provides the application with full access to all the computer's resources. Before running an application in this mode, Windows 95 ends all running tasks, loads a real-mode copy of MS-DOS, and uses customized versions of the CONFIG.SYS and AUTOEXEC.BAT files to run the application. After you quit the MS-DOS-based application, Windows 95 restarts and returns to the Windows 95 user interface. Caution Running an MS-DOS-based application in MS-DOS Mode does not necessarily improve its performance, but it does allow you to run it when it might not otherwise run in Windows 95. To configure an MS-DOS-based application to run in MS-DOS Mode 1. In My Computer, right-click the application's executable file, and then click Properties. 2. In the application's properties, click the Program tab, and then click Advanced. 3. In the Advanced dialog box, click MS-DOS Mode. If an MS-DOS-based application, such as a game, performs badly because of insufficient memory or a lack of appropriate drivers, you can try the following: 7 Run the application in MS-DOS Mode. 7 Adjust the amount of memory available. 7 Create a custom startup configuration by modifying the contents of the CONFIG.SYS and AUTOEXEC.BAT files, either at the command prompt or in the application's properties. To adjust the amount of memory available to an MS-DOS-based application 1. In My Computer, right-click the application's executable file, and then click Properties. 2. In the Application's properties, click the Memory tab, and then increase or decrease the amount of memory available to the application. For more information about the types of memory, see Setting Properties for MS-DOS-Based Applications. To create a custom startup configuration 1. In My Computer, right-click the application's executable file, and then click Properties. 2. In the application's properties, click the Application tab, and then click Advanced. 3. In the Advanced dialog box, click MS-DOS Mode, click the option named Specify A New MS-DOS Configuration, and then create a custom startup configuration. Note Windows 95 automatically provides expanded memory for MS-DOS-based applications that require it to run. Windows cannot provide this memory, however, if you include a statement in CONFIG.SYS that loads EMM386.EXE with the noems parameter. When you include EMM386.EXE in CONFIG.SYS, use the ram parameter or use the x=mmmm-nnnn statement to allocate enough space in the upper memory area for Windows 95 to create an EMS page frame. For more information, see Command-Line Commands Summary. Tip for Running MS-DOS-Based GamesIn most cases, MS-DOS-based games run under Windows 95 with no special adjustments. Most popular games are listed in the Windows 95 APPS.INF file. Games that include a Windows 3.1 PIF file should also continue to perform well. Certain PIF settings are now obsolete, however, because Windows 95 manages them automatically. These settings include foreground and background priorities, exclusive priority, video memory usage, and video port monitoring. If you run a game that uses graphics modes and Windows 95 fails to run it in a full screen, press ALT+ENTER. To run the game in a full screen every time you start it, right-click the game's executable file, and then click Properties. Click the Screen tab, and then click Full Screen. You can also use the Properties dialog box to adjust other settings that improve performance. For more information, see Setting Properties for MS-DOS-Based Applications. Application Support Configuring MS-DOS-Based Applications Setting Properties for MS-DOS-Based Applications In Windows 95, the properties sheets replace PIF Editor, which was used in earlier versions of Windows to optimize settings for MS-DOS-based applications. To view or modify the properties settings for an MS-DOS-based program 1. Right-click the icon for the program, and then click Properties. (If the program's icon is not on the Windows 95 desktop, use Windows Explorer to find the program, then right-click the icon in Windows Explorer.) This displays the properties sheets for the program. 2. Click the tab you want to use and change the options as appropriate. (See the following section for information about all of these options.) 3. Do the same for all other options and tabs, and then click OK. MS-DOS-based programs have six properties sheets - General, Program, Font, Memory, Screen, and Misc. Use the General properties to see information about the type, size, and location of the MS-DOS-based application. From this properties sheet, you can turn on and off the Read Only, Archive, Hidden, and System attributes, which have the same meaning as they do in MS-DOS. Caution Do not change file attributes unless you are absolutely sure of what you are doing. General properties for an MS-DOS-based application Use the Program properties to identify details about how the program will be run. Program properties for an MS-DOS-based application Option Comments (Filename) Include the filename for the application. Command Line Type the full command line, including the correct drive, path, and options, to run this application. Working Specify the working directory. Batch File Type the name of a batch file you want to run before the program starts. Shortcut Key Specify the key combination (if any) that you want to use to quickly switch to this application. Run Choose whether to run the program in a normal-sized window, a maximized window, or a minimized window. Close on Exit Check this box if you want the window to close after the MS-DOS-based program has ended. Use the Advanced command button to specify information about the mode in which your program will run. Advanced properties for an MS-DOS-based application Option Comments Prevent MS-DOS-based Programs From Detecting Windows Check this box to hide Windows 95 from MS-DOS-based applications for those applications that cannot run or that perform poorly if they detect the presence of Windows 95. Suggest MS-DOS Mode As Necessary Check this box to allow Windows 95 to detect whether MS-DOS-based applications run best in MS-DOS Mode. If it detects such an application, Windows 95 runs a wizard to set up a custom command to run the application. MS-DOS Mode Check this box to run this program in exclusive MS-DOS Mode. No other processes are allowed to run simultaneously if you use this option. Warn Before Entering MS-DOS Mode Check this box to enable the automatic warning presented when Windows 95 is about to run an application that requires MS-DOS Mode and must shut down all other applications. If this option is checked, Windows 95 will warn the user before beginning the shutdown process. Specify A New MS-DOS Configuration Check this box to edit the CONFIG.SYS and AUTOEXEC.BAT files in the corresponding text boxes or by clicking the Configuration button. CONFIG.SYS For MS-DOS Mode Type any lines you want to add to CONFIG.SYS to allow this application to run properly. This version of CONFIG.SYS is used only for the MS-DOS Mode session in which this application runs. AUTOEXEC.BAT For MS-DOS Mode Type any lines you want to add to AUTOEXEC.BAT for this application. This version of AUTOEXEC.BAT is used only for the MS-DOS Mode session in which this application runs. As shown in the preceding table, you can set the path for a specific MS-DOS-based application that runs in MS-DOS Mode in the AUTOEXEC.BAT box. For MS-DOS-based applications that don't run in MS-DOS Mode, you can only set a working directory. You can set a global path for all MS-DOS-based applications by adding a path statement in AUTOEXEC.BAT. You can also write a batch file that sets a path for an MS-DOS-based application; for example: path=%path%;c:\utils;c:\norton After you write the batch file, create a shortcut to your MS-DOS-based application, and specify the batch file's path and name in the Batch File field of the Program properties. >From the Font properties, you can specify the font size and type to be used when the MS-DOS-based program runs. From Font properties, you can also preview how the program window and the font will appear. Font properties for an MS-DOS-based application >From the Memory properties, you can define the following memory allocation options: 7 Conventional memory, which consists of the first 640K of memory available on your computer. 7 Expanded memory, which can be installed as an expanded memory card or emulated by an expanded memory manager (EMM). EMM software maps pages of expanded memory onto the system's upper memory area. 7 Extended memory, which is essentially a seamless upward extension of the original 1-MB address space available in the memory of 80286 and 80386 computers. Extended memory always starts at exactly 1024K, where the upper memory area ends. 7 MS-DOS protected-mode memory, which Windows 95 automatically provides as expanded memory for MS-DOS-based applications that require it to run. It cannot provide this memory, however, if you include a statement in CONFIG.SYS that loads EMM386.EXE with the noems parameter. Use the ram parameter when loading EMM386.EXE in CONFIG.SYS, or use the x=mmmm-nnnn statement to allocate enough space in the upper memory area for Windows 95 to create an EMS page frame. Using Upper Memory Blocks (UMBs) and High Memory Area (HMA) are two ways to free conventional memory for use by MS-DOS-based applications, and thus improve performance. In conventional memory, UMBs are the unused part of upper memory from 640K to 1 MB, where information can be mapped to free memory below 640K. HMA is the first 64K of extended memory, where drivers can be loaded to free conventional memory. Memory properties for an MS-DOS-based application >From the Screen properties, you can specify options for how the application will be displayed. Screen properties for an MS-DOS-based application Option Comments Usage Specify whether the application will run in a window with an initial size you can specify, a full-screen window, or a window with a size automatically determined by the graphic mode it uses. Windows Choose whether to display a toolbar or to preserve the previous Windows 95 window settings. Performance Choose Dynamic Memory Allocation to use the Windows 95 video ROM-handling capabilities. Choose Fast ROM Emulation to enable VxD emulation of selected video ROM services and to speed up video operations, particularly text output. >From the Misc properties, you can specify details about running your program in the foreground and in the background. You can specify whether your program must have exclusive access to the system when it is in the foreground and whether running a screen saver is allowed when the program is active. You can also specify whether the program must be suspended when it is in the background. In addition, you can specify preferences for mouse, idle sensitivity, Windows hot keys, and other options. Miscellaneous properties for an MS-DOS-based application In Windows 95, the Properties dialog box replaces PIF Editor, which was used in earlier versions of Windows to optimize the settings for MS-DOS-based applications. For information about changing the properties for executable files, see online Help. For Help on the Properties dialog box of an executable file, click the question mark button at the top of the dialog box, and then click the item you want information about. Application Support Configuring MS-DOS-Based Applications Setting Paths for MS-DOS-Based Applications You can set the path for a specific MS-DOS-based application that runs in MS-DOS Mode by carrying out the following procedure. To specify a path for MS-DOS-based applications that run in MS-DOS Mode 1. Right-click the application's executable file, and then click Properties. 2. Click the Application tab, and then click Advanced. 3. Make sure MS-DOS Mode is checked. 4. In the AUTOEXEC.BAT For MS-DOS Mode area, specify the correct path. Note For MS-DOS-based applications that do not run in MS-DOS Mode, you can set only a working directory. You can set a global path for all MS-DOS-based applications by adding a path statement to AUTOEXEC.BAT. You can also write a batch file that sets a path for an MS-DOS-based application; for example: path=%path%;c:\utils;c:\norton After you write the batch file, carry out the following procedure to ensure that Windows runs it before starting your MS-DOS-based application. To run a batch file before starting an MS-DOS-based application 1. In the application's properties, click Program. 2. In the Batch File area, specify the batch file's path and name. 3. If you want the VM window in which the batch file is running to close after the batch file has finished, make sure the Close On Exit box is checked. For more information about commands that can be used in batch files, see Command-Line Commands Summary. Application Support Configuring MS-DOS-Based Applications Understanding the APPS.INF File APPS.INF contains a section named [PIF95] that acts as a master list of settings for MS-DOS-based applications. Each line in this section corresponds to a subsequent entry in APPS.INF that contains information about running that specific application. Each entry in the [PIF95] section uses the following syntax: app file=%title%, icon file, icon num, set working, section, other file, set pif Entry Meaning app file The filename, with extension, of the application's executable file. title The name that appears in the application's title bar. The string identifier must appear in the [Strings] section of the INF file, set to the quoted name of the application. icon file The file from which to extract the application's icon. icon num The number from the icon extraction table. The default is 0. set working Allows the computer to automatically set the working directory to the one that contains the executable (0, the default), or prevents it from doing so (1). section The name of the corresponding section in APPS.INF that contains details about this application. other file The key file within a directory for this application, used when two app file entries are identically named. set pif The value allowing (0, the default) or preventing (1) creation of a PIF file for this application. Each section following the [PIF95] section includes entries that define any parameters, any required memory or other options, and options that can be enabled or disabled. For example: [WORD.EXE] LowMem=384 Enable=cwe Disable=win,bgd,asp The Enabled= and Disabled= entries use the following abbreviations. To separate multiple entries, use commas. Entry Meaning Entry Meaning aen ALT+ENTER eml EMS memory locked aes ALT+ESC ems EMS memory afp Allow fast paste emt Emulate ROM aps ALT+PRINT SCREEN exc Exclusive mode asp ALT+SPACE gmp Global memory protection ata ALT+TAB hma Use HMA awc Automatic window conversion lml Low memory locked bgd Background mse Mouse cdr CD-ROM net Network ces CTRL+ESC psc PRINT SCREEN cwe Close on exit rvm Retain video memory dit Detect idle time rwp Run Windows applications dos Real mode win Run in a window dsk Disk lock xml XMS memory locked .