We do not quite say that the new is more valuable because it fits in; but its fitting in is a test of its value. --T.S. Eliot For your consideration, I submit the following examples of hardware longevity: The computer I use to test software and run beta copies of programs is a trusty old 486 that has served me faithfully for over five years; I recently purchased a new laser printer, but the old LaserJet I had was four-and-a-half years young; my first notebook computer is still going strong after five years (albeit in the company of my goddaughter, to whom I donated it last year); and my fax machine will celebrate its seventh birthday later this year.
Why the litany of Methuselan machines? Because I want to compare these old hardware codgers with the software I use. To wit, of all the programs and utilities I crank up regularly, the oldest--an accounting package I use to track my finances--has been out of its shrink wrap for a little less than a year!
Hardware, then, is a typical high-end commodity--we buy it and then tend to hang on to it until it wears out. Software, on the other hand, is a new kind of consumer product, one that reinvents itself constantly. Thanks to cheap, frequent upgrades and an unending stream of new, innovative products, it's tough to resist the siren song of the latest and greatest.
The upshot is that we spend a not-insignificant chunk of our computing lives installing software. The designers of Windows 98, bless their fully vested hearts, understood this all too well, so they included some features in Windows 98 that make it easier to install applications. Even better, there's also support for uninstalling programs, just in case the two of you don't get along very well. This chapter shows you how to use Windows 98's built-in install/uninstall features, and it also shows you how to add and remove older Windows applications and DOS programs.
For those who enjoy working with computers, few things are as tempting as a new software package. The tendency is to just tear into the box, liberate the source disks, and let the installation program rip without further ado. This approach often loses its luster when, after a willy-nilly installation, your system starts to behave erratically. That's usually because the application's setup program has made adjustments to one or more important configuration files and given your system a case of indigestion in the process. That's the hard way to learn the hazards of a haphazard installation.
To avoid such a fate, you should always look before you leap. That is, you should follow a few simple safety measures before double-clicking that SETUP.EXE file. The next few sections give you some precautionary tales.
If the application you're installing is from a well-known developer, if you purchased it from a reputable dealer, and if the box is unopened, you almost certainly don't have to think twice about viruses. Yes, there have been documented cases of viral code infecting a disk or two in brand-name programs, but these are extremely rare, to the point where worrying about it verges on the paranoid.
However, there are other situations in which it pays to be paranoid. You should check for viruses before installing if
Ideally, your virus checker should be able to hunt down viruses even in ZIP files and other compressed archives. All the anti-virus programs I mentioned in Chapter 17, "Wielding the Windows 98 System Tools," can do this.
It's a rare (and poorly constructed) installation program that will bring an entire system to its knees, but it can happen. An amateurish Windows 98 installer could rip apart the Registry, for example, or a dumb DOS setup program could write to a verboten memory address. Although having a bootable disk within reach is always a good idea, make sure you have one handy before installing any new software. To learn how to create a bootable disk and stock it with utilities and files that will let you recover gracefully, see Chapter 17 (in the "Creating an Emergency Boot Disk" section).
Few software developers want to alienate their installed user base, so they usually emphasize upward compatibility in their upgrades. That is, the new version of the software will almost always be able to read and work with documents created with an older version. However, in the interest of progress, you often find that the data file format used by the latest incarnation of a program is different from its predecessors, and this new format is rarely downward- compatible. That is, an older version of the software will usually gag on a data file that was created by the new version.
So you are faced with the following choices:
One possible solution to this dilemma is to make backup copies of all your data files before installing the upgrade. That way, you can always restore the good copies of your documents if the upgrade causes problems or destroys some of your data. If you've already used the upgrade to make changes to some documents, but you want to uninstall the upgrade, most programs have a Save As command that lets you save these documents in their old format.
If you're installing a Windows 98 application, it will write the bulk of its configuration data to the Registry. Most of these changes will be application-specific, but some installation programs also make changes to more global settings. You could end up with a system that behaves strangely or, in the worst case, doesn't behave at all!
Fortunately, as you'll see later, true Windows 98 applications have an uninstall feature that not only removes the program's files, but also purges any traces of the program from the Registry. However, programs designed for Windows 3.1 and Windows for Workgroups might also change some Registry settings in the HKEY_CLASSES_ROOT key.
So, just to be safe, you should make a backup copy of the Registry before installing any application that might fiddle with the Registry. You should do two things:
While you're in a backing-up frame of mind, you can add an extra level of protection to your installations by backing up all your configuration files: the Registry, CONFIG.SYS, AUTOEXEC.BAT, WIN.INI, SYSTEM.INI, and so on. This is particularly important before installing 16-bit or DOS applications that routinely make changes to these files.
The best way to back up all these configuration files in one fell swoop is to use Windows 98's Registry Scan utility, described in Chapter 17. Be sure to customize the utility to back up all your configuration files.
When I discuss uninstalling applications later in this chapter, you'll see that one of the biggest problems you'll face is figuring out which files the program used outside its home folder. Many 16-bit Windows applications like to add files to both the main Windows folder and the SYSTEM subfolder. Unfortunately, there's no easy method of determining which files an application inserts into these two folders. (However, as I explain later, Windows 98's Quick View accessory can help ferret out which DLLs a program uses.)
The only way to be sure is to take a "snapshot" of the current state of the main Windows 98 folder and the SYSTEM subfolder both before and after you install the software. To do this, head to the DOS prompt and run the following two commands before you install:
dir c:\windows /a-d /on > windir1.txt dir c:\windows\system /a-d /on > sysdir1.txt
The first line runs the DIR command on C:\WINDOWS (which you should change to the path of your main Windows 98 folder) and saves it in a file named DIRWIN1.TXT. (The /a-d switch tells DIR not to display folders, and the /on switch sorts the files alphabetically by name.) The second line saves a file listing of the SYSTEM subfolder in the file SYSDIR.TXT1.
When the installation is complete, go back to the prompt and enter the following commands:
dir c:\windows /a-d /on > windir2.txt dir c:\windows\system /a-d /on > sysdir2.txt
You can then compare WINDIR1.TXT to WINDIR2.TXT, and SYSDIR1.TXT to SYSDIR2.TXT, to see which files the setup program foisted upon your system.
One way to do this would be to open two copies of Notepad and load the contrasting files into each window. In the post-installation versions, if you delete the lines corresponding to the files that haven't changed, you end up with a list of the new files. You can then keep this list in a safe location in case you need it later while uninstalling.
Another way to compare these files is to use the DOS FC (file compare) command. I'll explain how this command works later in this chapter (see the section titled "The FC Command").
If you do nothing else to prepare for a software installation, you should read whatever documentation the program provides that pertains to the setup. This includes the appropriate installation material in the manual, README files found on the disk, and whatever else looks promising. By spending a few minutes perusing these resources, you can glean the following information:
Many programs offer to display their README files when the installation is complete, but that might be too late. On more than one occasion, I have installed a program, viewed the README file, and then groaned when I read some crucial tidbit that I should have known before the setup procedure began. (You should always assume that setup programs were coded in haste at the end of the development cycle and therefore tend to be somewhat poorly designed.)
Some setup programs give new meaning to the term "brain-dead." You slip in the source disk, run SETUP.EXE (or whatever), and the program proceeds to impose itself on your hard disk without so much as a how-do-you-do. Thankfully, most installation programs are a bit more thoughtful than that. They usually give you some advance warning about what's to come, and they prompt you for information as they go along. You can use this newfound thoughtfulness to assume a certain level of control over the installation. (The Windows 98 Setup program is a perfect example of a polite installer that gives you as much or as little control over the installation process as you'd like.) Here are a few things to watch for:
Choose your folder wisely: Most installation programs offer to install their files in a default folder. Rather than just accept this without question, think about where you want the program to reside. Personally, I prefer to use the Program Files folder to house all my applications. If you have multiple hard disks or partitions, you might prefer to use the one with the largest amount of free space. If the setup program lets you select data directories, you might want to use a separate folder that makes it easy to back up the data.
Use the custom install option: Like Windows 98 Setup, the best programs offer you a choice of installation options. Whenever possible, choose the Custom option, if one is available. This will give you maximum control over the components that are installed, including where they're installed and how they're installed.
Perform your own configuration file modifications: If an installation program is truly polite, it will let you know that it needs to modify one or more of your configuration files. Hopefully, you also can choose between letting the program make the modifications automatically or making the modifications yourself. If so, you should always opt for the latter so that you can change the files in a way that won't harm your system.
I've mentioned three separate examples of files that you might need to compare before and after an installation:
In each case, you compare the pre-installation version with its post-installation counterpart to see what changes were made (if any). You can use three basic methods to make these comparisons: brute force, the DOS FC command, and your word processor's compare feature.
The most straightforward method is to load the before-and-after files into separate Notepad (or WordPad) windows and compare them line by line. This is fine for small files (such as CONFIG.SYS) or ordered files (such as the results of the DIR command I showed you earlier), but it's next to useless for a large file such as the exported Registry.
DOS has an FC (file compare) command that will compare two files and report on their differences. Here are the two syntaxes you can use with this command:
FC [/A] [/C] [/L] [/LBn] [/N] [/T] [/W] [/n] filename1 filename2 FC /B filename1 filename2
/A - Displays only first and last lines for each set of differences.
/B - Performs a binary comparison.
/C - Disregards the case of letters.
/L - Compares files as ASCII text.
/LBn - Sets the maximum consecutive mismatches to the specified number of lines.
/N - Displays the line numbers on an ASCII comparison.
/T - Does not expand tabs to spaces.
/W - Compresses white space (tabs and spaces) for comparison.
/n - Specifies the number of consecutive lines that must match after a mismatch.
filename1 - The first file you want to compare. filename2 - The second file you want to compare. For example, to compare the SYSTEM folder file listings I mentioned earlier, you use the following command (assuming that the files are in the root folder of drive C):
fc /l c:\sysdir1.txt c:\sysdir2.txt > fc.txt
In this case, I've redirected the output of the FC command into a file named FC.TXT. Figure 18.1 shows part of this output. Each time FC finds a difference, it displays the lines that are changed, as well as the lines before and after that are still the same. For example, FC shows the following output for SYSDIR1.TXT:
WINSSPI DLL 30,416 08-11-97 11:34a WINSSPI.DLL WINTRUST DLL 78,096 08-18-97 4:43p WINTRUST.DLL
This is followed by the output for SYSDIR2.TXT:
WINSSPI DLL 30,416 08-11-97 11:34a WINSSPI.DLL WINTOP VXD 14,102 06-22-96 5:04a WINTOP.VXD WINTRUST DLL 78,096 08-18-97 4:43p WINTRUST.DLL
As you can see, one file has been added between WINSSPI.DLL and WINTRUST.DLL--namely,
WINTOP.VXD.
FIGURE 18.1. The output
of an FC command.
Most high-end word processors have a feature that enables you to compare two files. In Word 97, for example, open the post-install file, select Tools | Track Changes | Compare Documents, and then use the Open dialog box to open the pre-install file. Word examines the documents and then inserts the changes using revision marks.
You've seen throughout this book that Windows 98 has a Wizard for almost every occasion. Installing applications is another one of those occasions. The Add/Remove Programs Wizard is a simple series of dialog boxes that help you find and run an application's setup program. This might sound like something that's useful only for novices, but there are good reasons to use this Wizard to launch all your installation programs. The biggest reason is that it warns Windows 98 that you're about to install an application, so the operating system can set itself up accordingly. Also, for Windows 98 applications, it ensures that the appropriate data is stored in the Registry (the program's installed components, the parameters needed to run the program successfully, the information needed to uninstall the program, and so on).
Here are the steps to follow to run the Add/Remove Program Wizard:
FIGURE 18.2. If the Wizard finds an installation program, it displays its pathname.
If the installation program tells you to restart your computer, try to avoid letting the program do it for you. It's safer to just exit the installation program, close your running applications, and then restart the system manually.
Let's now turn our attention to the three main types of applications you might need to install: 32-bit applications, 16-bit applications, and DOS applications. The next few sections discuss the installation issues involved with each type of application, as well as approaches that work best with each type.
There are plenty of reasons to use 32-bit applications under Windows 98, including long filename support, preemptive multitasking, and protected memory space. Here are two more to add to the list: a standard installation procedure that's easy to use and the ability to uninstall applications.
Before proceeding, I should clarify that when I talk about "32-bit" applications, I'm referring specifically to applications that qualify for the Windows 95 or Windows 98 logo. In other words, I'm not talking about applications written specifically for computers running Win32s (a subset of the Win32 API) or Windows NT.
Microsoft has published a new set of requirements for the Windows 98 logo. As a recap, to qualify for the Windows 95 logo, an application must meet the following guidelines:
For Windows 98, Microsoft has put together a new set of guidelines (known as the Logo 4.0 requirements) that an application must meet to qualify for the "Designed for Windows 98" logo. Here are some of the highlights:
THE LATEST LOGO NEWS
To get the latest information about the "Designed for Windows 98" logo, keep an eye on the following Web site:
http://www.microsoft.com/windows/thirdparty/winlogo/
Thirty-two-bit applications that qualify for the coveted Windows 98 logo have strict guidelines they must follow during installation. These guidelines are designed to make the installation easier for the user and to make sure that the application fits into the Windows 98 way of doing things (what Microsoft calls, somewhat chillingly, being a "good Windows 98 citizen"). These guidelines include the following points:
The Registry is crucial because it identifies the application to Windows 98 and sets up functionality, such as file types, default document actions, OLE information, application-specific paths, uninstall data, and more. The next few sections run through some of the changes that a typical installation program might make to the Registry.
Version-Specific Settings Most programs add a new subkey to HKEY_LOCAL_MACHINE\SOFTWARE that uses the following general format:
HKEY_LOCAL_MACHINE\SOFTWARE\CompanyName\ProductName\VersionCompanyName is the name of the vendor, ProductName is the name of the software package, and Version is the version number of the application. This key stores general information pertaining to this copy of the application.
User-Specific Settings Most programs also add the following key:HKEY_CURRENT_USER\Software\CompanyName\ProductNameThis key stores user-specific preferences and generally has a number of subkeys. For example, Figure 18.3 shows the various subkeys added by Netscape Navigator. Applications used to store this data in WIN.INI.
FIGURE 18.3. Applications use HKEY_CURRENT_USER\ Software to store their user-specific options and preferences.
Application-Specific Paths As explained in Chapter 13, "A Few Good Hacks: Some Useful Registry Tweaks," Windows 98 uses application-specific paths instead of a general PATH statement. When you enter just the primary name of an application's executable file, Windows 98 will launch the program successfully.
To set up this feature, the installation program must add a new subkey to the following key:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\AppPathsThis new subkey will have the same name as the application's executable file, and its Default setting will contain the full pathname to the executable. The install program might also create a Path setting that specifies a default folder (or folders) for the application. Netscape, for example, adds a NETSCAPE.EXE subkey with the following settings:
Default C:\Program Files\Netscape\Navigator\Program\Netscape.exe Path C:\Program Files\Netscape\Navigator\Program;C:\Program ÂFiles\Netscape\Navigator\System
Extensions and Actions If the program creates data files with a unique extension, the installation procedure will register a new file type with Windows 98. This involves adding an extension subkey to HKEY_CLASSES_ROOT (the alias of HKEY_LOCAL_MACHINE\SOFTWARE\Classes), as well as a corresponding file type subkey. The latter will define the default icon for the file type, actions available for the file type, and a few other things. For OLE applications, a unique CLSID subkey will be added to HKEY_CLASSES_ROOT\CLSID (you'll learn more about this in Chapter 19, "Sharing Data in Windows 98: The Clipboard and OLE").
Shared DLLs As you'll see later when you learn about uninstalling, one of Windows 98's nicest features is that it keeps track of shared DLLs--DLL files that are used (or can be used) by multiple applications. A common example is the VBRUN300.DLL file that's used by most programs created with Visual Basic version 3.It's up to the installation program to check the user's system for any shared DLLs (and other components) that are required by the application. If it finds any, the installation program should increment the Registry's usage counter for each DLL. You find these usage counters in the following key:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\SharedDLLsFigure 18.4 shows some sample entries in this key. Each setting uses a DWORD value that tells you how many applications use each DLL. For example, Figure 18.4 tells you that two applications use the file CTRES.DLL.
FIGURE 18.4. Windows 98 uses the SharedDLLs key to keep track of the number of 32-bit applications using a particular DLL file.
Uninstall Data To facilitate easy removal of an application, the setup program stores uninstall information in the following Registry key:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\UninstallI'll talk more about this feature later in this chapter in the section called "Uninstalling 32-Bit Applications."
Installing 32-bit applications is easy. Use the Add/Remove Programs Wizard to launch the setup program, and the installation proceeds with (generally speaking) little in the way of user input. (This depends on the complexity of the application, of course.) Many Windows 98 developers use the InstallShield SE Toolkit that's included in the Win32 Software Development Kit (SDK) to develop their installation programs. This means that most of your 32-bit programs will have a similar look and feel during installation. You know that a program is using the InstallShield Wizard if you see the dialog box shown in Figure 18.5.
DON'T FORGET AUTOPLAY
Another advantage of using 32-bit applications designed for Windows 95 or Windows 98 is that they often support the AutoPlay feature for CD-ROMs. In particular, these applications will often launch their installation programs automatically when you insert the CD.
FIGURE 18.5. If you see
this dialog box, you know that the setup program was developed using the InstallShield
SE Toolkit.
From here, the InstallShield Wizard takes you through a series of dialog boxes like
the ones shown in Figures 18.6 and 18.7. Unlike with Windows 3.x, in the vast
majority of cases you won't have to reboot after installing your 32-bit application.
Because all the configuration information is stored in the Registry, Windows 98 can
handle the newcomer dynamically. (The exceptions to this rule are applications that
require device drivers to be loaded at startup.)
FIGURE 18.6. The first of
the InstallShield Wizard's dialog boxes.
FIGURE 18.7. This InstallShield
Wizard dialog box prompts you for a file location.
Sixteen-bit Windows 3.x applications are, by definition, ineligible for the Windows 98 logo, so their installation programs don't have all the fancy features that 32-bit applications have. In particular, 16-bit install programs don't know about the Registry--or, more accurately, they know, at best, only about a small part of the Registry: HKEY_CLASSES_ROOT. Therefore, they don't support new features, such as application-specific paths, shared DLLs, and uninstall data.
Microsoft, of course, was well aware of this, so it made sure that any 16-bit application would install in Windows 98 exactly as it would install in Windows 3.x. To accomplish this, Microsoft made the following design decisions in Windows 98:
Support for older configuration files: Most 16-bit applications store their configuration data in WIN.INI and SYSTEM.INI, and they read data from these files as well. Therefore, Windows 98 still maintains these files so as not to break 16-bit installation programs. Sixteen-bit install programs are also free to add or edit lines in CONFIG.SYS and AUTOEXEC.BAT, and Windows 98 will honor these changes.
Built-in 32-bit functionality to replace 16-bit components: Most drivers and TSRs that used to get loaded in CONFIG.SYS and AUTOEXEC.BAT are now part of the Windows 98 operating system in 32-bit versions. Sixteen-bit applications don't know this, however, so they'll often look to CONFIG.SYS and AUTOEXEC.BAT for the appropriate files. The polite ones will let you know that you're "missing" a particular component and offer to add it for you, as shown in Figure 18.8. Other, ruder install programs will just go ahead and add lines to your startup files.
FIGURE 18.8. Here, VISIO's
setup program wants to add the SHARE command to AUTOEXEC.BAT.
SHARE is now implemented as the VSHARE VxD, so you could ignore this
request.
CHECK YOUR STARTUP FILES AFTER INSTALLING
After installing any 16-bit application, check your CONFIG.SYS and AUTOEXEC.BAT files to see whether any extraneous lines have been added, and delete them if necessary.
A SYSTEM subfolder: Microsoft now encourages developers to store DLLs and other behind-the-scenes components in their program's main folder. However, most 16-bit applications are set up to just toss all their DLLs, font files, and whatever else into the SYSTEM subfolder of the main Windows folder. Because these install programs can't update the SharedDLLs usage counters, it's a good idea to save a DIR file listing for the SYSTEM subfolder before and after installing 16-bit applications.
Windows 98 watches the SYSTEM subfolder: Microsoft wanted to avoid letting bull-in-a-china-shop install programs overwrite newer DLLs or add useless DLLs to the SYSTEM subfolder. Therefore, while you're installing, Windows 98 keeps an eye on activity in this folder and prevents install programs from messing with any of the existing files. This is another good reason to use the Add/Remove Programs Wizard to install 16-bit applications, because it alerts Windows 98 that an installation is underway.
DO YOU HAVE TO REINSTALL YOUR 16-BIT APPS?
If you chose to install Windows 98 in a folder separate from Windows 3.x, you might think that you have to reinstall all your 16-bit applications to get them to work from Windows 98. Actually, in many cases you won't have to. As long as you add the main Windows 3.x folder and its SYSTEM subfolder to your Windows 98 PATH, many of your 16-bit applications will run just fine. To do this, add the following line to your AUTOEXEC.BAT file:PATH %PATH%;C:\WIN31;C:\WIN31\SYSTEM
Be sure to substitute your main Windows 3.x folder for C:\WIN31. Note that, in some cases, you might also need to add the application's folder to the PATH as well.
Because DOS programs (for the most part) don't bother with any Windows-related procedures, they're the simplest of all programs to install. Just fire up the Add/Remove Programs Wizard, find the installation program, and proceed from there. As usual, it's best to use this procedure and not simply install the program from Explorer or the DOS prompt. That way, Windows 98 can monitor the progress of the installation and make sure nothing untoward goes on. Also, this ensures that Windows 98 checks APPS.INF for program-specific configuration information.
You may occasionally find that a DOS-based setup program won't run under Windows 98. If this happens, you have no choice but to abandon Windows 98 and install the program using MS-DOS mode. (For details on MS-DOS mode, see Chapter 23, "DOS Isn't Dead: Unleashing the DOS Shell.")
As with 16-bit applications, you need to watch out for unnecessary changes to CONFIG.SYS and AUTOEXEC.BAT. If the program adds drivers or TSRs that have been replaced by protected-mode components in Windows 98, you need to remove the offending lines from the startup files. However, if the program will run only in MS-DOS mode, you have two choices:
If you're a system administrator and you often install software on multiple machines on your network, Windows 98 gives you a handy method for allowing users to install these applications themselves. Setting this up requires three steps:
The next two sections expand on steps 2 and 3.
APPS.INI is an initialization file that specifies both the name of each application and the location on the server of the application's setup program. Create APPS.INI as a plain text file in a read-only folder on the server. Then open APPS.INI and enter the following section title:
[AppInstallList]
Below this heading, enter the specifics for each application using the following general format:
Application Name=[*]UNC-Path
Application Name is any descriptive name you give to the application (this is the name the users will see when they install the application). UNC-Path is the UNC path to the application's setup program. Here's an example:
Netscape Communicator=\\ZEUS\C\Applications\Netscape4\cb32e401a.exe
If the application's setup program doesn't support UNC paths, append an asterisk (*) to the front of the UNC path. This tells the server to temporarily map a drive letter for the application's folder.
To enable the network install feature on a user's machine, you need to modify the user's Registry. Specifically, you need to launch the Registry Editor and travel to the following key:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion
From here, select Edit |ew | String Value and then name the new
setting AppInstallPath. Open this new setting and, in the Edit String dialog
box that appears, enter a UNC path that points to the APPS.INI file on the
server. Figure 18.9 shows an example.
FIGURE 18.9. You need
to add an AppInstallPath setting to each user's Registry.
This new setting goes into effect as soon as you exit the Edit String dialog box.
The result is a new Network Install tab in the Add/Remove Programs Properties sheet,
as shown in Figure 18.10. This tab contains a list of all the applications you entered
in your APPS.INI file. To install the application from the server, highlight
it and click Install.
FIGURE 18.10. With the AppInstallPath
setting in effect, the Add/Remove Programs Properties dialog box sprouts a new Network
Install tab.
Applications, like the people we meet, fall into three categories: friends for life, acquaintances we deal with occasionally, and those we hope never to speak to again. Avoiding people we dislike is usually just a matter of avoiding contact with them--they'll get the hint after a while. Unlikable applications, however, just don't seem to get it. They keep hanging around like party guests who won't leave. If you have an application that's worn out its welcome, this section shows you the proper way to uninstall it so that it's out of your life forever.
One of the truly useful features you get with 32-bit Windows 98 logo-compliant applications is the ability to uninstall these programs easily. When you install one of these programs, it adds a new subkey to the following Registry key:
\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall
As you can see in Figure 18.11, this subkey contains two settings:
DisplayName: This setting is usually the name of the program, and it's what appears in the list of programs to uninstall that you see in the Add/Remove Programs Properties dialog box (discussed later).
UninstallString: This is the command line for the program that performs the removal. Note that it's not Windows 98 that's doing the removing. Instead, it's a program provided by the developer of the application (a sort of "anti-install" program).
FIGURE 18.11. 32-bit applications store uninstall data in the Registry. When removing an application from your system, the uninstall program does the following:
To uninstall an application, open Control Panel's Add/Remove Program icon. The box in the bottom half of the Install/Uninstall tab lists the applications that you can uninstall, as shown in Figure 18.12. To remove an application, highlight it and click the Add/Remove button. A dialog box will appear, asking you to confirm the deletion. Click Yes to continue.
If the program finds a shared DLL that isn't used by another program (that is,
a DLL with a usage counter at 0), you see a Remove Shared File? dialog box similar
to the one shown in Figure 18.13. Click Yes or No as appropriate. You might need
to repeat this process a few times.
FIGURE 18.12. The Add/Remove
Programs Properties dialog box lists the applications you can uninstall.
FIGURE 18.13. You see
this dialog box for shared DLLs with a usage counter that's now down to 0.
TROUBLESHOOTING: YOU CAN'T UNINSTALL A PROGRAM
When you remove a program using the Add/Remove Programs tool in Control Panel, you receive the following error message:An error occurred while trying to remove <Program Name>. Uninstallation has been canceled
This error occurs if a program that's listed in the Install/Uninstall tab has already been deleted manually. To remove a program from the list in the Install/Uninstall tab, delete the appropriate subkey under the following Registry key:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall
Unfortunately, removing a 16-bit application from your system is much less straightforward. Unless the program comes with its own uninstall feature (and some do), you have to employ a bit of guesswork to eradicate these older programs.
The real problem with 16-bit applications is that they tend to litter the main Windows 98 folder and the SYSTEM subfolder with all kinds of extraneous files. Determining which files can be deleted is often a tricky business. Here are some ideas:
FIGURE 18.14. The Quick
View accessory can tell you which DLLs an executable file uses.
You can delete some of these files without a second thought. A private INI file is
a good example. However, it's dangerous to delete DLLs and other SYSTEM
folder files, because other applications might need them. There are a couple of ways
to check, however.
For example, you could examine the SharedDLLs key in the Registry to see whether any 32-bit applications are using the DLLs. You could also use the Find feature (Start | Find | Files or Folders) to look for mentions of the DLL in other files. You probably just need to search the main Windows 98 folder and all its subfolders. (For example, if the DLL is named OLDAPP.DLL, search for oldapp.) You need to enter the primary name of the DLL in the Containing text box. If Find locates any executable files or other DLLs that mention the DLL in question, you can assume it's being used by another application.
If, in the end, you're still not sure about a particular DLL, just move it to another folder. Then, down the road, if a program complains that the file is missing, you can always restore it.
When all that's done, you can get rid of the rest of the program by following these steps:
Uninstalling DOS programs is usually more straightforward, because they tend to store all their files in one folder. This means you can remove most DOS programs with a simple four-step procedure:
This chapter showed you how to install and uninstall applications in Windows 98. I began by showing you a few tips and techniques for practicing "safe" setups. These included checking for viruses, having a bootable disk nearby, backing up configuration files, reading the documentation, and taking control of the installation. I then showed you how to wield the Add/Remove Programs Wizard. The rest of the chapter showed you how to install and uninstall 32-bit applications, 16-bit applications, and DOS programs.
Here's a list of chapters where you'll find related information:
© Copyright, Macmillan Publishing. All rights reserved.
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}