The Microsoft® Windows® 95 Setup program, the Control Panel, and the Plug and Play system use class installer dynamic-link libraries (DLLs) to install, remove, and configure hardware drivers for all types of hardware on the system. The network class installer (Netdi.dll) handles all network drivers and software components. The network components are divided into four types: network adapter drivers, transport drivers, client software, and other network services. Each type corresponds to a Windows 95 device class described by a Plug and Play INF file. The corresponding device class names are Net, NetTrans, NetClient, and NetService. Each network driver or software component must be specified in an INF file tagged as one of the four network classes.
The network class installer handles installation of all network drivers and components for all network hardware and software vendors. Both Microsoft internal components and third-party vendors should use the Microsoft network driver class installer for network driver installation in order to maintain maximum interoperability with other network components and with Windows 95 Plug and Play.
Most network drivers and software can fully specify their installation requirements and files by using network INF files. These requirements include the list of files to copy, registry entries to make, requirements and restrictions for interoperability and compatibility as well as scripts to describe user-modifiable parameters. Also, network INF files can manipulate text file and .ini files to add drivers to the configuration.
Drivers that have more complex requirements than the INF scripts can describe, such as custom user-interfaces or installation procedures, may register a Network Driver Installer (NDI) procedure to handle NDI messages. The NDI procedure allows you to customize many installation and configuration actions. A custom NDI procedure is optional: the default NDI procedure handles all configuration and installation functions based on information provided in the INF file. In this way, the custom procedure can pass any message along to the default procedure that it does not wish to handle, or it can perform special processing and then call the default handler. (This is a similar arrangement to a window procedure and the DefWindowProc.)