Installing Applications

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

Install an application on a network server or workstation, as described in the documentation from the vendor.
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).
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

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:
```
Microsoft Word 97=*\\applications\forusers\word97\setup.exe
```
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

In the registry on the client computer, click the following key:
Hkey_Local_Machine/Software/Microsoft/Windows/Current Version
Right-click a blank area in the right pane, and then click New.
Click String Value, type appinstallpath, and then press ENTER.
Right-click the item you just created.
In the Edit menu, click Modify.
In the Value Data area, type the UNC path to Apps.ini, including the file name. For example:
```
\\myserver\myshare\apps.ini
```
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.

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

On the Start menu, click Run, and then in the Open box, type dcomcnfg.
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.
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

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

On the Start menu, click Run, and then in the Open box, type dcomcnfg.
Click the Applications tab, click the application that you want to configure, and then click Properties.
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.