How Windows 95 Stored TCP/IP in the Registry

Windows 95 represented a major milestone in personal computing by introducing a built-in 32-bit TCP/IP stack to mainstream users. Rather than relying on legacy configuration files like AUTOEXEC.BAT or SYSTEM.INI, the operating system centralized networking parameters within the Windows Registry. This article examines the structure, specific keys, and data formats Windows 95 used to store TCP/IP parameters, including IP addresses, DNS settings, default gateways, and DHCP information.

The Central Registry Hive

All network configuration details in Windows 95 were stored within the HKEY_LOCAL_MACHINE (HKLM) hive, serialized on disk within the SYSTEM.DAT file. The operating system organized networking settings into two primary areas: global protocol configurations and adapter-specific protocol bindings.

Global TCP/IP Configuration: MSTCP

The primary location for global TCP/IP parameters was:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\VxD\MSTCP

This key corresponded directly to the Microsoft TCP/IP virtual device driver (MSTCP.386). It maintained host-level networking parameters that applied across all network interfaces, including:

  • Hostname: A string value (REG_SZ) containing the local host name configured for DNS resolution.
  • Domain: A string specifying the local DNS domain suffix (e.g., example.com).
  • NameServer: A space- or comma-delimited string of IP addresses representing the active DNS servers (e.g., "192.168.1.1,192.168.1.2").
  • SearchList: A list of domain suffixes to append when attempting to resolve non-fully qualified domain names.
  • EnableDNS: A string flag ("1" or "0") indicating whether DNS name resolution was active.

Interface-Specific Settings: Class\NetTrans

While MSTCP held global options, adapter-specific IP configurations—such as static IP addresses and subnet masks—were tied directly to network protocol bindings located under:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Class\NetTrans

Under this path, Windows 95 created sequentially numbered four-digit subkeys (such as 0000, 0001, 0002) for each installed transport protocol. A subkey dedicated to TCP/IP typically contained a DriverDesc value set to "TCP/IP".

Within the relevant NetTrans\000x key, the following values dictated network addressing:

  • IPAddress: A comma-delimited string representing the assigned IP address (e.g., "192.168.1.50"). Windows 95 allowed multiple IP addresses per card, separated by commas.
  • IPMask: A comma-delimited string representing the subnet mask corresponding to each defined IP address (e.g., "255.255.255.0").
  • DefaultGateway: A string listing the gateway IP addresses to route non-local traffic.
  • NodeType: A string indicating the NetBIOS over TCP/IP (NetBT) node type (1 = B-node, 2 = P-node, 4 = M-node, 8 = H-node).

Dynamic Host Configuration Protocol (DHCP) Storage

When an interface was configured to obtain an address automatically via DHCP, the configuration values changed format. The static IPAddress key was often set to "0.0.0.0".

The dynamic configuration leased from the server was tracked by the virtual DHCP driver (VDHCP.386) and written to the registry under the corresponding adapter and MSTCP keys using dynamic parameters:

  • DhcpIPAddress: The assigned temporary IP address leased from the server.
  • DhcpSubnetMask: The subnet mask assigned by the DHCP scope.
  • DhcpDefaultGateway: The gateway provided by DHCP options.
  • DhcpServer: The IP address of the responding DHCP server.
  • Lease: A binary or DWORD value recording the lease duration.
  • LeaseObtained: A timestamp tracking when the current lease was granted.

Application and Persistence

When changes were made via the Network Control Panel applet (ncpa.cpl), the interface wrote these values directly to the corresponding keys in HKLM. Because the Windows 95 TCP/IP stack was loaded into kernel memory via 32-bit Virtual Device Drivers (VxDs) during the bootstrap process, modifications to these registry keys rarely took effect dynamically. A full system reboot was typically required to reload MSTCP.386 and rebind the stack with the newly defined Registry settings.