Windows 98 File Copying Over Network Shares

In Microsoft Windows 98, copying files across local area network (LAN) shares relied on the Server Message Block (SMB) protocol operating over NetBIOS, managed through a modular 32-bit protected-mode architecture. When a file transfer began, Windows 98 coordinated the process using its Installable File System (IFS) Manager, which routed data requests between local storage drivers and network redirectors. This system divided data into discrete network packets, transferred them across transport protocols like TCP/IP, NetBEUI, or IPX/SPX, and assembled them on the destination machine without requiring third-party networking software.

The Network Architecture and Component Drivers

Windows 98 handled network input/output (I/O) using a layered virtual device driver (VxD) model. At the center of file operations was the IFS Manager (IFSMGR.VXD), which intercepted high-level file system calls from user applications, Windows Explorer, or the MS-DOS command prompt.

When a source or destination path used a Universal Naming Convention (UNC) path (such as \\server\share\path), the IFS Manager recognized that the target resided outside the local file allocation table (VFAT) system. Instead of querying local disk drivers, it handed the request off to the Microsoft Network Redirector (VREDIR.VXD). On the receiving side, the target computer processed the request using the File and Printer Sharing service (VSERVER.VXD).

Session Establishment and Handshake

Before data moved, Windows 98 resolved the target machine's NetBIOS name to an address on the local network using broadcast queries, a local LMHOSTS file, or a WINS (Windows Internet Name Service) server. Once the client located the host, it established a session:

  1. Protocol Negotiation: The client and server negotiated an SMB dialect (typically SMB 1.0/CIFS) to determine shared capabilities and buffer limits.
  2. Session Setup: The client authenticated using the local user credentials or prompted for a share password, depending on whether the share was set up for Share-Level Access Control or User-Level Access Control.
  3. Tree Connect: The client established a connection to the specific shared folder, obtaining a Tree ID (TID) to track subsequent operations within that folder.

The Read, Buffer, and Write Cycle

Unlike modern operating systems that support server-side copy mechanisms, Windows 98 always pulled data through the client machine initiating the copy command. If a user copied a file from \\ServerA\Share to \\ServerB\Share, the client acted as an intermediary, downloading the file from Server A into local memory before uploading it to Server B.

For a standard copy from a local drive to a remote network share, the execution flow followed a repetitive loop:

  1. Local Read: The IFS Manager requested a block of data from VFAT.VXD, which retrieved it from the physical drive via the block I/O subsystem and loaded it into the system's memory cache (VCACHE).
  2. Packet Assembly: VREDIR.VXD broke the cached data into SMB Write requests (SMB_COM_WRITE or SMB_COM_WRITE_ANDX). The default negotiated buffer size (raw transfer size) typically limited these chunks to between 4 KB and 64 KB per operation.
  3. Transport Layer Delivery: The redirector passed the SMB requests to the NetBIOS interface, which handed the data to the configured transport driver (such as VTCP.386 for TCP/IP). The transport layer split the data into network frames and sent them through the Network Driver Interface Specification (NDIS) layer to the physical network interface card (NIC).
  4. Acknowledgement: The destination machine's VSERVER.VXD received the packets, wrote the payload to its local disk, and returned an SMB acknowledgement back across the network.
  5. Loop and Completion: The client waited for the acknowledgement (or managed sliding windows if supported) before sending the next block.

Finalizing the File

Once the final byte transferred, the client issued an SMB_COM_CLOSE command to close the remote file handle. Along with the close request, the client transmitted the original file’s metadata, including standard DOS file attributes (Read-Only, Archive, Hidden, System) and the last modified timestamp, ensuring the newly created remote copy matched the original source file.