How Windows 95 Handled HOSTS File Name Resolution

In Windows 95, background network name resolution using the local HOSTS file relied on the Windows Sockets (Winsock 1.1) architecture and the operating system's 32-bit preemptive multitasking capabilities. When an application requested a network address asynchronously, Winsock managed the query off the main application thread, parsing the flat HOSTS text file located in the Windows directory before falling back to remote protocols such as DNS. This system allowed the operating system to resolve static mappings instantly and silently without blocking the user interface or stalling concurrent network traffic.

The Winsock Resolution Architecture

Windows 95 introduced WSOCK32.DLL, a 32-bit implementation of the Windows Sockets API that worked alongside the underlying MSTCP virtual device driver (MSTCP.386). When an application needed to translate a human-readable hostname into an IPv4 address, it interfaced directly with Winsock.

Winsock followed a strict, predefined search order for TCP/IP host name resolution:

  1. Local hostname check (resolving the machine's own name).
  2. The local HOSTS file.
  3. Domain Name System (DNS) servers.
  4. NetBIOS name resolution mechanisms (WINS, broadcast, and LMHOSTS), if configured as a hybrid node.

Because the HOSTS file was prioritized immediately after the local machine name, any entry matching the requested hostname bypassed external network traffic entirely.

Asynchronous Processing with WSAAsyncGetHostByName

In earlier 16-bit Windows environments, standard name resolution calls like gethostbyname() were blocking functions that could freeze an application while awaiting disk or network I/O. Windows 95 addressed this through the asynchronous function WSAAsyncGetHostByName().

When an application initiated a background resolution request:

  1. Initiation: The application called WSAAsyncGetHostByName(), passing a window handle (HWND), a notification message ID, a target buffer, and the hostname to resolve.
  2. Task Delegation: Winsock allocated an internal task handle and immediately returned control to the application thread. The application continued executing its primary operations, such as redrawing the graphical interface.
  3. Background Execution: Winsock utilized an internal background worker thread to process the resolution.
  4. File Access: The background process opened C:\WINDOWS\HOSTS directly via the 32-bit VFAT file system driver. It performed a linear, line-by-line text scan, stripping comment lines (denoted by #) and evaluating whitespace-delimited tokens matching the target string.
  5. Completion Notification: Once a matching IP address was found (or the end of the file was reached without a match), the Winsock subsystem posted a Windows message (uMsg) back to the application's message queue via PostMessage(). The application’s message loop then unpacked the resolved hostent structure from the designated buffer.

File Parsing and Performance Characteristics

The Windows 95 HOSTS parsing engine was intentionally lightweight:

  • Location: The file was permanently mapped to the root system folder, typically C:\WINDOWS\HOSTS, with no file extension.
  • Lack of In-Memory Caching: Unlike modern operating systems, Windows 95 did not maintain a persistent DNS client service or a RAM cache for HOSTS file contents. Every single resolution request that reached the HOSTS stage re-read the file directly from storage.
  • Sequential Parsing: Processing was strictly sequential. Entries placed at the very top of the HOSTS file resolved measurably faster than entries located at the bottom of long files.

If the background thread completed its read of the entire HOSTS file without locating the target hostname, it quietly terminated that stage of the pipeline and transitioned to dispatching UDP packets to the primary DNS server defined in the Network Control Panel applet.