How Windows 98 Handled Software Uninstallations

In Microsoft Windows 98, software removal was primarily coordinated through the "Add/Remove Programs" applet located in the Control Panel. Rather than managing the physical deletion of files itself, the operating system functioned as a central directory that queried the system registry to identify installed applications and execute third-party uninstallation routines. This article explains the technical mechanics of the Windows 98 Control Panel uninstaller, how the registry mediated the process, how native components were separated from third-party tools, and the architectural limitations that often left residual files behind.

Accessing Add/Remove Programs

Users initiated software removal by opening the Control Panel from the Start Menu (Start > Settings > Control Panel) and launching the Add/Remove Programs utility (internally executed via appwiz.cpl). The tool featured a tabbed interface, with the primary tab labeled Install/Uninstall. This screen compiled an alphabetical list of non-native programs registered with the operating system, accompanied by an "Add/Remove" button used to trigger the removal sequence.

Registry-Driven Discovery

Windows 98 did not actively monitor the hard drive to determine which programs were installed. Instead, it populated the uninstallation list by reading a specific branch of the Windows Registry:

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Uninstall

During software installation, well-behaved setup programs created a subkey under this path containing two critical string values:

  • DisplayName: The readable name of the software shown to the user in the Control Panel list.
  • UninstallString: The exact command-line instruction, executable path, or script required to initiate the removal process (e.g., C:\Program Files\App\uninst.exe or a call to an engine like InstallShield's IsUninst.exe).

When a user selected an application and clicked "Add/Remove," Windows 98 simply executed the command defined in the UninstallString.

Delegation to Third-Party Uninstallers

Windows 98 lacked a universal installer framework (the Windows Installer engine, or MSI, was only introduced toward the end of Windows 98's lifecycle via redistributables). Because of this, the operating system completely delegated the cleanup process to the third-party developer's proprietary uninstaller.

Once triggered from the Control Panel, the developer's uninstaller took over the screen, tasked with:

  1. Deleting application files from directories like C:\Program Files.
  2. Removing shortcuts from the Start Menu and Desktop.
  3. Deleting program-specific registry keys from HKEY_CURRENT_USER and HKEY_LOCAL_MACHINE.
  4. Deregistering COM components and removing system extensions.

The Handling of Shared DLLs

One of the defining aspects of the Windows 98 uninstallation routine was the handling of dynamic link libraries (DLLs). The operating system tracked shared components using reference counters stored in the registry under:

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\SharedDLLs

When an uninstaller decremented this counter to zero, it typically prompted the user with a dialog warning that a file may no longer be needed by any program, asking: "The system indicates that the following shared file is no longer in use by any programs. Do you want to delete it?" Users were forced to choose between deleting the file (risking breaking another application) or keeping it (wasting disk space).

Native Component Removal

The Add/Remove Programs applet contained a separate tab titled Windows Setup for handling operating system components. Unlike third-party applications, native features—such as Paint, Solitaire, Dial-Up Networking, and Internet Tools—were managed using setup information files (.inf files). Checking or unchecking these components prompted Windows 98 to read from the local C:\WINDOWS\OPTIONS\CABS directory or require the insertion of the original Windows 98 installation CD-ROM to modify the system files.

Common Limitations and Ghost Entries

Because the Control Panel served merely as a launcher for external scripts, several structural problems frequently occurred:

  • Broken Entries: If an application was manually deleted by dragging its folder to the Recycle Bin, the registry key remained. Attempting to click "Add/Remove" produced an error stating that the uninstallation program could not be found, leaving "ghost" entries in the Control Panel that required manual registry editing to remove.
  • Registry Clutter: Poorly written uninstallers routinely failed to clean up all configuration settings, leading to registry bloat over time.
  • Incomplete Deletions: Read-only files, temporary files generated after installation, and user-created data were frequently skipped, leaving empty folders behind on the hard drive.