How Windows 98 Handled File Copying Progress

Microsoft Windows 98 featured one of the most recognizable file copying experiences in personal computing history, characterized by its iconic flying-paper animation and notoriously erratic time estimations. This article breaks down how the operating system handled file transfer dialogs, focusing on the interface design, the underlying calculation mechanics, and the technical reasons why the estimated time remaining fluctuated so drastically during operations.

The User Interface and Visual Elements

When a user initiated a file transfer via Windows Explorer, Windows 98 presented a dedicated modal dialog box managed by the Win32 Shell API—specifically through the SHFileOperation function.

The dialog included several key visual components:

  • The Animation: A looping Audio Video Interleave (AVI) animation displayed at the top of the window, showing sheets of paper physically drifting through the air from one folder into another. This animation served primarily as a heartbeat indicator to reassure users that the system had not frozen during heavy disk I/O.
  • Source and Destination Paths: Clear text paths displaying where files originated and where they were being written.
  • The Target Filename: Dynamic text updating in real time to show the exact file currently being processed.
  • Progress Bar: A standard 32-bit progress bar control that tracked the overall percentage of data transferred rather than individual file counts.
  • Time and Data Metrics: Text indicating the amount of data transferred versus the total size, alongside the "Estimated time remaining" line.

Calculation Mechanics and Time Estimation

Windows 98 calculated progress based on the total byte count of the selected payload rather than the quantity of files. Before initiating the transfer, the system scanned the selected directories to calculate the total byte size.

The time estimation algorithm relied on a simple moving average of recent transfer speeds. It measured the speed of the most recently transferred chunks of data and extrapolated that rate across the remaining bytes.

This approach was the primary reason for the dialog's famously erratic time estimates. Several factors routinely disrupted the accuracy of these calculations:

  1. File Size Variance: Copying thousands of tiny files required significant file system overhead (creating directory entries and updating the File Allocation Table, or FAT32) compared to copying a single large contiguous file. When the transfer shifted between large and small files, the instantaneous throughput changed drastically, causing the estimated time to jump from seconds to hours and back.
  2. Disk Caching: Windows 98 utilized VCACHE, which aggressively cached writes in RAM. Initial transfer speeds often appeared blisteringly fast until the cache filled up, causing the time estimate to drop rapidly at first, only to climb steeply once the system had to wait on physical disk writes.
  3. Hardware Latency: Variable read/write speeds from optical drives (CD-ROMs), floppy disks, and early USB 1.1 peripherals constantly skewed the transfer rate samples used by the estimator.

Error and Conflict Handling

The Windows 98 copy dialog also served as the control hub for file conflicts and file system errors. If a file with the same name already existed in the destination folder, the process paused and displayed a replacement confirmation prompt offering options to overwrite the file ("Yes"), overwrite all subsequent conflicting files ("Yes to All"), skip the file ("No"), or abort the entire operation ("Cancel").

Because file operations ran on the shell's thread architecture, any unreadable sector on a degraded floppy disk or scratched CD would cause the progress dialog to halt entirely while the system repeatedly attempted hardware-level retries before finally presenting an "Abort, Retry, Fail" style error prompt.