Multi-Protocol Network Bindings in Windows 95

During the mid-1990s, the release of Windows 95 marked a major evolution in PC networking by introducing native, protected-mode support for running multiple network protocols simultaneously over a single network interface card (NIC). Before this, managing concurrent protocols like NetBEUI, IPX/SPX, and TCP/IP required complex real-mode DOS drivers that consumed scarce conventional memory. Windows 95 solved this challenge through a modular, 32-bit network architecture centered around the Network Driver Interface Specification (NDIS) version 3.1, enabling seamless multi-protocol binding without third-party shims or system reboots.

The Role of NDIS 3.1

The core technology enabling multi-protocol binding in Windows 95 was NDIS 3.1. Developed jointly by Microsoft and 3Com, NDIS standardized the interface between transport protocols and network adapter drivers.

In NDIS 3.1, drivers operated in 32-bit protected mode (.vxd virtual device drivers). The NDIS wrapper functioned as a multiplexing intermediary:

  • Above NDIS: Multiple transport protocol drivers (such as VIPX.386 for IPX/SPX or MSTCP.386 for TCP/IP) could register to send and receive frames.
  • Below NDIS: A single miniport driver managed physical communication with the network adapter.

Because the interface was decoupled, protocols did not need direct knowledge of the underlying physical hardware, and hardware drivers did not need custom code to support specific network suites.

How Binding and Multiplexing Worked

When Windows 95 initialized a network interface card, it created bindings—logical software connections—between installed transport protocols and the physical adapter driver.

  1. Transmission: When an application sent data over the network, it passed the request to the appropriate protocol stack (e.g., NWLink for NetWare resources, TCP/IP for the internet). The protocol formatted the data into an NDIS-compliant packet and passed it downward. The NDIS wrapper scheduled the packet and directed it to the single adapter driver for transmission over the wire.
  2. Reception and Demultiplexing: When the network card received incoming traffic, the miniport driver handed the raw data frame up to the NDIS layer. NDIS inspected the frame's header (specifically the Ethernet Type field or 802.2 LLC header) to identify the protocol:
    • Frames with EtherType 0x0800 were directed to the TCP/IP stack.
    • Novell 802.3 or 802.2 frames were routed to IPX/SPX (NWLink).
    • NetBEUI frames were routed to the NetBEUI transport layer.

This packet-level demultiplexing occurred entirely in memory at the driver level, allowing a single cable and card to maintain concurrent sessions across completely different operating systems and server environments.

Binding Order and Priority

Windows 95 exposed these bindings directly to the user through the Network Control Panel applet. Users could inspect the properties of a network adapter to view and toggle which protocols were bound to it.

Because multiple protocols could theoretically resolve network names or service discovery requests, Windows 95 allowed administrators to configure the binding order. If a computer needed to connect to both a local Windows NT server running NetBEUI and a UNIX host running TCP/IP, the system queried protocols according to their binding priority. For NetBIOS applications, users could designate one protocol as the default NetBIOS transport, reducing broadcast traffic and latency across the local segment.