I’m in the process of learning what’s required to update my driver to
use WSK and have been wondering if it’s currently being installed in the
best way: it’s a protocol driver that talks to userland via an LSP and
uses TDI and WFP to send and receive data over IP. At the moment I’m
installing it as a non-PnP driver and using “net start/stop” to control
it.
Since to the user it’s a protocol driver I’m wondering if there would
be any point in implementing NDIS functions to make it show up as a
protocol driver that can be installed via the adapter settings page,
or if I should leave it as a ‘legacy’ driver?
–
Bruce Cran
Bruce,
I think that you and your customers are the ones to answer that.
The only factor that I can think of that could make any difference would be
WHQL driver signing. But even there I think that either way that you go the
WHQL tests would be the same: The Unclassified test.
Thomas F. Divine
From: “Bruce Cran”
Sent: Tuesday, February 15, 2011 7:00 PM
To: “Windows System Software Devs Interest List”
Subject: [ntdev] Installing a non-NDIS protocol driver
> I’m in the process of learning what’s required to update my driver to
> use WSK and have been wondering if it’s currently being installed in the
> best way: it’s a protocol driver that talks to userland via an LSP and
> uses TDI and WFP to send and receive data over IP. At the moment I’m
> installing it as a non-PnP driver and using “net start/stop” to control
> it.
>
> Since to the user it’s a protocol driver I’m wondering if there would
> be any point in implementing NDIS functions to make it show up as a
> protocol driver that can be installed via the adapter settings page,
> or if I should leave it as a ‘legacy’ driver?
>
> –
> Bruce Cran
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
Adding to Thomas’ comments…
If the user perception is that the function is a ‘protocol’ and you want to provide control over it being installed and managed, then I would trend towards that control being exposed by the NetUI functionality.
As a protocol layered on IP you may need to add additional functionality to handle the concept of ‘binding’ to a network stack similar to how NBT does the same. If, for example, I disable (unbind) WINS or NBT from operation on a specific adapter, it does not effect anything like an NDIS binding. Instead it adjusts registry configuration information that WINS and NBT uses to determine if it should operate on a particular transport device - a thing exposed by TCPIP.
The NETTCPIP.INF might be a good place to expore the trade-offs and mechanisms of how a ‘protocol’ layered over TDI/WSK is bound into and/or exposed in NetUI for control.
Good Luck,
Dave Cattley