Application Support: The Basics

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.

With Windows 95, you can run Win32-based, Win16-based, and MS-DOS – based applications. This chapter offers some tips you can use to ensure that applications run well under Windows 95.

Windows 95 optimizes the performance of new Win32-based applications and existing applications created for MS-DOS and earlier versions of Windows. They perform more smoothly because Windows 95 significantly increases system resources available to them and more efficiently manages how they use system memory. Windows 95 also supports new and existing versions of OLE technology, including OLE Controls and OLE Automation for new Windows-based applications.

Increased system resources.

Windows 95 increases system resources for all applications by using 32-bit heaps to store applications' data structures, making more resources available for the remaining data elements. In addition, Windows 95 increases the number of timers, COM and LPT ports, Windows menu handles, and other resources available to applications. For more information, see Chapter 17, "Performance Tuning."

Improved memory management.

The Virtual Machine Manager, an integral part of Windows 95 architecture, manages the memory that each application needs. A virtual machine (VM) is an environment in memory that seems to function as a separate computer for each application. All Win32-based and Win16-based applications run in the System VM, in which all system processes also run. Each MS-DOS – based application runs in its own VM. For more information, see Chapter 31, "Windows 95 Architecture."

On This Page

Win32-Based Applications
Application Support: Issues
Installing Applications
Removing Applications
Running Applications
Configuring MS-DOS–Based Applications
Using OLE to Share Data Between Applications
Technical Notes on Application Support
Troubleshooting Applications

Win32-Based Applications

Win32-based applications receive the full benefit of the performance enhancement features in Windows 95. Because each Win32-based application runs in a separate memory space, it can take complete advantage of the preemptive multitasking capabilities of Windows 95.

Requirements for Windows 95 Logo.

To get the best possible performance, upgrade to versions of applications that were designed for Windows 95 whenever possible. Applications written specifically for Windows 95 carry the "Designed for Windows 95" logo. To qualify for a Windows 95 logo, applications must meet the following requirements:

• Use Win32 APIs executable in the PE (Portable Executable) format

  Support Windows 95 user interface (shell), including the following:

  • Use system metrics for sizing

  • Use system colors (recommended)

  • Use the right mouse button for context menus and not for anything else (recommended)

  • Use Windows 95 Setup guidelines to make the application visible in the shell

• Use long filenames

• Be aware of Plug and Play events (recommended)

• Run successfully on Windows NT 3.5 or later

There are modified requirements for file-based applications, utilities such as anti-virus software, and compilers and other development tools. For more information, contact the Microsoft Developer Network (MSDN). In Canada or the United States, call (800) 759-5474, or in Europe call +31 10 258 88 64.

Win16-Based and MS-DOS – Based Applications

Win16-based applications designed for Windows 3.1 run under Windows 95 without modification, but these applications run in a shared memory space and cannot take advantage of preemptive multitasking. However, they do benefit from improvements incorporated into the Windows 95 subsystem. For Win16-based and MS-DOS – based applications that are known to need special parameters to run, Windows 95 includes an APPS.INF file that defines parameters for each application.

Because of default settings and other support in Windows 95, you do not need to have CONFIG.SYS, AUTOEXEC.BAT, and INI files to run Win16-based and MS-DOS – based applications, although you can still use settings from existing files. When you upgrade by replacing Windows 3.1 with Windows 95, Windows automatically moves the current settings for your installed applications to the Registry for use with Windows 95.

MS-DOS – based applications can take advantage of the improved memory management and increased system resources that are made possible by the new system architecture. Most applications can now run in a window. MS-DOS – based applications that do not run well under Windows can run the application in exclusive MS-DOS Mode, which makes all system resources available to that application, as described in "Changing Memory Settings for MS-DOS – Based Applications " later in this chapter.

When running under Windows 95, MS-DOS – based applications also benefit from the following:

• Improved robustness, including better virtualization for computer resources, such as support for timers and sound devices.

• Improved support for highly graphical MS-DOS – based applications. This allows you to run video-mode style applications in a window rather than in a full screen.

• Improved memory protection. Windows 95 includes a global memory-protection attribute in the properties dialog box for executable files. This attribute allows the MS-DOS system area to be protected from errant MS-DOS – based applications.

• Improved printing performance and font support, including user-scalable windows with support for TrueType® fonts in virtual machines (VMs).

• Local environmental settings for VMs. You can also customize the VM environment by specifying a batch file in an executable file's properties dialog box.

Application Support: Issues

Before you install and configure applications for use with Windows 95, consider the following questions:

• How will applications perform in your networking environment? After you set up Windows 95 on the network, you will need to install and test how applications perform. For example, for MS-DOS – based applications that were created for your network, test whether they can run in a window or if you need to run them in MS-DOS Mode. After you test them, disperse information to users about how to run different applications.

• Do the default settings for MS-DOS – based applications work well for each of your applications? You can use the executable file's properties dialog box to modify settings as needed, as described in "Configuring MS-DOS – Based Applications" later in this chapter.

• Do you need to restrict users from running MS-DOS-based applications? Or do you want to allow only certain Windows-based applications to run on a computer? For computers that run File and Printer Sharing services, where access to the shared resources is critical to other users, you may want to restrict the ability to switch to MS-DOS Mode to ensure that shared resources are always available. For information about using system policies to restrict access to MS-DOS Mode or restrict the applications that can run on a computer, see Chapter 15, "User Profiles and System Policies."

• Which applications do you want to share over the network? With Windows 95, most applications can be shared across the network by installing them on a network computer and then creating a shortcut to them. Users can open them from the network location by double-clicking the shortcut. For more information, see "Installing and Sharing Applications Across the Network" later in this chapter.

  To share some large applications, you must run a separate setup on the server and on the workstation. Check the documentation for the application before attempting to share it across the network.

• Which TSRs do you need to run to support applications? If you are running Client for NetWare Networks, you cannot process TSRs in a logon script. For information about how to load a TSR, see "Running Logon Scripts with Client for NetWare Networks" in Chapter 11, "Logon, Browsing, and Resource Sharing."

• Do you want users to have access to the Windows 3.1 Program Manager rather than to the new Windows 95 interface? For information, see "Using the Windows 3.x Program Manager with Windows 95" later in this chapter.

Installing Applications

How you install and configure an application depends on whether it is created for Windows 95, an earlier version of Windows, or MS-DOS.

Using Add/Remove Programs with Win32-based applications.

Windows 95 simplifies installing applications created for Windows 95 by providing an Add/Remove Programs option in Control Panel. When you install an application by using this option, Windows 95 does the following:

• Adds information about the application to the Registry, such as which parameters to use to run the application and which files to delete when removing the application from the computer.

• Searches drives A and B for applications named INSTALL or SETUP. If a setup application uses a name other than INSTALL or SETUP, start the setup application by double-clicking its icon in My Computer.

Keeping Windows 3.1 settings.

If you upgrade by placing Windows 95 in the Windows 3.x directory, you do not need to reinstall applications. Setup automatically moves information about currently installed applications to the Registry. Setup also converts existing Program Manager groups and adds them to the Programs menu on the Start menu.

If you install Windows 95 in a separate directory, you must reinstall all Windows-based applications to ensure that they work properly under Windows 95. Copying .GRP and INI files from your previous Windows directory is not sufficient to run applications under Windows 95.

Creating applications groups and icons.

When a Windows-based setup application creates an application group and icons, Windows 95 creates folders and icons for the Programs menu on the Start menu. If a setup application fails to create a shortcut correctly, you can do it manually. For information about adding shortcuts to the Start menu, see online Help.

Running specific applications.

For information about whether a specific application runs under Windows 95, check the Windows 95 README.TXT file. If you do not find an application listed in the README.TXT file, check with the application's manufacturer or your software vendor. Windows 95 provides a utility that makes an incompatible application compatible with Windows 95. The "make compatible" utility is a file named MKCOMPAT.EXE in the Windows SYSTEM directory. For more information, see "Troubleshooting Applications" later in this chapter.

Installing MS-DOS-based applications.

You can install an MS-DOS – based application by running its executable file. Windows 95 copies information about the application from the APPS.INF file to the application's PIF file. If it was installed under an earlier version of Windows 95, Setup automatically moves its settings to the new APPS.INF file. If there is no information about the application in APPS.INF, Windows 95 uses default settings instead, or you can manually set the properties, as described in "Setting Properties for MS-DOS – Based Applications" later in this chapter.

Note: Windows 95 has no separate PIF Editor. To configure an application, right-click the application's executable file, and then click Properties.

For more information about installing applications after you have installed Windows 95, see online Help.

Installing and Sharing Applications Across the Network

You can share most applications on a network by installing them on a network computer and then creating a shortcut to them. Users can run the application by double-clicking the shortcut or by double-clicking the application's icon in Network Neighborhood.

To share an application on the network

1. Install an application on a network server or workstation, as described in the documentation from the vendor.

2. In Network Neighborhood, right-click the icon for the application, and then click Create Shortcut. Windows 95 asks if you want to create a shortcut on the desktop.

For more information about creating shortcuts, see online Help. For information about creating and distributing custom shortcuts using system policies, see Chapter 15, "User Profiles and System Policies."

Tip In general, Windows 95 doesn't allow you to specify a working directory in the properties sheet of a Win16-based application. This is because the program file has links assigned to it that rely on unchanging data. However, you can achieve the same effect by creating a shortcut for the application and specifying a working directory in the Start In box in the properties for the shortcut.

Creating an APPS.INI File

If users will be installing applications from source files stored on the network, you can create an APPS.INI file that contains a master list of applications and their network locations. When a user's Registry contains a reference to the APPS.INI file, a new tab named Network Install appears in Add/Remove Programs. The Network Install tab lists all the applications that appear in the APPS.INI file.

To create an APPS.INI file

1. Use a text editor to create a file that contains list of applications using the following format:

   application name = [*] UNC path

   For application name, substitute the name that you want users to see on the Network Install tab. For UNC path, substitute the network location of the setup application. If a setup application cannot work with UNC names, include an asterisk before it. For example:

Word for Windows=*\applications\forusers\WORD60\SETUP.EXE

2. Save the APPS.INI file on a server to which users have read-only access.

To display the applications listed in APPS.INI on the Network Install tab

1. In the Registry, click the following key:

Hkey_Local_Machine/Software/Microsoft/Current Version

2. Right-click a blank area in the right pane, and then click New.

3. Click String Value, and then type the following:

   appinstallpath

4. Press ENTER, and right-click the item you just created.

5. Click Modify. In the Value Data area, type the UNC path to the APPS.INI file.

For information about adding Registry settings in setup scripts, see Appendix D, "MSBATCH.INF Parameters."

Removing Applications

If you installed applications designed for Windows 95 by using the Add/Remove Programs option in Control Panel, they can safely be removed in the same way. Because the application's components are tracked through the Registry, Windows 95 deletes all of the application's files unless those files are being used by another installed application. Shared files are retained on the hard disk.

For more information about removing an application that was designed for Windows 95, see online Help. For all other applications, check their documentation to determine which files should be removed.

Note: To appear in the uninstall list in the Add/Remove Programs option, an application must provide an uninstall utility. Only applications designed for Windows 95 include this functionality.

Removing a Win16-based or MS-DOS – based application is not always straightforward. You can delete the directory that contains the application but, especially in the case of Win16-based applications, additional files belonging to the application are often located in the Windows or Windows SYSTEM directory. There is no way to determine which applications placed certain files in these directories, so some of the application's files may be left behind on your hard disk.

Conversely, if you try to delete all the files of an application installed in the Windows or Windows SYSTEM directory, you might delete a system file that is used by other applications. If this happens, the other applications will not run properly and must be reinstalled.

To avoid problems when removing Win16-based or MS-DOS – based applications, check their documentation for instructions about removing them, and keep backup copies of DLLs and other essential system files in case you need to restore them.

Running Applications

There are several ways to start applications in Windows 95:

• Click the Start button, point to Applications, point to the folder that contains the application, and then click the application's name.

• In My Computer or Windows Explorer, double-click the application's icon.

• Click the Start button, click Run, and then type the path and filename for the application's executable file.

• Right-click the desktop, point to New, and then click Shortcut. Use the Create Shortcut wizard to create a shortcut to applications. To start the application, double-click the shortcut icon on the desktop.

• In My Computer or Windows Explorer, click the icon, click the File menu, and then click Open. Or right-click the application's icon, and then click Open.

• Click the Start button, and then click Run. Drag an executable file from My Computer, Windows Explorer, or Network Neighborhood into the Run dialog box. If there is already text in the Run dialog box, the executable file you drag into the dialog box (including the application's path or UNC name) is appended to the existing text.

• Use the Windows 3.1 Program Manager. For more information, see "Using the Windows 3.x Program Manager with Windows 95" later in this chapter.

To bring a running application to the foreground

• On the taskbar, click the button for the application.

  – Or –

  Press ALT+TAB until the icon for the application you want is selected.

Tip Instead of starting a popular Windows-based application to view a document, you can use Quick View. For example, if you are searching for a particular document, but aren't sure of its name, you can use Quick View to look at individual documents. When you find the document you're looking for, you can click the File menu in Quick View, and then click Open File For Editing. For more information, see online Help.

Associating a File Type with an Application

To open an application when you double-click a related document file, the file's type must be defined in the Registry. If the file type is defined in the Registry, it appears in a list of file types that you can associate with an application.

For information about associating a file type with an application so that the application runs when you double-click a file, see online Help.

If a file type has been associated with an application, you can reassociate the file type to a different application.

To reassociate a file type

1. Double-click My Computer, and then click the View menu.

2. Click Options, and then click the File Types tab.

3. Click the type of document you want to reassociate, and then click Edit.

4. In the Actions list, click Open, and then click Edit.

5. In the Application Used To Perform Action area, type the path to the application you want to associate with the file type.

Some applications, such as Microsoft Word, associate multiple extensions with a file type. For example, a Microsoft Word document is associated by default with both a .DOC and an .RTF extension. This can cause problems if a user wants to change which application opens a particular file. To reassociate a file type with an application under these conditions, you must delete all extensions registered to that application, and then re-associate each file type with an application. In addition, you must redefine Open, Print, and DDE commands for each file type. To do this, in My Computer or Windows Explorer, click the View menu, click Options, and then click the File Type tab.

If you click New in the File menu in Windows Explorer or in the context menu, a list of objects appears, such as Folder or Microsoft Excel 5.0 Worksheet. Clicking an object creates a new object in Windows Explorer or on the desktop. You can add an object to this list by adding a key called ShellNew to the corresponding file extension in the Registry for the related filename extension:

Hkey_Classes_Root.ext

After creating the ShellNew key, you need to add a new string value called FileName with a data value that equals the path name to a template file in the ShellNew subdirectory. For example:

FileName="c:\windows\shellnew\excel.xls"

Tip In the Open dialog box in a Windows-based application, you can request that multiple file types be displayed by separating the file types with a semicolon. For example, to see .DOC, .TXT, and .RTF files in an Open dialog box you would type *.doc; *.txt; *.rtf.

Configuring the Start and Programs menus

The items that appear on the Start and Programs menus are arranged alphabetically. To specify a different order, rename menu items to include a number as their first character. Renaming menu items in this way also enables users to start an application by pressing the number at the beginning of the application's name.

To specify the order in which items on the Start or Programs menu appear

1. Right-click the Start button, and then click Open.

2. To specify the order of items at the top of the Start menu, skip to step 3.

   To specify the order of items on the Programs menu, double-click the Applications folder.

   To specify the order of items on a submenu of the Programs menu, double-click the Applications folder, and then double-click the folder that corresponds to the submenu.

3. Right-click the item that you want to appear first on the menu, and then click Rename.

4. Press HOME, type the number 1 followed by a space, and then press ENTER.

5. Repeat steps 3 and 4 using consecutive numbers until all the menu items that you want to arrange in a different order have been numbered.

For information about the following topics, see online Help:

• Adding an application to the Start or Programs menu

• Adding new submenus (or folders) to the Programs menu

• Rearranging items on the Programs menu

Note: Windows 95 adds your most recently used documents to the Documents menu or the Start menu. When you open a file in a Win32-based application, Windows 95 adds the data file to the Documents menu. Windows 95 does not add files to this list that were opened in a Win16-based application. However, if you double-click a document in Windows Explorer or My Computer, Windows 95 does add it to the list.

Using the Windows 3.x Program Manager with Windows 95

Some users may not feel comfortable moving to the new Windows 95 interface immediately after you upgrade their computers from Windows 3.x. To ease their transition, you can use the a Windows 3.x Program Manager.

When you replace Windows 3.x with Windows 95, you can choose to include Program Manager on the Windows 95 desktop. Program Manager does not support the following Windows 95 functionality:

• You cannot copy an item from a Program Manager group to the Windows 95 desktop, and you cannot copy My Computer, Network Neighborhood, Control Panel, or the Printers folder to a Program Manager group.

  The folders that were created when you installed Windows 95 are not designed to work with Program Manager. Program Manager recognizes files only.

• When you copy a shortcut to a Program Manager group, the shortcut's name is truncated to eight characters.

  In this case, Program Manager uses the filename (minus the extension) for the shortcut's name. For example, if you copy the MS-DOS Prompt shortcut from My Computer to a Program Manager group, the MS-DOS Prompt description is shortened to MS-DOSPR. This occurs because the MS-DOS Prompt shortcut uses the MS-DOS name MS-DOSPR.LNK. To rename the shortcut, click it, click the File menu in Program Manager, and then click Properties. In the Description field, type a new name.

• When you copy a shortcut or other item to Program Manager, the item's icon is lost.

  This occurs because the icon created in the Program Manager group references a file with an .LNK extension. Because Program Manager does not recognize this extension, a generic icon appears. To change the icon, click it, click the File menu in Program Manager, and then click Properties. Click Change Icon, and then select a different icon.

• You cannot quit Windows 95 by quitting Program Manager. To quit Windows 95 or restart your computer, click the Start button, and then click Shut Down.

Tip For a comparison of Windows 95 and Windows 3.x features, see "If You've Used Windows Before" in online Help.

If you want to run Windows 3.1 Program Manager, it must be installed during Windows 95 Setup.

To install the Windows 3.1 Program Manager during Windows 95 Setup

1. In Windows 95 Setup, choose Custom as the Setup Option type.

2. In the Computer Settings dialog box, click User Interface, and then click Change.

3. Click Windows 3.1 (Program Manager), and then click OK.

After Setup, a shortcut for Program Manager appears in the StartUp folder. This causes Program Manager to start every time Windows 95 is started.

After users grow familiar with the Windows 95 interface, they will probably prefer to use it to run applications and manage files. At this point, you can remove the shortcut to Program Manager from the StartUp folder.

Closing Failed Programs

If an application stops responding, or other parts of the computer, such as the keyboard, mouse, or display no longer function correctly, you can end the malfunctioning process or application without quitting other applications or Windows 95. This ability to recover from problems related to a specific application ensures robust performance in Windows 95.

To end a failed process or quit an application that has stopped responding

1. Press CTRL+ALT+DEL.

   The Close Application dialog box appears. If Windows 95 detects that a processor application has failed, the words "not responding" appear beside it.

   

2. Click the process or application you want to close, and click End Task.

Some applications may have several processes running simultaneously. For example, a mail application may be running an executable application and a spooler. If a single process fails and you close that process, the rest of the application may continue to run.

Although it is possible to restart your computer by pressing CTRL+ALT+DEL twice, it is not recommended. Correctly restarting or shutting down your computer ensures that all current information is saved in the Registry and that each application is closed correctly before Windows closes. It also ensures that users who are connected to a shared resource do not lose data when a computer running File and Printer Sharing is shut down.

For more information about restarting or shutting down a computer, see online Help.

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 Chapter 17, "Performance Tuning."

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" later in this chapter.

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.

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:

• Run the application in MS-DOS Mode.

• Adjust the amount of memory available.

• 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" later in this chapter.

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 Appendix A, "Command-Line Commands Summary."

Tip for Running MS-DOS-Based Games

In 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" later in this chapter.

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 once 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:

• Conventional memory, which consists of the first 640K of memory available on your computer.

• 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.

• 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.

• 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 property sheet 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, look up "file properties, changing" in the Windows 95 Help Index.

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.

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 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 Appendix A, "Command-Line Commands Summary."

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

Using OLE to Share Data Between Applications

Windows 95 includes built-in OLE functionality that enables you to share data between OLE-compliant applications. Using applications that take advantage of OLE technology, you can create OLE documents that contain multiple types of data and that allow you (or other users) to edit or display that data without running other applications.

OLE is a technology built into Windows 95 that improves on the OLE 1.0 standard. It provides services for sharing OLE objects (units of data) and the related functions needed to manipulate that data. In Windows 95, the file STORAGE.DLL manages OLE documents.

Under Windows 95, applications that use OLE technology can use new OLE objects, and new OLE applications can use OLE 1.0 objects. However, in each case, functionality is limited to OLE 1.0. For example, OLE 1.0 does not include in-place interaction, so when you double-click an object in an OLE 1.0 application, the source application starts and the object is displayed in another window.

The new OLE technology provides a way of communicating between container applications and object applications. Container applications maintain OLE documents, and object applications act as servers to provide various data objects (such as text, bitmaps, spreadsheets, spreadsheet cells, or sound clips) to be included in the OLE document. The container application does not need any information about the object application or its specific data type to communicate with it.

Windows 95 keeps track of OLE objects by keeping an entry for each one in the Registry. Each entry includes a unique identification tag for the object and an application identifier. The application identifier is also used as a class name when OLE objects are placed in OLE containers. For example, "Word.Document.6" is the application identifier for a Word 6.0 document.

Note: With ClipBook Viewer, an OLE application that is located in the OTHER\CLIPBOOK directory on the Windows 95 compact disk, you can share OLE objects for use in documents across a network. For more information, see Help in ClipBook Viewer.

OLE objects can be visually edited, meaning that users can activate objects and edit, play, or otherwise manipulate them in the location in which they are embedded.

To enable visual editing, both the container application and the object application must be OLE-compliant and must support the OLE visual editing interface. If either the container or the object application (or both) meets only the OLE 1.0 specification, the object application will be launched in its own window for editing. For example, Corel® Draw 4.0 implements some features of OLE that do not include the visual editing interface, so when a Corel Draw 4.0 object is opened for editing, the Corel Draw 4.0 application will start in its own window.

If an embedded object has a filename extension that is not associated with any application, you may be unable to successfully activate it. You must first associate the file type with an application. For information about associating file types with applications, see online Help.

To move or copy an object, you can drag it from one container to another. When doing so, use the following key combinations.

Mouse Action	Result
Drag and drop	Determined by target and source; usually Move
SHIFT+drag and drop	Move the object
CTRL+drag and drop	Copy the object
SHIFT+CTRL+drag and drop	Link the object from the source to the container

For OLE-compliant applications, when an object is dragged between documents, it automatically becomes embedded in the destination document, unless the data type is the same for both the source and the destination application. In this case, the information is merely placed as native data.

Technical Notes on Application Support

This section summarizes technical information about running applications under Windows 95. For information about the supporting system components, see Chapter 31, "Windows 95 Architecture."

System Changes Affecting Application Support

The following sections describe how system changes affect 16-bit and 32-bit applications and MS-DOS – based applications.

Windows 95 changes the system configuration files, as described in Chapter 6, "Setup Technical Discussion." The following changes affect application suuport:

• If no FILES= line is specified in CONFIG.SYS, Windows 95 uses a setting of 60.

• Windows 95 enables file sharing by default. Therefore, it is no longer necessary to add SHARE.EXE to the AUTOEXEC.BAT file or VSHARE to the SYSTEM.INI file.

• Many application settings have moved from INI files to the Registry. If you install an application after Windows 95 is installed, and the setup application writes directly to the WIN.INI and SYSTEM.INI files instead of using documented functions, Windows 95 does not recognize those changes. To resolve this problem, or obtain a version of the application that is designed for Windows 95.

Support for Win32-Based Applications

Applications that use Win32 APIs and are designed for Windows 95 can take full advantage of all Windows 95 performance enhancement features. Win32-based applications feature several benefits over Win16-based applications, including preemptive multitasking, Win32 APIs, long filename support, separate message queues, and memory protection. Each Win32-based application runs in its own fully protected, private address space, preventing it from causing the operating system or other applications to fail and preventing interference from errors generated by other applications. An added benefit is that you can manage files from the Open dialog box in Win32-based applications.

To support preemptive multitasking, the Windows 95 kernel schedules the time allotted for running applications. This results in smoother concurrent processing and prevents any one application from using all system resources without permitting other tasks to run. (An exception is when you run an MS-DOS – based application in MS-DOS Mode, which gives the application exclusive use of system resources.) Win32-based applications can implement threads to improve the level of detail at which they can take advantage of multitasking.

Under Windows 3.1, the operating system passes control to another task, allowing that task to be scheduled cooperatively, at the point when an application checks the system message queue. In this case, if an application doesn't check the message queue on a regular basis, or if the application stops and thus prevents other applications from checking the message queue, the system keeps other tasks suspended until the errant application is ended. Under Windows 95, each Win32-based application has its own message queue and thus is not affected by how other tasks access message queues.

Resources allocated for each Win32-based application tracked on a per-thread basis are automatically freed when the application ends. If an application stops responding, you can press CTRL+ALT+DEL to display the Close Application dialog box, and then close the unresponsive application without affecting other running tasks.

To make the most of Windows 95, your applications should:

• Be Win32-based

• Be OLE-compliant to allow for data sharing with other applications

• Use Remote Procedure Call (RPC) for networked NetBIOS applications

• Use Windows Sockets for networked non-NetBIOS applications

Win32-based applications that run under Windows NT will run well under Windows 95 if the application does not use any Windows NT-specific APIs (such as those for security) or if it has been designed to run under both Windows 95 and Windows NT.

Support for Win16-Based Applications

Win16-based applications designed for Windows 3.1 run under Windows 95 without modification. Windows 95 ensures that any Win16-based application runs on a 4-MB (or greater) computer as well as or better than it did under Windows 3.1. In addition, the performance of Win16-based applications is improved because it can use operating system services provided by the 32-bit system components of Windows 95, including 32-bit device driver components and 32-bit subsystems.

Windows 95 provides the same system resources to both Win32-based and Win16-based applications, but Win16-based applications cannot take advantage of preemptive multitasking. Win16-based applications share memory, a common input queue, and a common message queue, and their processes are scheduled cooperatively.

Win16-based applications benefit from preemptive multitasking of other system components, including the 32-bit print and communications subsystems and improvements made in system robustness and protection for the Windows 95 system kernel.

Because all Win16-based applications run in the same virtual machine (VM), an errant application can cause other Win16-based applications to fail, but shouldn't adversely affect Win32-based applications. However, the improvements made to overall system-wide robustness significantly increase the system's ability to recover from an errant application and improved cleanup of the system lessens the likelihood of application errors. Windows 95 tracks resources allocated by Win16-based applications and uses the information to clean up the system after an application exits or ends abnormally, thus freeing up unused resources that the rest of the system can use. If an application does fail, you can press CTRL+ALT+DEL to display the Close Application dialog box, and then close the unresponsive application without affecting other running tasks, as described in "Closing Failed Programs" earlier in this chapter.

Note: Win16-based applications cannot use long filenames. The Windows 95 file system should preserve long filenames while you use a Win16-based application to edit files. However, you will lose long filenames if you copy files from within existing Win16-based applications such as user interface replacements.

Support for MS-DOS – Based Applications

Windows 95 includes many improvements over Windows 3.1 for running MS-DOS– based applications, including better printing support and improved capabilities for running hardware-intensive applications such as games.

As with Windows 3.1, each MS-DOS – based application runs in its own virtual machine (VM), which allows multiple 8086-compatible sessions to run on the CPU. This, in turn, allows existing MS-DOS – based applications to run preemptively with the rest of the system. The use of virtual device drivers (VxDs) provides common regulated access to hardware resources. Each application running in a VM appears to run on its own individual computer; this allows applications that were not designed for multitasking to run concurrently with other applications.

VMs are protected from each other, and from other running applications. This prevents errant MS-DOS – based applications from overwriting memory that is occupied or used by system components or other applications. If an MS-DOS – based application attempts to access memory outside its address space, the system notifies the user and ends the MS-DOS – based application.

One of the major difficulties MS-DOS – based applications had in the VMs in earlier versions of Windows was insufficient conventional memory space. By the time MS-DOS – based device drivers, TSR applications, and networking components were loaded with Windows, there often wasn't enough conventional memory left to allow the MS-DOS – based application to load or run. Windows 95 provides 32-bit, protected-mode driver components that replace many 16-bit, real-mode device driver and TSR counterparts, improving overall system performance and using no conventional memory. The memory savings with protected-mode components can be significant. For example, a computer using only Windows 95 protected-mode components would save more than 225K of conventional memory over the amount used by real-mode networking software, drivers for a mouse and SCSI CD-ROM drive, and SMARTDrive.

How Windows 95 Accommodates Application Problems

Some Windows-based and MS-DOS – based applications may not run well under Windows 95 because they were written to take advantage of characteristics of older operating systems. For example, certain applications use a portion of the title bar to include items other than the title, such as a Quick Help button. Because Windows 95 title bars are not formatted in the same way as Windows 3.x title bars, some information may be overwritten when you run these old applications.

In addition, some applications use interrupts that are not automatically supported by Windows 95. Others do not handle long filenames well, or incorrectly check for the operating system's version number.

Windows 95 provides a utility to make an application that is incompatible with Windows 95 compatible. You can use this utility to troubleshoot if you have trouble printing from an application or an application stalls or has other performance problems. It provides a means to switch from EMF to RAW printer data, to increase stack memory to an application, to emulate earlier versions of Windows, and to solve other common problems that cause an application not to run with Windows 95. For more information, see online Help.

To run the Make Compatible utility

• Click the Start button, click Run, and then type mkcompat.exe

Notes: Many programming tools that are not specifically designed to run under Windows 95 may run satisfactorily, but the corresponding debugging tools usually do not. Make sure that both the programming and debugging tools you use are designed for Windows 95.

Some Win16-based and MS-DOS – based disk utilities must be run with special care. In addition, some disk utilities do not perform correctly with long filenames. For more information about using Win16-based and MS-DOS – based disk utilities with Windows 95, see Chapter 20, "Disks and File Systems."

Running TSRs

Some older TSRs rely on MS-DOS interrupts to monitor everything that happens on the system. However, because of its protected-mode file system, Windows 95 doesn't use MS-DOS interrupts. If Windows 95 detects that a TSR is trying to monitor these interrupts, it will accommodate the application and will send all system information through MS-DOS interrupts. This way, the TSR can monitor system events successfully. However, doing this will slow the performance of the operating system significantly.

The IOS.INI file, as described in Chapter 19, "Devices," includes a list of "safe" drivers and applications. If Windows 95 finds the application listed in IOS.INI, it will not send system events through MS-DOS interrupts, thus avoiding slowed performance.

Fixing Version-Checking Errors

If you are using an MS-DOS – based application that was designed for an MS-DOS version other than 7.0 (which is the version that Windows 95 reports), you may receive a message that says you are not using the correct version of MS-DOS. If this is the case, you can add the application to the version table. The version table contains a list of executable files followed by the version number of MS-DOS that the applications were designed to run with.

To display the version table, type setver in a command prompt window. For information about the syntax, parameters, and switches you can use to add an application to the version table, type setver /? at the command prompt.

Windows 95 cannot report the correct MS-DOS version to applications unless the version table is loaded into memory. To load the version table, include a device command in CONFIG.SYS; for example:

device=c:\windows\setver.exe 

If you modify the version table or CONFIG.SYS, restart the computer so the changes can take effect.

Some applications incorrectly check the version number of Windows 95. Incorrect version-checking techniques sometimes invert the two bytes that record the version number; thus, version 3.10 would be reported as 10.3. Windows 95 tries to accommodate this possible version-checking error by reporting 3.95 as the version. This way, if an application looks for a version greater than 3.10 or its inverse, 10.3, the new Windows 95 version will prove to be greater.

If the application looks for an exact match for the version number, such as Windows version 3.10, it may not run under Windows 95. To resolve this problem, add the following line to the [Compatibility] section of the WIN.INI file:

compiled_module_name=0x00200000

To determine the compiled module name, right-click an executable file in Windows Explorer, and then click Quick View. The Module Name line provides this information. After you have obtained the module name, the section you add to the WIN.INI file should look similar to this entry for cc:Mail™:

[Compatibility]
CCMAIL=0x00200000

Windows 95 Setup adds entries to the WIN.INI file for many applications that are known to have this problem.

Note: Do not add a permanent entry to WIN.INI for an installation application. Install your application first, and then edit the compiled module name in WIN.INI.

If a setup application incorrectly detects the version of Windows 95, you may be unable to install the application. In this case, add an entry to the [Compatibility] section of WIN.INI for the setup application (for example, SETUP=0x00200000). Install the application, and then immediately remove the section that you added to WIN.INI.

Running Applications That Replace System DLLs

Some setup applications do not check the version of the system files they are installing and overwrite the newer Windows 95 versions of those DLLs. Windows 95 restores its original DLLs after every setup application runs and for the first three startups thereafter. If an application stops running or behaves erratically after you install it, you may need to obtain an updated version of the application that does not overwrite Windows 95 system files.

Earlier versions of Windows allowed applications to redistribute parts of the system with no ill effects. For example, an application might overwrite a system file with no adverse consequences.

In Windows 95, multiple system files have been consolidated to expedite the startup process. If an application tries to overwrite a system file that is no longer used, Windows allows the application to copy the file, but does not use it.

If your application must run with a replacement file, you can add that file to the Windows SYSTEM\VMM32 directory (which is initially empty after you set up Windows 95).

After you install an application, Windows 95 checks for files that are commonly overwritten by setup applications. If any are found, a dialog box appears, enabling you to restore the files from the hidden Windows SYSBCKUP directory.

Troubleshooting Applications

Hot keys fail to start applications.

In Windows 95, you cannot use hot keys to run applications located on the desktop. You can use hot keys to run only those applications located in the Applications folder. To start an application that is located on the desktop, double-click its icon.

If you cannot create a shortcut.

If you try to add an application to the Start menu by dragging the application's icon to the Start button, you may receive a message that says that you cannot create a shortcut. The message prompts you to place the shortcut on the desktop. This message appears if the Start Menu directory is corrupted or deleted.

To repair a corrupted or missing Start Menu directory

1. Click the Start button, and then click Shut Down.

2. Click Restart The Computer.

   This creates a new Start Menu folder. If you continue to receive an error message when dragging items to the Start button, delete the Start Menu directory in My Computer or Windows Explorer, and then repeat this procedure.

.LNK extensions are never displayed.

Windows 95 never displays the .LNK extension, even if you choose Show All Files on the View tab of the Options dialog box in My Computer or Windows Explorer.

A disk utility cannot write to a disk.

Windows 95 does not support MS-DOS – based or Windows 3.1 – based utilities that perform direct disk writes. Direct disk writes using the MS-DOS read sector (INT 26h) or absolute read sector (INT 13h) interfaces will fail unless the application has locked the volume for exclusive use. For information, see Chapter 20, "Disks and File Systems."

You can't print from an application.

If you cannot print from an application, you can bypass spooling by sending printer output to a file and then dragging that file to a printer. For information about printing to a file, see Chapter 23, "Printing and Fonts."

The taskbar is hidden.

Whenever you maximize an application, Windows 95 resizes the window so it does not cover the taskbar. However, if an application maximizes itself by using screen metrics to resize its window to take up the entire screen, the taskbar may be obscured. Because this type of application commonly has problems with the taskbar, Windows 95 hides the taskbar when this occurs, giving the application the entire screen. To display the taskbar, manually resize the application's window or minimize the application. To display the Start menu, press CTRL+ESC.

An application on a compressed drive lacks enough memory to run.

Applications that require maximum available conventional memory should not be run on compressed drives. You might need to run such applications in MS-DOS Mode.

Running an MS-DOS-based application causes Windows 95 to stall during startup.

To restore Windows 95, shut down and restart the computer, and then press F8 when the Starting Windows 95 message appears. In the Windows 95 Startup menu, select the option named Previous Version of MS-DOS. (This option does not appear unless you edit the MSDOS.SYS file, as described in Chapter 6, "Setup Technical Discussion.") Remove the following lines in AUTOEXEC.BAT by typing REM before them:

REM cd c:\windows\command
REM call c:\windows\command\<game.exe>
REM c:\windows\win.com/wx

Remove the following line in CONFIG.SYS by typing REM:

REM DOS=SINGLE

Text on menus and other screen elements is truncated.

Applications that depend on the system font to be a certain size may truncate the text on menus and other screen elements if the text is larger than the default setting. This may occur if users customize their screen fonts. To resolve this problem, right-click the desktop, and then click Properties. Click the Appearance tab, and then, in the Scheme list, click Windows Standard.

Strange colors and patterns appear on the desktop.

Some Windows 3.1 applications hook into the desktop so they can be aware of all the events that take place there. When all applications were minimized in Windows 3.1, the desktop was the background area. In Windows 95, however, the background area is always covered by the new Windows 95 shell. Applications that subclass the old desktop no longer monitor any activity. If such applications attempt to draw on the old background, images will appear on the new desktop, but they will conflict with images that the Windows 95 interface draws there. Users will be unable to interact with the images such applications draw.

This problem typically occurs with screen background/wallpaper applications and with replacement user interfaces, typically located in the StartUp folder. These types of applications may also be started by run= or load= lines in WIN.INI.

To resolve this problem, remove the application from the StartUp folder or remove its entry in the WIN.INI file. Or obtain a version of the application designed for Windows 95.

Setup program cannot create shortcuts.

Because of cooperative multitasking in Windows 3.1, Program Manager was always guaranteed to respond within a few seconds of a DDE message. For that reason, many setup applications set the DDE timeout to a very short interval. In some cases, Windows 95 may be unable to process the DDE request in the same time period due to preemptive multitasking. Setup applications may be unable to create an application group or shortcuts for this reason. If this occurs, you can manually add folders and shortcuts to the Programs menu. For more information, see online Help.

If you need to rebuild the Programs menu.

If Windows components are inadvertently deleted from the Programs menu, you can rebuild the menu. When you do, Windows 95 searches for installed components and adds shortcuts for them to the Programs menu. Before you rebuild the Programs menu, you must rename the setup.old file to setup.ini file. To rebuild the Programs menu, click the Start button, click Run, and then type grpconv -s in the Open box**.**

For information about manually rebuilding the Programs menu, see online Help. For more information about grpconv, see Chapter 6, "Setup Technical Discussion."

If you need to save a Notepad or WordPad file using an unassociated filename extension.

If you are saving a file in Notepad or WordPad and you specify a filename extension that has not been associated with an application, Notepad or WordPad will append the default filename extension to the end of the filename. Notepad uses the extension .TXT, and WordPad uses the extension .DOC.

To save a file using a filename extension that is not in the Registry, enclose the filename in quotation marks.