Hi all,
I am reading up NDIS drivers. One thing that dtuck me as strange is why do
they have seperae implementations of most support libraries like
NdisZeroMemory(…) etc. Why can’t we use RtlXXX(…) for them?
Can some one throw some light on this issue please?
A P
NDIS is a driver model which achieves platform neutrality by sandboxing the
APIs used to a small and controlled subset. If you look at ndis.h you will
see that many of the support routines are trivially implemented (on NT) with
RtlXxxx, KeXxxx, or ExXXX equivalents. On other systems that use NDIS, the
mappings are different but the driver source code remains largely the same.
How about looking at it this way: If you are writing an NDIS driver and
need to zero some memory, what is wrong with NdisZeroMemory()?
If you find that you *must* use a system routine not exposed in a platform
neutral way in an NDIS driver, well, realize you just stopped being and NDIS
driver (and in most cases, cannot get signed as such).
Note: NDIS drivers are miniports. Protocol drivers are platform drivers
with an NDIS ‘edge’, not NDIS drivers per-se.
good luck,
dave cattley
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of A P
Sent: Tuesday, December 19, 2006 6:24 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] NdisXXX(…)
Hi all,
I am reading up NDIS drivers. One thing that dtuck me as strange is why do
they have seperae implementations of most support libraries like
NdisZeroMemory(…) etc. Why can’t we use RtlXXX(…) for them?
Can some one throw some light on this issue please?
A P
— Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256 To unsubscribe, visit the List
Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
“David R. Cattley” wrote in message news:xxxxx@ntdev…
>
> How about looking at it this way: If you are writing an NDIS driver and
> need to zero some memory, what is wrong with NdisZeroMemory()?
>
> If you find that you must use a system routine not exposed in a
> platform
> neutral way in an NDIS driver, well, realize you just stopped being and
> NDIS
> driver (and in most cases, cannot get signed as such).
>
Actually, you can get it signed as an NDIS-WDM driver depending on the
circumstances. I’ve argued against the NDIS and storage port approach for
quite a while, since many of the calls are wrappers. In particular there
are reasons that the environment should be eliminated, in particular:
1. There are a significant number of calls that have modifications to
their semantics. For instance list operations in NDIS will return NULL for
an empty list, and in WDM the list needs to be tested for empty. Having
too models causes bugs, that are all too common.
2. There is a lot effort put into handling extensions for the
port/miniport models. Everything from people writing their own storage
port drivers because they needed to go beyond the mini-port model, to
NDIS-WDM in instances where it was not originally intended and then having
to argue with WHQL about signing. This is rather stupid when a driver is
only targeted for the 2000/XP/2003/Vista environment. Yes, there needs to
be a well defined subset for support in WinCE, but that is a small set of
the drivers, and should not dominate the effort.
3. How many times have people asked for books on the subjects of
network and storage drivers. If the port / miniport model was replaced
with a library with only the nessecary stuff for subsystem, I suspect we
would see the inclusion of chapters on how to do this in a number of books.
Note: I have written an NDIS/WDM mini-port with roughly 20 NDIS calls
total. We don’t need the complexity of multiple models, hopefully if KMDF
moves into these areas we can eliminate the legacy of DOS/Windows 3.1 and
move to a consistent model.
–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
http://www.windrvr.com
Remove StopSpam from the email to reply
>sandboxing the APIs used to a small and controlled subset.
isnt that what all libraries try to do?
If you are writing an NDIS driver and need to zero some memory, what is
wrong with NdisZeroMemory()?
nothing wrong, just that when u are migrating from a diff stack to ndis, u
feel curios as to he benifit of the same.
I do have a strong intution that there is much more erason behind it, tahn
just name sake!
yes, the reason is source code compability across multiple platforms. if
you were ‘migrating’ a NIC driver from NT to WinCE, for instance, the source
code can be largely the same.
good luck,
-dave
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of A P
Sent: Tuesday, December 19, 2006 8:56 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] NdisXXX(…)
sandboxing the APIs used to a small and controlled subset.
isnt that what all libraries try to do?
If you are writing an NDIS driver and need to zero some memory, what is
wrong with NdisZeroMemory()?
nothing wrong, just that when u are migrating from a diff stack to ndis, u
feel curios as to he benifit of the same.
I do have a strong intution that there is much more erason behind it, tahn
just name sake!
— Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256 To unsubscribe, visit the List
Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
Don,
Just explaining - no justifying 
As an ‘ndis guy’ I must say I am satisfied that ‘my’ miniport model does not
try to solve the storage stack’s problems at the expense of narrowing the
platform breadth. That said, I hesitated to mention NDIS-WDM in my previous
post but I am glad you kept the discussion rouned out here. NDIS-WDM, of
course, works only on NT5 and W98SE+ (yawn) where as NDIS alone can manage
NT3.x, W95+, NT4, NT5, and CE. Since the current NDIS versions have all had
their first cut on NT, the mappings on NT are pretty efficient (almost
trivial) and if you forego binary compatibility (reasonable for all except
miniports) then you get “MACRO” versions inlined the very same RtlXxx &
KeXxx routines you would have used anyway. The effort to stitch an NDIS
edge to a WDM or KMDF edge is relatively modest and already well ‘sampled’
in the DDKs. In the case of NDIS-WDM or NDIS-KMDF the turbulence in the
intersection is pretty minor. Since storage is not my gig, I can only
empathise and with the issues in that world.
And as for that NDIS book… Heck, if we were sure that the 10 people that
would ‘buy’ it would not also have to be given free copies because they were
also the reviewers, maybe… But really, the DDK docs and samples in the
NDIS world have generally been pretty solid stuff. Sure, everyone wants to
know how to make PASSTHRU do silly things but is that a book? (yes, a career
ending book!)
Cheers,
-dave
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Don Burn
Sent: Tuesday, December 19, 2006 8:47 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] NdisXXX(…)
“David R. Cattley” wrote in message news:xxxxx@ntdev…
>
> How about looking at it this way: If you are writing an NDIS driver
> and need to zero some memory, what is wrong with NdisZeroMemory()?
>
> If you find that you must use a system routine not exposed in a
> platform neutral way in an NDIS driver, well, realize you just stopped
> being and NDIS driver (and in most cases, cannot get signed as such).
>
Actually, you can get it signed as an NDIS-WDM driver depending on the
circumstances. I’ve argued against the NDIS and storage port approach for
quite a while, since many of the calls are wrappers. In particular there
are reasons that the environment should be eliminated, in particular:
1. There are a significant number of calls that have modifications to
their semantics. For instance list operations in NDIS will return NULL for
an empty list, and in WDM the list needs to be tested for empty. Having too
models causes bugs, that are all too common.
2. There is a lot effort put into handling extensions for the
port/miniport models. Everything from people writing their own storage port
drivers because they needed to go beyond the mini-port model, to NDIS-WDM in
instances where it was not originally intended and then having to argue with
WHQL about signing. This is rather stupid when a driver is only targeted
for the 2000/XP/2003/Vista environment. Yes, there needs to be a well
defined subset for support in WinCE, but that is a small set of the drivers,
and should not dominate the effort.
3. How many times have people asked for books on the subjects of
network and storage drivers. If the port / miniport model was replaced with
a library with only the nessecary stuff for subsystem, I suspect we would
see the inclusion of chapters on how to do this in a number of books.
Note: I have written an NDIS/WDM mini-port with roughly 20 NDIS calls total.
We don’t need the complexity of multiple models, hopefully if KMDF moves
into these areas we can eliminate the legacy of DOS/Windows 3.1 and move to
a consistent model.
–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting http://www.windrvr.com
Remove StopSpam from the email to reply
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer