3.4.6 Bindable Net Rule

The syntax for a bindable entry is defined as follows:

bindable: REG_MULTI_SZ :  [FromClass    ToClass    [non|exclusive]    Value    [non|exclusive] Value]….

FromClass 
Matches the ClassName specification in the class net rule for this component. FromClass binds to ToClass.
ToClass
Specifies the ClassName of another component on which this component depends.

The ToClass value must be the ClassName specification of another component under that component's class net rule.

non|exclusive
Specifies the (in)dependencies between the FromClass and ToClass components. One of these values must be specified for each FromClass and ToClass in the list, as follows:
  • The initial non XOR exclusive specifies whether the component designated by FromClass can bind itself to other components than the given ToClass.

  • The subsequent non XOR exclusive specifies whether the component designated by ToClass can be bound to by components other than FromClass.

A NIC driver specifies one or more bindable net rules, each with a FromClass that is the driver name, such as xxxDriver, and a ToClass the name of an adapter the driver controls, such as xxx1Adapter, xxx2Adapter, and so forth. Usually, a NIC driver specifies non for its FromClass, because NIC drivers typically can bind to (in other words, control) more than one model of adapter. The NIC driver typically specifies exclusive for ToClass, because an adapter can be bound to only by one NIC driver at a time.

The bindable entry for a transport protocol driver is more complex because it is bound to by one or more services and because the transport binds itself to one or more underlying NDIS drivers. A transport typically specifies non for the FromClass (transport) if it can bind to other NIC drivers and non for the underlying NIC driver if the NIC can be bound to by other transports. Otherwise, a transport specifies exclusive for the FromClass if that transport can bind itself only to a specific NIC driver designated by the ToClass, and exclusive for the ToClass if the underlying NIC is a transport-dedicated device. Such a pair of closely coupled, interdependent drivers are very rare.

Value
Indicates the relative importance of the binding, effectively specifying whether this binding should be chosen or dropped if there is another competing binding of lesser or greater value. A Value in the range 1 to 100 can be used to weight the choice of a binding. A higher value indicates a higher importance is assigned to a particular binding.

A value other than 100 is occasionally used to force an exclusive binding between components to form a monolithic network stack. A NIC driver, intermediate, or transport driver typically specifies Value as 100. With this default, the various bindings expressed in the registry are used without any relative weighting among them.

Examples of Bindable Net Rule

The following examples show how bindable is specified in the registry for certain system network drivers, also shown in the preceding bindform rule examples, under their respective ..\NameOfComponent\NetRules keys:

  1. The NIC driver for the ee16 adapter has the entry
    bindable : REG_MULTI_SZ : ee16Driver ee16Adapter non exclusive 100

    This entry specifies that the ee16 driver can bind to an ee16 adapter but possibly also to other adapters. The ee16 adapter, however, is limited to binding to the ee16 driver.

  2. The Nbf transport has no bindable entry in the registry. This transport does not attempt to limit the devices it binds to, nor the services that can bind to it.

  3. The TCP/IP transport has the entry
    bindable : REG_MULTI_SZ : tcpipService tcpipTransport non exclusive 100 tcpipTransport ndisDriver non non 100 

    This rule specifies that the higher level tcpService can possibly bind itself to other transport drivers (non), but the tcpipTransport driver can only be bound to by the tcpService (exclusive). This rule also specifies the interdependency between the TCP/IP transport and lower network drivers. The tcpipTransport driver can bind itself to any (or all) lower network component(s) in the class ndisDriver, but this transport potentially can bind itself to other underlying types of drivers (non) as well. As expected, any driver in the class ndisDriver can be bound to by more transports (non) than just the tcpipTransport.