During network reconfiguration (that is, when you use the Network icon in Control Panel to make changes), the system reads the values stored in the NetRules subkeys for information used to bind the network components. The Registry path for these value entries is the following:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft
\driverName\CurrentVersion\NetRules
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion
\NetworkCards\netcard#\NetRules
Bindable REG_MULTI_SZ fromClass toClass Yes|No Yes|No value
Defines a possible binding and its constraints. For example:
bindable = ndisDriver ndisAdapter non exclusive 100
This example specifies that components of class "ndisDriver" can be bound to those of class "ndisAdapter." For the other fields in this example:
Because this value entry is a REG_MULTI_SZ, as many criteria for binding as necessary can be defined by a single component.
This value entry is optional, because there are a few predefined binding rules, and binding rules defined anywhere in the system apply to all network component classes.
Bindform REG_SZ ObjectName Yes|No Yes|No [container|simple|streams]
The ObjectName field contains the name (or name prefix) by which the component is identified by the system. This value must be the same as the name in the related CurrentControlSet\Services subkey. Names for adapters are created by the system and override the Bindform setting.
The first Yes|No pair indicates whether the component is to receive binding information directly in its Linkage subkey. The second Yes|No pair indicates whether the device name is supposed to appear in generated binding strings.
The final optional value in this entry indicates how binding device names are constructed. This value is required for software components.
Class REG_MULTI_SZ NewClassName OldClassName|basic [Yes|No]
Allows a component to define a new class. As many new classes as necessary can be defined by any component.
Note These classes are not related to the OLE and DDE classes defined under HKEY_LOCAL_MACHINE\SOFTWARE\Classes.
Class names do not need to be defined within any particular component. The system adds the new definition to its database without regard to origin. The order of Class entries is irrelevant. However, results are indeterminate if classes are referred to that are not defined anywhere in the system.
This entry is optional, because there are a few predefined classes, and class definitions made anywhere in the system apply to all network components. Because any network component can define new classes, be careful that the names used are unique within all possible installable network components. The following shows the predefined class names in the first release of Windows NT. This list, of course, cannot be exhaustive.
Predefined class | Adapter card type |
ee16Driver; ee16Adapter | Intel EtherExpress 16 LAN adapter |
elnkiiAdapter; elinkiiDriver | 3Com Etherlink II® adapter |
ibmtokDriver; ibmtokAdapter | IBM Token Ring adapter |
lanceDriver; dec101Adapter | DEC Lance adapter |
lt200Driver; lt200Adapter | Daystar Digital LocalTalk adapter |
ne2000Driver; ne2000Adapter | Novell NE2000 adapter |
proteonDriver; p1390Adapter | Proteon adapter |
ubDriver; ubAdapter | Ungermann-Bass Ethernet NIUpc adapter |
wdlanDriver; smcisaAdapter | SMC® (WD) adapter |
The final optional value indicates whether this class is a "logical end-point" for the bindings protocol; the default value is No.
Hidden REG_DWORD 0 or 1
Suppresses the display of the component (adapter or network software) in the Network dialog box in Control Panel.
Usually, all networking components discovered in the Registry are displayed in the two list boxes in the Network dialog box in Control Panel. Setting this value to 1 prevents the item from being displayed, which means it cannot be configured or removed by the user.
Interface REG_MULTI_SZ
Allows a single component to make available more than one type of capability to other components in the system. The format for this value is:
Interface = interfaceName upperClass "objectName" namingMethod
Value | Meaning |
interfaceName | The tokenized name of the secondary interface. |
upperClass | The class to which the interface belongs. (LowerClass is the same as the primary interface.) |
objectName | The Windows NT device name to be created. |
namingMethod | Determines how the bindings appear. |
Review REG_DWORD 0 or 1
Indicates whether a component requests bindings review. If set to 1 (or nonzero), the system reinvokes this component's .INF file after bindings have been changed. This allows network components to modify the binding information or request additional information from administrators about the new or altered connections.
Type REG_SZ component className [lowerClass]
Defines the type of the component in terms of abstract network component classes. If the optional lower class name is absent, the first (or upper level) class type name is used for both its upper and lower classes.
This value is required for network software and network adapter cards.
Component type | Meaning |
Adapter | A piece of hardware |
Driver | A software component associated directly with a piece of hardware |
Transport | A software component used by services |
Service | A software component providing capability directly to user applications |
Basic | A token used to represent a fundamental class name (that is, a class with no parent) |
Use REG_SZ service|driver|transport|adapter [Yes|No] [Yes|No]
Defines the role played by the component. If this entry is absent, the value of Service is assumed. This value entry only appears for software items.
A hardware device is automatically assumed to be an adapter. Each network component may identify itself as a driver, transport, or service to clarify its role. This distinction is as follows (note the lowercase for the values):
Value | Meaning |
driver | Exists only to support one or more adapters. If no bindings are generated (or permitted by the user) that include a particular driver, that driver is not loaded. However, no error is generated, since no "denial of service" has occurred. |
service | Provides end-user functionality, and every attempt is made to support its operation. An EventLog entry is generated if a service is present in the system for which there is no available transport (the number of possible bindings is zero). |
transport | Exists only to support services. Like a driver, it is not loaded unless necessary. |
The final two Yes|No values in this entry are optional; if present; each must be either Yes or No. The first value indicates whether driver group names are used instead of specific driver dependencies. The second value indicates whether transport group names are used instead of specific transport dependencies. These values cause the system to generate references to dependencies based upon their group names, not by their specific service names.
For example, the LanmanServer is marked as Yes Yes; this means that its transport and driver dependencies are at the group level; so LanmanServer will be loaded if any one of its transport dependencies and any one of its driver dependencies successfully load.