Windows 98 Internet Explorer History and Cookie Storage

In Microsoft Windows 98, web browsing history and HTTP cookies from Internet Explorer were deeply intertwined with the operating system itself due to the integration of the browser shell. This article examines the file structures, proprietary databases, and directory locations Windows 98 used to manage these artifacts, focusing on the mechanics of the index.dat database system and individual text-based cookie files.

The Role of User Profiles and Default Paths

Windows 98 supported both single-user and multi-user configurations. Storage locations depended on whether user profiles were activated:

  • Single-User (Default): Artifacts were kept in the primary system directory:
    • History: C:\WINDOWS\History
    • Cookies: C:\WINDOWS\Cookies
  • Multi-User Profiles Enabled: Artifacts were segregated by account under the profiles directory:
    • History: C:\WINDOWS\Profiles\<Username>\History
    • Cookies: C:\WINDOWS\Profiles\<Username>\Cookies

Windows treated these folders as special shell objects. A hidden desktop.ini file inside each directory instructed Windows Explorer to load dedicated shell extensions, rendering these folders as dynamic, searchable interfaces rather than standard file listings.

Browser History Storage

Internet Explorer (versions 4.01 through 5.x shipped with or updated on Windows 98) did not store browsing history as raw text or standard SQL databases. Instead, history records were managed via a proprietary binary database file named index.dat.

  1. Directory Hierarchy: The History directory contained several subdirectories organized by time frames (such as Today, Monday, or Week 1). Each of these subfolders contained its own hidden index.dat file.
  2. Database Contents: The index.dat file recorded the Uniform Resource Locator (URL), page titles, visit counts, timestamps (using the Win32 FILETIME structure), and cache association pointers.
  3. Shell Abstraction: When a user viewed the History folder, the operating system did not display the index.dat file. Instead, the Windows shell parsed the binary data and presented the entries as navigable shortcuts grouped by domain and date.

Cookies were handled through a hybrid system consisting of individual text files tracked by a master index file.

  1. Individual Text Files: Every stored cookie was written to disk as a plain text file. The naming convention typically followed the pattern <username>@<domain>[<number>].txt (for example, default@example[1].txt).
  2. File Format: Each cookie file contained plain-text lines detailing the specific cookie parameters:
    • Variable name and value
    • Domain name and path
    • Security flags (e.g., secure connections only)
    • Expiration timestamps encoded as two 32-bit integers representing Windows 64-bit file time values
    • Delimiter characters (typically asterisks *) separating distinct cookies from the same domain within a single file.
  3. The Cookies index.dat: Alongside the text files, the C:\WINDOWS\Cookies directory contained its own index.dat file. This database mapped domains to their corresponding text files to speed up retrieval when Internet Explorer requested stored state data during page loads.

Locking and Persistence

Because Internet Explorer components were loaded into explorer.exe at system startup, the index.dat files in both the History and Cookies directories remained open with exclusive write locks while Windows was running.

Clearing history or deleting cookies via the Internet Options control panel marked records as deleted within the binary database, but the underlying index.dat file was rarely reduced in file size. Complete removal of these records required restarting the machine into Real Mode MS-DOS to manually delete or recreate the locked index.dat files before the Windows GUI initialized.