How Windows 98 Handled Dual Processors and SMP

Microsoft Windows 98 did not support dual-processor or Symmetric Multiprocessing (SMP) hardware configurations. Despite the rising popularity of dual-socket enthusiast motherboards and multi-CPU workstations in the late 1990s, the consumer-focused operating system was fundamentally architected for single-processor machines. When installed on an SMP-capable system, Windows 98 simply ignored any additional processors, utilizing only the primary CPU while leaving secondary cores completely idle.

The Underlying Architectural Limitations

The inability of Windows 98 to harness multiple processors stemmed from its hybrid 16-bit and 32-bit architecture. Built upon the legacy foundations of MS-DOS and Windows 3.1, the Windows 9x kernel relied heavily on shared 16-bit system code, specifically within core components like USER and GDI.

To prevent concurrent operations from corrupting system memory, Windows 98 used a crude, global locking mechanism known as the "Win16Mutex." Any thread executing 16-bit code had to hold this lock, forcing all other threads requiring the subsystem to wait. Implementing SMP would have required re-architecting the kernel from scratch to handle fine-grained thread locking across multiple hardware execution contexts. Microsoft opted not to invest the massive engineering effort required to overhaul an aging codebase that was already slated for obsolescence.

System Behavior on SMP Hardware

When booted on a dual-processor system—such as the popular dual-Celeron setups on the ABIT BP6 motherboard of the era—Windows 98 handled the hardware by effectively pretending the second CPU did not exist.

During the initial boot sequence, the system BIOS initialized the hardware and designated one CPU as the Bootstrap Processor (BSP) while placing the other into an idle state as the Application Processor (AP). Windows 98 loaded only a uniprocessor kernel and possessed no SMP-aware Hardware Abstraction Layer (HAL). It initialized the BSP, ignored the AP entirely, and executed all operating system tasks and user applications exclusively on that single processor. Device Manager and system benchmarking tools inside Windows 98 would consistently report and utilize only one physical CPU.

The Solution: Windows NT and Windows 2000

Users who required dual-processor capabilities during the Windows 98 era had to run Microsoft's enterprise-grade operating systems. Windows NT 4.0 and the subsequent Windows 2000 were built on a fully 32-bit, modern kernel designed from inception with preemptive multitasking and SMP support. These operating systems utilized specialized multiprocessor HALs to dynamically distribute execution threads across multiple CPUs, unlocking the full potential of multi-socket hardware.