Dependency Handling for Network Components

Services can be dependent upon other services or drivers, which can be dependent upon others, and so on. The system can establish these types of dependencies:

Specific Dependencies

A specific dependency is simply the name of a necessary service. By default, the system generates explicit names for all dependent services discovered during bindings generation. Specific dependencies are marked in the Registry as a value of the Use entry under the component's NetRules subkey.

For example, assume the Workstation service is dependent upon NBF. NBF is connected to two adapter cards and so is dependent upon their drivers. The system will mark NBF as dependent upon the two network card drivers and will mark the Workstation service as dependent upon the network card drivers and NBF.

Group Dependencies

It often happens that a service should be loaded if any member of a set of dependencies successfully loads. In the previous example, the Workstation service would fail to load if either of the network card drivers failed to initialize.

Groups are used to support this approach. Any service (driver, transport, or whatever) can identify itself as being a member of a service group. All Windows NT network card drivers, for example, are treated as members of the group NDIS.

Group dependencies are marked in the Registry as a value of the Use entry under the component's NetRules subkey. Groups are symbolic names listed in the CurrentControlSet\Control\GroupOrderList subkey.

Static Dependencies

A static dependency is a required service in all circumstances and is unrelated to how the system otherwise determines bindings.

When the system computes dependencies, it discards any previously listed dependencies. To guarantee that a service is always configured to be dependent upon another service, the value entry OtherDependencies can be created under the component's Linkage subkey. OtherDependencies is a REG_MULTI_SZ value, so it can contain the names of as many services as needed.