How Windows 95 Handled Network File Transfers
Windows 95 introduced a hybrid 32-bit operating system architecture that significantly altered how background tasks, including network file transfers, operated compared to earlier versions of Windows. By implementing preemptive multitasking for 32-bit applications, a protected-mode 32-bit networking stack, and an Installable File System (IFS) manager, Windows 95 allowed network transfers to progress in the background while users interacted with other applications.
Preemptive Multitasking and Thread Management
Under the prior Windows 3.x environment, cooperative multitasking required applications to explicitly yield control back to the operating system, meaning an active file transfer could easily stall if another application froze. Windows 95 resolved this for 32-bit processes by introducing preemptive multitasking.
When a user initiated a network copy through Windows Explorer or a Win32 application, the task ran on an independent execution thread. The Windows 95 kernel scheduler allocated CPU time slices to each thread using priority-based scheduling. If a foreground task was idle or waiting for user input, the scheduler allocated CPU cycles to the background file transfer thread, keeping data moving across the network without user intervention.
The 32-Bit Protected-Mode Network Redirector
A major component of background transfers in Windows 95 was the
Microsoft Client for Microsoft Networks (VREDIR.386 or VREDIR.VXD), a
32-bit virtual device driver (VxD) running in Ring 0 (kernel mode). In
older architectures, network operations frequently dropped down into
16-bit real-mode DOS to execute INT 21h or
INT 2Fh interrupts, which blocked the CPU and degraded
multitasking performance.
Windows 95 bypassed real-mode DOS for networking entirely. The VREDIR driver implemented the Server Message Block (SMB) protocol natively in protected mode. Because network protocol operations took place in Ring 0 using 32-bit code, the operating system could process incoming and outgoing network packets via asynchronous interrupts without halting user-space (Ring 3) tasks.
The Installable File System (IFS) and VCACHE
The coordination between local storage and remote network shares was
managed by the Installable File System (IFS) Manager
(IFSMGR.VXD). When a network file transfer took place, the
IFS Manager routed requests between the network redirector and the local
file system driver (VFAT).
The transfer process functioned through several integrated components:
- Asynchronous I/O: The network stack did not wait synchronously for a packet to reach its destination before returning control to the system. Network drivers transmitted packets and used hardware interrupts to signal when buffers were cleared or new packets arrived.
- NDIS 3.1: The Network Driver Interface Specification (NDIS) version 3.1 enabled 32-bit, protected-mode network interface card (NIC) drivers. This allowed direct memory access (DMA) transfers between the network card and system RAM without stalling the main processor.
- Unified Caching (VCACHE): Windows 95 utilized dynamic 32-bit disk caching. During transfers, data read from the network was staged in cache memory before being committed to the local hard drive, reducing the impact of slower storage writes on network throughput.
UI Separation and the Win16 Lock
While the network transfer itself was managed preemptively at the kernel and driver level, the visual feedback—such as the standard file-copy animation showing paper flying between folders—was handled in the user-interface layer by the Windows shell.
Windows 95 retained some legacy 16-bit code in its User and GDI subsystems, governed by a mechanism called the "Win16 Lock" (or Win16 Mutex). If a legacy 16-bit application was actively drawing to the screen or handling messages, the graphical progress bar for the file copy might appear to freeze. However, because the underlying network redirector, NDIS drivers, and the IFS Manager operated entirely in 32-bit Ring 0, the actual byte transfer continued unimpeded in the background.