Dynamic Adapter Binding (Windows CE 5.0)

Send Feedback

The operating system includes an inherent dynamic adapter handling system that provides Plug and Play compatibility for built-in or removable network adapters. The operating system supports a set of new functions that allow protocol drivers greater control over the creation of adapter instances and over adapter binding and unbinding.

When a protocol driver registers with NDIS, the currently registered adapters are bound to the protocol through the BindAdapterHandler function, just as if the adapters were newly inserted PC Cards. Protocol drivers no longer require registry keys that specify the built-in adapter instances to which they must bind. A Plug and Play ready protocol driver can support dynamic binding to underlying network adapters by providing the ProtocolBindAdapter and ProtocolUnbindAdapter functions. NDIS calls the ProtocolBindAdapter function of a protocol driver to notify it that an adapter is available. The protocol can choose to ignore this notification or it can try to bind to the adapter by calling the NdisOpenAdapter function.

In Microsoft® Windows® CE 2.10 or earlier, NDIS informed the protocol driver of the presence of a new network adapter by calling the BindAdapterHandler function only if the network adapter was a removable PC Card. With Windows CE, this binding mechanism applies to built-in or removable adapters. That is, when a protocol driver registers with NDIS, it is informed about all current adapters through its BindAdapterHandler function. Except for IrDA, which statically binds to a single adapter and, thus, does not use the BindAdapterHandler function, driver developers can no longer control the binding mechanism by manipulating the protocol registry settings; however, you can use an alternative mechanism that enables driver developers to specify which adapters get bound to which protocols. You can define the protocols that an adapter is to bind to by specifying the required protocol in the HKEY_LOCAL_MACHINE\Comm\<Adapter Name>\Parms\UpperBind registry entry of the adapter. This entry corresponds to a MULTI_SZ value that lists the names of all of the protocols that should be informed about the presence of the adapter. If the first entry is NOT, then the remaining entries will list the protocols that should not be informed about the adapter. If this registry entry is not set for an adapter, then all of the protocol drivers will be informed about the adapter instance and might attempt to bind to it.

For information on device suspend prevention, see Suspend and Resume Handling.

See Also

Network Driver Programming Considerations | NdisOpenAdapter | ProtocolBindAdapter | ProtocolUnbindAdapter | SystemIdleTimerReset

Send Feedback on this topic to the authors

Feedback FAQs

© 2006 Microsoft Corporation. All rights reserved.