Chapter 25 - Application Support

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.

This chapter describes how to optimize support for applications in Microsoft Windows 98 using the new Distributed Component Object Model (Distributed COM). It also describes support and issues for using Win32-based, Win16-based, and MS-DOS-based applications.

See Also

  • For more information about setup, see Chapter 5, "Setup Technical Discussion." 

  • For more information about performance tuning, see Chapter 26, "Performance Tuning." 

  • For more information about the registry, see Chapter 31, "Windows 98 Registry." 

  • For more information about the Apps.inf file, see Appendix C, "Windows 98 INF Files." 

Overview of Application Support in Windows 98

Cc768195.spacer(en-us,TechNet.10).gif Cc768195.spacer(en-us,TechNet.10).gif

Windows 98 optimizes the performance of applications written for it, as well as existing applications created for MS-DOS and previous versions of Windows. Applications perform more smoothly than with MS-DOS, Windows for Workgroups, Windows 3.1, or Windows 95, because Windows 98 significantly increases system resources available to them and more efficiently manages how they use system memory.

Windows 98 also supports new and existing versions of COM technology, including ActiveX Controls and Automation for new Windows-based applications. It also supports other Web authoring technologies such as Dynamic Hypertext Markup Language (HTML) and JavaScript. For more information about ActiveX, Dynamic HTML, and JavaScript, see Chapter 20, "Internet Access and Tools." Finally, Windows 98 now supports the Distributed Component Object Model, which lets application components work with each other across a network or across the Internet.

Windows 98 offers the following general improvements in application support:

Distributed computing with the Distributed Component Object Model. New for Windows 98, Distributed COM extends the COM infrastructure to allow components of a distributed application to communicate over a network. Users can access and share information without needing to know the location of an application's components.

Increased system resources and other optimizations. Windows 98 increases system resources for all applications by using 32-bit heaps to store application data structures, making more resources available for the remaining data elements than with MS-DOS, Windows 3.1, or Windows for Workgroups. In addition, Windows 98 increases the number of timers, COM and LPT ports, Windows menu handles, and other resources available to applications.

Windows 98 also includes performance enhancements, such as a change to binaries and a change to Disk Defragmenter, that make applications run faster. For more information, see Chapter 26, "Performance Tuning." See also Chapter 10, "Disks and File Systems."

Improved memory management. The Virtual Machine Manager, an integral part of the Windows 98 architecture, manages the memory required by each application. A virtual machine (VM) is an environment in memory that functions like 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 28, "Windows 98 Architecture."

Distributed Component Object Mode

The Distributed Component Object Model (Distributed COM) extends the Component Object Model (COM) to allow components of a distributed application to communicate over the network securely and transparently. Your existing COM applications can use Distributed COM without any modifications to the application code. Distributed COM provides the infrastructure for creating applications as a system of software objects (for example, sorting functions or database searches) designed to be reusable and replaceable.

In a corporate environment, Distributed COM lets application developers break down an application into a multitier design using smaller components that can communicate directly with each other across computers. Application developers can update a single component without having to recompile the entire application.

For example, as shown in Figure 25.1, your company might deploy a distributed order entry application that uses individual components for sales tax calculations, with each component designed for a different geographic sales region. Each of these sales channel components uses the same inventory component located on a network server. As the inventory changes, you can change the inventory component without having to rewrite and recompile the sales tax components for each of the sales regions.

Cc768195.wrkii01(en-us,TechNet.10).gif

Figure 25.1 Overview of distributed applications using Distributed COM 

Distributed COM is particularly powerful for component applications running across computers for the following reasons:

Distributed COM is transport-neutral. Components can communicate with each other over any network transport. In Windows 98, Distributed COM supports Transmission Control Protocol/Internet Protocol (TCP/IP).

Distributed COM is language-neutral. ActiveX controls, Java applets, and components written in many languages (such as Microsoft Visual Basic, Microsoft Visual C++®, or even COBOL or Pascal) can communicate with each other through COM.

Distributed COM is platform-independent. Distributed COM runs on Windows 98, Windows NT, UNIX, and legacy operating systems, providing a common application infrastructure across a company's entire information systems environment.

Distributed COM is based on open standards. Distributed COM uses the Open Group distributed computing environment (DCE) remote procedure call (RPC) mechanism for communication between clients and servers across the network.

For procedures on how to configure applications and establish permissions for using Distributed COM, see "Distributing Applications Across a Network" later in this chapter.

For schematic and detailed information about Distributed COM, see "Technical Notes," later in this chapter.

For more information about COM, go to https://www.microsoft.com/com/ .

Win32-based Applications

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

To get the best possible performance, use versions of applications designed for Windows 98 whenever possible. Applications written specifically for Windows 98 carry the "Designed for Microsoft Windows NT Windows 98" logo. To qualify for the logo, applications must meet the requirements outlined on the Microsoft Developer Network (MSDN) Web site at https://msdn.microsoft.com/** **. Windows 98 includes new requirements in areas such as power management, assumed hard disk size limitations, digital signing, and installation.

Win16-based Applications

Win16-based applications designed for Windows 3.1 run under Windows 98 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 98 subsystem. For Win16-based applications that are known to need special parameters to run, Windows 98 includes an Apps.inf file that defines parameters for each application.

Because of default settings and other support in Windows 98, you do not need Config.sys, Autoexec.bat, and INI files to run Win16-based applications, although you can still use settings from existing files. When you upgrade by replacing Windows 3.1 with Windows 98, Windows automatically moves the current settings for your installed applications to the registry for use with Windows 98.

In general, Windows 98 does not allow you to specify a working directory in the properties sheet of a Win16-based application. (This is true for Win32-based applications as well.) 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 dialog box for the shortcut.

MS-DOS-based Applications

MS-DOS-based applications can take advantage of the improved memory management and increased system resources that are made possible by the system architecture used in Windows 95 and Windows 98. Most applications can now run in a window. An MS-DOS-based application that does not run well under Windows can run in exclusive MS-DOS mode, which makes all system resources available to that application. For more information, see "Changing Memory Settings" later in this chapter.

For MS-DOS-based applications that need special parameters to run, Windows 98 includes an Apps.inf file that defines parameters for each application. When running under Windows 98, 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 98 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 VMs. 

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

Because of default settings and other support in Windows 98, you do not need Config.sys, Autoexec.bat, and INI files to run MS-DOS-based applications, although you can still use settings from existing files. Windows automatically moves the current settings for your installed applications to the registry when you install Windows 98.

Installing Applications

Cc768195.spacer(en-us,TechNet.10).gif Cc768195.spacer(en-us,TechNet.10).gif

This section describes how to install and remove applications locally or on a network. It also describes how to configure distributed applications across a network using Distributed COM.

Considerations Before Installing Applications

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

  • How will applications perform in your networking environment? After you set up Windows 98 on the network, you will need to install and test how applications perform. For example, for MS-DOS-based applications, 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. 

  • Which applications do you want to share over the network? With Windows 98, most applications can be shared across the network by installing them on a network server and then creating shortcuts to them on the client computers. Users can open them from the network location by double-clicking the shortcuts. For more information, see "Sharing and Installing Applications Across a 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. 

  • Can you use Distributed COM to configure distributed applications for use across a network? For more information, see "Distributing Applications Across a Network" later in this chapter. 

  • Do you want to use software distribution channels to automatically install or update applications? Internet Explorer 4.0 can subscribe to software distribution channels, a special type of Active Channel that updates subscribers' computers at regular intervals. For more information, see Chapter 6, "Configuring the Active Desktop and Active Channels." 

  • Do you want to simplify users' access to applications by customizing the Programs menu or the toolbar? For more information, see Chapter 6, "Configuring the Active Desktop and Active Channels." 

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

  • Which terminate-and-stay-resident (TSR) programs 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 the section titled "Running Logon Scripts with Client for NetWare Networks" in Chapter 18, "Logon, Browsing, and Resource Sharing." 

  • Do you need to restrict users from running MS-DOS-based applications? 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. Or do you want to allow only certain Windows-based applications to run on a computer? For more information about using system policies to restrict access to MS-DOS mode or restrict the applications that can run on a computer, see Chapter 7, "User Profiles," and Chapter 8, "System Policies." 

Installing Applications Locally

How you install and configure an application depends on whether it was created for Windows 95, Windows 3.1, or MS-DOS. This section discusses how to install and configure applications written for each operating system and how to find out whether your application is compatible with Windows 98. For more information about installing and configuring distributed applications across a network using Distributed COM, see "Distributing Applications Across a Network" later in this chapter.

Using Add/Remove Programs with Win32-based Applications

Windows 98 simplifies installing Win32-based applications by providing an Add/Remove Programs option in Control Panel. When you install an application using this option, Windows 98 does the following:

  • Searches specified drives for files named Install or Setup. If an application setup file uses a name other than Install or Setup, you can start setup by double-clicking the application setup file's icon in My Computer. 

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

Keeping Windows 3.1 Settings

If you upgrade by placing Windows 98 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 98 in a separate directory, you must reinstall all Windows-based applications to ensure that they work properly under Windows 98. Copying GRP and INI files from your previous \Windows directory is not sufficient to run applications under Windows 98.

Creating Application Groups and Icons

When a Windows-based setup application creates an application group and icons, Windows 98 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 the section titled "Configuring the Start and Programs Menus" in Chapter 6, "Configuring the Active Desktop and Active Channels."

Installing MS-DOS-based Applications

You generally install an MS-DOS-based application by running its Setup.exe file. When you install the application, Windows 98 copies information about the application from Apps.inf to the application's program information file (PIF). If the application was installed under an earlier version of Windows, Setup automatically moves its settings to the new Apps.inf. If there is no information about the application in Apps.inf, Windows 98 uses default settings instead, or you can manually set the properties, as described in "Configuring MS-DOS-based Applications" later in this chapter.

Note Windows 98 has no separate PIF Editor. To configure an application, right-click its executable file, and then click Properties.

Running Specific Applications

For more information about whether a specific application runs under Windows 98, check the Windows 98 Readme.txt file. If you do not find an application listed in Readme.txt, check with the application's manufacturer or your software vendor. Windows 98 provides a utility that makes an incompatible application compatible with Windows 98. This utility is a file named Mkcompat.exe in the \Windows\System directory. For more information, see "How Windows 98 Accommodates Application Problems" later in this chapter.

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

Sharing and Installing Applications Across a Network

This section describes how to share and install applications over a network. It first explains how to make applications available over a network. It then explains an optional procedure for giving users a master list of available applications.

Sharing Applications

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

You can also install applications over a network by using software distribution channels, a type of Active Channel that updates subscriber's computers at regular intervals. For more information about software distribution channels, see Chapter 6, "Configuring the Active Desktop and Active Channels."

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

  2. Make sure that users can access the network server or workstation. For information about sharing directories on Windows 98 computers, see Chapter 18, "Logon, Browsing, and Resource Sharing." For information about sharing directories on Windows NT–based computers, see the Microsoft Windows NT Server Networking Guide in the Microsoft Windows NT Server Resource Kit (for Microsoft Windows NT Server version 4.0) (ISBN 1-57231-343-9). 

  3. On a client computer, go to Network Neighborhood, right-click and hold down the icon for the application, drag it to the desktop, and then click Create Shortcut.

For more information about creating shortcuts, see online Help. For information about creating and distributing custom shortcuts using system policies, see Chapter 8, "System Policies." For more information about configuring Active Desktop toolbars, see Chapter 6, "Configuring the Active Desktop and Active Channels."

Creating an Apps.ini File

If users will be installing applications from source files stored on a 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 Apps.ini, a new tab named Network Install appears under Add/Remove Programs, in Control Panel. The Network Install tab lists all the applications that appear in the Apps.ini file and that can be installed from the server.

To create an Apps.ini file on a network server
  1. Use a text editor to create a file that contains a list of applications using the following format: 

    [AppInstallList]
    

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 universal naming convention (UNC) names, include an asterisk before it. For example: 

<pre IsFakePre="true" xmlns="https://www.w3.org/1999/xhtml">Microsoft Word 97=*\\applications\forusers\word97\setup.exe
  1. Save Apps.ini on a server to which users have read-only access. 
To display the applications listed in Apps.ini on a client computer's Network Install tab
  1. In the registry on the client computer, click the following key:

    Hkey_Local_Machine/Software/Microsoft/Windows/Current Version 

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

  3. Click String Value, type appinstallpath, and then press ENTER. 

  4. Right-click the item you just created. 

  5. In the Edit menu, click Modify

  6. In the Value Data area, type the UNC path to Apps.ini, including the file name. For example: 

    \\myserver\myshare\apps.ini
    
  1. Click Close

For information about adding registry settings in setup scripts, see Appendix D, "Msbatch.inf Parameters for Setup Scripts." For information about adding registry settings using system policies, see Chapter 8, "System Policies."

Distributing Applications Across a Network

This section describes how to use the Distributed COM Configuration tool to configure clients, servers, and applications. The Distributed COM Configuration tool lets you configure 32-bit COM and Distributed COM distributed applications to run across computers by specifying properties for the distributed application, such as the locations of application components and security for those components.

Cc768195.wrkii02(en-us,TechNet.10).gif

Note Application configuration can also be specified in the application itself. If so, the settings override any settings you choose in the DCOM Configuration tool.

For additional procedures on using the Distributed COM Configuration tool to configure applications, see the Distributed COM Configuration tool's online Help system.

For more information about setting security levels and permissions for Distributed COM applications, see Chapter 9, "Security."

Configuring Distributed COM Clients and Servers

A Distributed COM computer running Windows 98 can be either a client, a server, or both. A client makes calls to a component, and a server gets calls. Thus, if computer A is running an application that calls a component on computer B, computer A is acting as a client and computer B is acting as a server. If the component on computer B also calls a component on computer C, computer B is acting both as a client and as a server.

Using the Distributed COM Configuration tool, you can configure your computer as a client, a server, or both. By default, your computer is configured as a client but not as a server. Before you can use dcomcnfg your computer must be configured for user-level security. For more information, see Chapter 18, "Logon, Browsing, and Resource Sharing."

To configure your computer as a DCOM client and server
  1. On the Start menu, click Run, and then in the Open box, type dcomcnfg

  2. Click the Default Properties tab, and then select the Enable Distributed COM on this computer check box if it is not already selected. By default, this box is selected. 

  3. If you also want to configure your computer as a Distributed COM server (you want to receive calls from other computers), click the Default Security tab, and then select the Enable Remote Connection check box. 

Setting Authentication Levels

You can configure the client computer to use authentication when a connection is made to the server. You can also configure the server to use authentication when a connection is made to a server. If either the client or the server requests authentication, both will need to use authentication.

It is highly recommended that you configure your computer to use authentication if it will be used as a server. Otherwise, client computers can call the server without being authenticated.

If your computer is not part of a Windows NT domain and has no access to Windows NT domain security, authentication will fail. If either the client or the server request authentication, the connection will fail. Thus, if you are certain that your computer is a client and not a server, and your computer is not part of a Windows NT domain, you might want to set that computer not to use authentication. However, even if you do so, the connection will fail if the server requests authentication.

If your computer is a server and is part of a Windows NT domain, but it is configured to use share-level security, a secure connection will fail. In that case, you might want to set your computer to use user-level security. For more information about user-level security, see Chapter 9, "Security" and Chapter 18, "Logon, Browsing, and Resource Sharing."

Before you can use dcomcnfg your computer must be configured for user-level security. For more information, see Chapter 18, "Logon, Browsing, and Resource Sharing."

To set authentication on communications between applications

  1. On the Start menu, click Run, and then in the Open box, type dcomcnfg

    Click the Default Properties tab, and then in the Default Authentication Level box, select the security level you want:

    • To disable security checking on communications between applications, select (None). 

    • To enable security checking for the initial connection, select Connect

Setting Impersonation Levels

With impersonation, one process can take on the security attributes of another process. For example, a server process can impersonate a client process to complete a task involving objects to which the server does not normally have access. The server application can impersonate the client application only on the computer running the server application.

You can set impersonation levels for a Distributed COM application on a Windows 98 Distributed COM client, enabling Windows NT Distributed COM servers to impersonate the client.

In most cases, the default settings are correct. However, if you want to change the impersonation level, see online Help.

Setting the Location for Distributed COM Applications

The first step in configuring an application for Distributed COM is to specify the location of the server application that will be accessed by the computer running the client application. You do this on the computer running the client application. Before you can use dcomcnfg your computer must be configured for user-level security. For more information, see Chapter 18, "Logon, Browsing, and Resource Sharing."

To set the location of a Distributed COM application
  1. On the Start menu, click Run, and then in the Open box, type dcomcnfg

  2. Click the Applications tab, click the application that you want to configure, and then click Properties

  3. Click the Location tab, and then specify where you want to run the server application. 

Configuring User Accounts to Access Distributed Applications with Distributed COM

You can create an access control list that specifies the user accounts that will have permission to have access to or start applications, on either the server or the application, or both. Before a component can run, Distributed COM validates the user name using whatever authentication mechanism is configured and checks the user name against the access control list. The permissions you can set depend on the server's operating system:

  • If the server is running Windows NT, you can set both access and start permissions. 

  • If the server is running Windows 98, you can set only access permissions. The server must have user-level security installed and must be using Windows NT domain security. 

Note If you set custom permissions for a Distributed COM application, the custom permissions will override any default permissions that have been set for all applications.

For information about how to use the Distributed COM Configuration tool to configure users and permissions, see online Help.

Starting Distributed COM–enabled Applications

The extent to which a Distributed COM client computer running Windows 98 can start or access a Distributed COM–enabled application on a server depends on the server's operating system:

  • If the server is running Windows NT, the client can start or access the server application. 

  • If the server is running Windows 98, the client cannot start the server application. The server application must be started manually on the server, and then the client can access it. 

Removing Applications

If you installed applications through Add/Remove Programs in Control Panel, you can safely remove them in the same way. Because the application's components are tracked through the registry, Windows 98 deletes all of the application's files unless those files are being used by another application. Shared files are retained on the hard disk. You see a prompt if you try to remove a shared file.

Removing a Win16-based or MS-DOS-based application is not always straightforward. You can delete the directory that contains the application, but additional files belonging to the application (especially in a Win16-based 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.

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 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 dynamic-link libraries (DLLs) and other essential system files, in case you need to restore them.

Configuring Applications

Cc768195.spacer(en-us,TechNet.10).gifCc768195.spacer(en-us,TechNet.10).gif

This section describes how to optimize access to applications by configuring elements of the Active Desktop. It also discusses how to associate specific file types with applications and how to optimize the performance of MS-DOS-based applications.

Associating File Types with Applications

To open an application when you double-click a related 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 applications.

For any standard Windows-based application, file types are automatically associated with the application when you install the application on your computer. You can use the following procedure to associate a file type with a different application. For example, if you wanted to make Internet Explorer open all GIF files, you could use this procedure to associate Internet Explorer with GIF files.

To associate a file type with an application
  1. In My Computer or Windows Explorer, click View, and then click Folder Options

  2. Click the File Types tab. 

  3. Click the type of file that you want to associate, 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 or browse the path to the application you want to associate 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 either a .doc or an .rtf extension. This can cause problems if a user wants to change which application opens a particular file. To re-associate a file type with an application under these conditions, follow the preceding procedure to delete all extensions registered to that application on the File Types tab, and then re-associate each file type with an application. In addition, you must redefine Open, Print, and Dynamic Data Exchange (DDE) actions for each file type.

Customizing the New Shortcut Menu

The New shortcut menu shows a list of options, such as Folder, Shortcut, Text Document, and Microsoft Word Document. It appears when you click File and then point to New in Windows Explorer, or when you right-click the Active Desktop and then point to New on the shortcut menu. Clicking an object on the New shortcut menu creates that 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 file name extension:

Hkey_Classes_Root.ext 

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

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

Customizing the Active Desktop for Applications

The Windows 98 Active Desktop lets you simplify a user's access to applications by customizing the Active Desktop Start and Programs menus. You can also create new toolbars containing only the applications and documents that you use most often.

You can also customize many other Active Desktop elements, such as channel bars, folders, and Active Desktop items. For more information about customizing the Active Desktop, see Chapter 6, "Configuring the Active Desktop and Active Channels."

Note Windows 98 adds your most recently used documents to Documents on the Start menu. However, documents opened in an application that is not Win32-based do not appear. Win16-based documents are added to the list only if you double-click the document's icon in Windows Explorer or My Computer.

Configuring MS-DOS-based Applications

Windows 98 configures conventional memory as do earlier versions of Windows, allowing MS-DOS-based applications to run smoothly in Windows 98. For more information about how Windows 98 makes system memory available to MS-DOS-based applications, see Chapter 26, "Performance Tuning."

Understanding the Apps.inf File

The Apps.inf file in Windows 98 (in the \Windows\Inf directory) 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. Table 25.1 explains these entries.

Each entry in the [PIF95] section uses the following syntax:

app file=%title%, icon file, icon num, set working, section, other file, set pif 

Table 25.1 Syntax of [PIF95] entries in Apps.inf 

Entry

Meaning

app file

The file name, 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 Windows 98 to set the working directory automatically 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.

Following the [PIF95] section are sections for each application listed in [PIF95]. Each application section includes entries that define any parameters, required memory or other options, and options that can be enabled or disabled for that application. For example:

[WORD.EXE]
LowMem=384
Enable=cwe
Disable=win,bgd,asp

The Enable= and Disable= entries use the abbreviations shown in Table 25.2. To separate multiple entries, use commas.

Table 25.2 Abbreviations used in Enable= and Disable= [PIF95] entries in Apps.inf 

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

Changing PIF Files

In addition to the information contained in the Apps.inf file, 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 to reset default properties used by Windows 98 that do not work correctly.

An application's settings are recorded in its program information file (PIF). Windows 98 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.

Windows 98 first searches for a PIF file in the directory that contains the executable file you are starting. If Windows 98 cannot find a PIF file there, it searches the \Windows\PIF directory. If there is no PIF file in the \Windows\PIF directory, Windows 98 searches the path specified in Autoexec.bat. If no PIF file is found, Windows 98 searches the Apps.inf file for a match.

If Windows 98 does not find an entry for an application in Apps.inf, it uses default settings for the application. If you replace Windows 3.1 with Windows 98, a _default.pif file remains in the directory. In this case, Windows 98 uses information in the _default.pif file to create a PIF file for the application.

If you do not have a _default.pif file and want to create one, you can do so by copying 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.

Changing Memory Settings

Windows 98 provides a flexible environment for running MS-DOS-based applications, even those that must have exclusive access to system resources. Almost all MS-DOS-based applications should run under Windows 98. For MS-DOS-based applications that need sole access to computer resources, Windows 98 offers MS-DOS mode.

When an MS-DOS-based application starts in MS-DOS mode, Windows 98 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 98 ends all running tasks, loads a real-mode copy of MS-DOS, and uses customized versions of Config.sys and Autoexec.bat to run the application. After you quit the MS-DOS-based application, Windows 98 restarts and returns to the Windows 98 user interface.

MS-DOS mode is intended for applications that will not otherwise run in Windows 98. It does not necessarily improve the performance of MS-DOS-based applications that will run in Windows 98.

To configure an MS-DOS-based application to run in MS-DOS mode
  1. Right-click the icon for the application, and then click Properties

  2. Click the Program tab, and then click Advanced

  3. In the Advanced Program Settings dialog box, select the MS-DOS mode check box. 

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 Config.sys and Autoexec.bat. 

To adjust the amount of memory available to an MS-DOS-based application
  1. Right-click the icon for the application, and then click Properties

  2. Click the Memory tab, and then increase or decrease the amount of memory available to the application. 

The following procedure describes how to create a custom PIF file for an MS-DOS-based application. Windows 98 includes two sample PIF files in the \Windows directory.

To create a custom startup configuration for an MS-DOS-based application
  1. Right-click the icon for the application, and then click Properties

  2. Click the Program tab, and then click Advanced

  3. In the Advanced Program Settings dialog box, select the MS-DOS mode check box, and then click Specify a new MS-DOS configuration

  4. Specify any custom startup instructions in the Config.sys for MS-DOS mode and Autoexec.bat for MS-DOS mode boxes. 

  5. If you want to enable or disable additional options, such as expanded memory specification (EMS) or Direct Disk Access, click Configuration, and then select the options you want to enable for your custom configuration. 

Note Windows 98 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 98 to create an EMS page frame.

Setting Properties

In Windows 98, the properties sheets replace PIF Editor, which was used in versions of Windows earlier than Windows 95 to optimize settings for MS-DOS-based applications.

To view or modify the properties settings for an MS-DOS-based application
  1. Right-click the icon for the application, and then click Properties

  2. Click the tab you want to use, and change the options as appropriate. 

For specific information about the options on each tab of the Properties dialog box, click the Quick Help button in the upper right of the tab, and then click the option you want to learn more about.

Setting Paths

You can set the path for a specific MS-DOS-based application that runs in MS-DOS mode using the following procedure.

To specify a path for an MS-DOS-based application that runs in MS-DOS mode
  1. Right-click the icon for the application, and then click Properties

  2. Click the Program tab, and then click Advanced

  3. In the Advanced Program Settings dialog box, select the MS-DOS mode check box, and then click Specify a new MS-DOS configuration

  4. In the Autoexec.bat for MS-DOS mode box, 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 dialog box, click the Programs tab. 

  2. In the Batch file box, type 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, select the Close on exit check box. 

Running Games

In most cases, MS-DOS-based games run under Windows 98 with no special adjustments. Most popular games are listed in the Windows 98 Apps.inf file. You do not need to specify certain PIF settings because Windows 98 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 98 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 its executable file, and then click Properties. Click the Screen tab, and then in the Usage area, click Full-screen. You can also use the Properties dialog box to adjust other settings that improve performance.

Using Applications

Cc768195.spacer(en-us,TechNet.10).gifCc768195.spacer(en-us,TechNet.10).gif

This section describes how to start applications and how you can use object linking and embedding (OLE) to share data between applications. It also discusses what to do when an application fails.

Starting Applications

There are several ways to start applications in Windows 98:

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

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

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

  • If the application has a shortcut on the desktop, double-click the application's shortcut icon. 

  • If the application has an icon on the QuickLaunch toolbar or on a custom toolbar, double-click the application's icon. 

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

Tip Instead of starting a Windows-based application to see the contents of a document, you can use the Windows Explorer Quick View option. You must first install Quick View using Add/Remove Programs in Control Panel. To use Quick View, in Windows Explorer, right-click the document you want to look at, and then click Quick View on the shortcut menu. This opens a Quick View window of the document. If you want to open the document, click File in the Quick View window, and then click Open File for Editing. For more information, see online Help.

Using Object Linking and Embedding to Share Data Between Applications

Windows 98 includes built-in object linking and embedding (OLE) functionality that enables you to share data between OLE-compliant applications. Using applications that take advantage of OLE technology, you can create compound 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 version 2.0 is a technology built into Windows 98 that improves on the OLE version 1.0 standard. It provides services for sharing OLE objects (units of data) and the related functions needed to manipulate that data.

As Figure 25.2 shows, OLE technology provides a way of communicating between container applications and object applications. Container applications maintain compound 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 compound document. The container application does not need any information about the object application or its data type to communicate with it.

Cc768195.wrkii04(en-us,TechNet.10).gif

Figure 25.2 OLE objects in applications 

Windows 98 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.8" is the application identifier for a Word 8.0 document.

Note With ClipBook Viewer, an OLE application that is located in the \Add-ons\Clipbook directory on the Windows 98 compact disc, 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 make visual editing possible, both the container application and the object application must be OLE-compliant and must support the OLE visual editing interface. This interface is a feature of Windows 98 OLE and is not supported by OLE 1.0. If either application meets only the OLE 1.0 specification, the object application will be launched in a separate window for editing. For example, Corel Draw version 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 from a Word document, the Corel Draw 4.0 application will start in its own window.

Note OLE version 2.0 applications that do not support visual editing also open in separate windows.

If an embedded object has a file name extension that is not associated with any application, you may not be able to activate it successfully. You must first associate the file type with an application. For more information about associating file types with applications, see "Associating File Types with Applications" earlier in this chapter.

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

Table 25.3 Key combinations used for moving and copying objects 

Mouse Action

Result

Drag and drop

Moves the object unless the source and target applications have the same data type, in which case the information is merely placed as native data.

SHIFT+drag and drop

Moves the object.

CTRL+drag and drop

Copies the object.

SHIFT+CTRL+drag and drop

Links the object from the source to the container.

Closing Failed Applications

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 by pressing CTRL+ALT+DEL.

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. For more information about restarting or shutting down a computer, see online Help.

Technical Notes

Cc768195.spacer(en-us,TechNet.10).gifCc768195.spacer(en-us,TechNet.10).gif

This section summarizes technical information about running applications under Windows 98. For more information about the supporting system components, see Chapter 28, "Windows 98 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 98 changes the system configuration files, as described in Chapter 5, "Setup Technical Discussion." The following changes affect application support:

  • If no files= line is specified in Config.sys, Windows 98 uses a setting of 60. 

  • Many application settings have moved from INI files to the registry. If you install an application after Windows 98 has been installed, and the setup application writes directly to Win.ini and System.ini instead of using documented functions, Windows 98 does not recognize those changes. To resolve this problem, obtain a version of the application designed for Windows 98 or Windows 95. 

  • Windows 98 enables file sharing by default. Therefore, it is no longer necessary to add Share.exe to Autoexec.bat or Vshare to System.ini. However, some applications check for the existence of Share.exe. To work around this problem, create a dummy file called Share.exe in your \Windows\Command directory. Depending on the application, you might also need to add a line to Autoexec.bat referring to the dummy Share.exe file. To do so, follow the procedure below: 

To create a dummy Share.exe file
  1. At the command prompt, go to the \Windows\Command directory and type Copy con share.exe

  2. Press ENTER at least twice. 

  3. Press CTRL+Z, and then press ENTER again. A dummy file called Share.exe is created. 

Distributed Component Object Model

The Distributed Component Object Model (Distributed COM) is based on the COM standard. With COM, an object can have multiple interfaces (the set of methods and properties the object supports). When an application accesses a COM object, it always uses an interface pointer. As a result, the calling application does not need to know the location of the object or how it is implemented. Also, developers can modify the implementation of COM interfaces — or add support for additional interfaces to your components — without rebuilding the client applications that use them.

COM also provides location transparency. All method calls on objects are similar to in-process function calls. The operating system handles all the details of making the call across processes.

As Figure 25.3 shows, Distributed COM extends COM to make the call across computers and to add security mechanisms. An application does not need to know the details of local or remote procedure calls (RPCs).

Cc768195.wrkii14(en-us,TechNet.10).gif

Figure 25.3 Distributed COM schematic overview 

Win32-based Applications

Applications that use Win32 application programming interfaces (APIs) can take full advantage of all Windows 98 performance enhancement features. Win32-based applications can utilize multitasking, Win32 APIs, long file name 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. In addition, you can manage files from the Open dialog box in Win32-based applications.

To support preemptive multitasking, the Windows 98 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. As Figure 25.4 shows, each Win32-based application has its own message queue and, consequently, is not affected by how other tasks access message queues.

Cc768195.wrkii15(en-us,TechNet.10).gif

Figure 25.4 Message queues in Windows 98 

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 Program dialog box, and then close the unresponsive application without affecting other running tasks.

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

  • Be Win32-based. 

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

  • Use RPCs for networked NetBIOS applications. 

  • Use Windows Sockets for networked non-NetBIOS applications. 

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

Win16-based Applications

Win16-based applications designed for Windows 3.1 run under Windows 98 without modification. Windows 98 ensures that Win16-based applications running on a computer with 16 MB or memory or more perform as well as—or better than—they did under Windows 3.1. In addition, the performance of Win16-based applications is improved, because they can use operating system services provided by the 32-bit system components of Windows 98, including 32-bit device driver components and 32-bit subsystems.

Windows 98 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 as well as common input and message queues, 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 98 system kernel.

Because all Win16-based applications run in the same VM, an errant application can cause other Win16-based applications to fail, but it should not 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. Improved cleanup of the system lessens the likelihood of application errors. Windows 98 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 Program dialog box, and then close the unresponsive application without affecting other running tasks.

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

MS-DOS-based Applications

Windows 98 support for MS-DOS-based applications includes better printing support and improved capabilities for running hardware-intensive applications, such as games.

Each MS-DOS-based application runs in its own VM, allowing 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 versions of Windows earlier than Windows 95 was insufficient conventional memory space. By the time MS-DOS-based device drivers, TSR applications, and networking components were loaded with Windows, there often was not enough conventional memory left to allow the MS-DOS-based application to load or run. Windows 98 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 savings in memory with protected-mode components can be significant. For example, a computer using only Windows 98 protected-mode components would save more than 225 KB 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 98 Accommodates Application Problems

Some Windows-based and MS-DOS-based applications may not run well under Windows 98 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 98 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 98. Others do not handle long file names well, or they incorrectly check for the operating system's version number.

Windows 98 provides the Make Compatible utility to make compatible an application that is initially incompatible with Windows 98. You can use this utility to troubleshoot if you have trouble printing from an application, or if an application stalls or has other performance problems. This utility provides the means to increase stack memory to an application, emulate earlier versions of Windows, and solve other common problems that cause an application not to run with Windows 98. For more information, see online Help.

To run the Make Compatible utility
  • Click the Start button, click Run, and then type mkcompat.exe

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

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 file names. For more information about using Win16-based and MS-DOS-based disk utilities with Windows 98, see Chapter 10, "Disks and File Systems."

Running Terminate-and-Stay-Resident Programs

Some older terminate-and-stay-resident programs (TSRs) rely on MS-DOS interrupts to monitor everything that happens on the system. However, because of its protected-mode file system, Windows 98 does not use MS-DOS interrupts. If Windows 98 detects that a TSR is trying to monitor these interrupts, it will accommodate the application and send all system information through MS-DOS interrupts. In this way, the TSR can monitor system events successfully. However, doing this will significantly slow the performance of the operating system.

Ios.ini, as described in Chapter 24, "Device Management," includes a list of "safe" drivers and applications. If Windows 98 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.1 (which is the version that Windows 98 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 with which the applications were designed to run. Windows 98 cannot report the correct MS-DOS version to applications unless the version table is loaded into memory.

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, add the question mark (?) switch to the command (that is, type setver /? at the command prompt).

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 98. 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 98 tries to accommodate this possible version-checking error by reporting 3.98 as the version. In this way, if an application looks for a version greater than 3.10 or its inverse, 10.3, the new Windows 98 version proves 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 98. To resolve this problem, add the following line to the [Compatibility] section of Win.ini:

compiled_module_name=0x00200000

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

[Compatibility]
CCMAIL=0x00200000

Windows 98 Setup adds entries to Win.ini 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 98, you may not be able 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.

Some setup applications do not check the version of the system files they are installing and overwrite the newer Windows 98 versions of those dynamic-link libraries (DLLs). Windows 98 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 98 system files.

Versions of Windows earlier than Windows 95 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 98, 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 98).

After you install an application, Windows 98 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.

Windows 98 includes a new utility, System File Checker, that checks for replaced system files. For information, see Chapter 27, "General Troubleshooting."

Troubleshooting Applications

Cc768195.spacer(en-us,TechNet.10).gifCc768195.spacer(en-us,TechNet.10).gif

This section describes some problems that might occur with applications on Windows 98. For information about specific applications, see the Relnotes.txt file included on the Windows 98 compact disc.

Hot keys fail to start applications. 

In Windows 98, 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 located on the desktop, double-click its icon.

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.

    This creates a new Start Menu folder.

.Lnk extensions are never displayed. 

Windows 98 never displays the .lnk extension in My Computer or Windows Explorer.

A disk utility cannot write to a disk. 

Windows 98 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 10, "Disks and File Systems."

You cannot 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 more information about printing to a file, see Chapter 11, "Printing, Imaging, and Fonts."

The taskbar is hidden. 

Whenever you maximize an application, Windows 98 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 such an application commonly has problems with the taskbar, Windows 98 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 sufficient 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 98 to stall during startup.

To restore Windows 98, shut down and restart the computer, and then hold down the CTRL key until the Microsoft Windows 98 Startup Menu appears. In the Microsoft Windows 98 Startup Menu, select the option named Previous Version of MS-DOS. (This option does not appear unless you edit Msdos.sys, as described in Chapter 5, "Setup Technical Discussion.") Disable 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; 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 98, however, the background area is always covered by the new Windows 98 shell. Applications that subclass the old desktop no longer monitor any activity. If such applications attempt to draw on the old background, images appear on the new desktop, but they conflict with images that the Windows 98 interface draws there. Users cannot interact with the images such applications draw.

This problem typically occurs with screen background and 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 Win.ini. Or obtain a version of the application designed for Windows 98.

A 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 Dynamic Data Exchange (DDE) message. For that reason, many setup applications set the DDE timeout to a very short interval. In some cases, Windows 98 may be unable to process the DDE request within the same time because of 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.

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 98 searches for installed components and adds shortcuts for them to the Programs menu. To rebuild the Programs menu, first rename Setup.old to Setup.ini. Then click the Start button, click Run, and type grpconv -s in the Open box.

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

You need to save a Notepad or WordPad file using an unassociated file name extension. 

If you are saving a file in Notepad or WordPad and you specify a file name extension that has not been associated with an application, Notepad or WordPad appends the default file name extension to the end of the file name. Notepad uses the extension .txt, and WordPad uses the extension .doc. For example, if you try to save the file "Cat.foo" in Notepad, Notepad saves it as "Cat.foo.txt."

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

An application requires Share.exe. 

Windows 98 no longer supports real-mode MS-DOS Share.exe. However, some applications check for the existence of a file named Share.exe. To work around this problem, create a dummy file named Share.exe in the \Windows\Command directory.

For more information, see "System Changes Affecting Application Support," earlier in this chapter.

You are using Distributed COM and see run-time error 429. 

Occasionally, when you attempt to access a Distributed COM server from a remote client application, you may see the following error:

Run-time error '429':
ActiveX component can't create object

If this happens, run dcomcnfg to check the following:

  • In the application's properties, make sure that the Run application on this computer setting is checked. 

  • In the application's properties, make sure that the correct server is specified. 

  • In the Default Security tab, make sure that Enable Remote Connection is selected. 

Also, make sure that the server application is started before the Windows 98 client tries to access it.

For more information about this troubleshooting step, see Knowledge Base Article 177394, "HOWTO: Troubleshoot Run-Time Error '429' in DCOM Applications."

Additional Resources 

For more information about

See this resource

COM and Distributed COM

https://www.microsoft.com/com/ 

Designed for Windows NT Windows 98 logo usage qualification

https://msdn.microsoft.com/ 

Sharing directories on Windows NT – based computers

Microsoft Windows NT Server Networking Guide in the Microsoft Windows NT Server Resource Kit (for Microsoft Windows NT Server version 4.0)

Cc768195.spacer(en-us,TechNet.10).gif