Hi All,
While going through NDIS part of DDK, I am more of shocked to find that for
almost every operation (synchronization, list manipulation etc.) it has it’s
own set of functions.
Can anybody please throw the light on “Why do we have a separate class of
APIs Ndis* for NDIS development?”
To be more specific, why do we have NdisInitializeListHead along with
InitializeListHead?
–
Amit Manocha
NDIS is a cross platform environment, it supports Win9x and
Windows NT based systems. Since the Win9X environment
did not have the same kernel, they made their own for everything.
For a good number of years now, there has been a WDM environment
for Win9X so the original reason went away, the NDIS team now tries
to claim that they are leaving hooks to support things like advanced
debugging and future interfaces. Problem with this claim is that they
have not done these things, and at the same time are blissfully unaware
of the regular kernel debugging capablilites.
For example meeting with them a while back, they insisted they needed
their own spin lock calls so they could do deadlock detection in the
future. When it was pointed out that driver verifier already did deadlock
detection, they were surprised, then said bad example, and moved away
from further discussion of this.
I was recently involved with a NDIS/WDM miniport driver that used less
than 20 NDIS calls for the complete implementation. The bottom line is t
he calls are not needed except in the minds of the NDIS group.
Don Burn
Windows 2k/XP/2k3 Filesystem and Driver Consulting
“Amit Manocha” wrote in message
news:LYRIS-796-107363-2003.05.02-08.33.02–burn#xxxxx@lists.osr.com…
> Hi All,
>
> While going through NDIS part of DDK, I am more of shocked to find that
for
> almost every operation (synchronization, list manipulation etc.) it has
it’s
> own set of functions.
> Can anybody please throw the light on “Why do we have a separate class of
> APIs Ndis* for NDIS development?”
>
> To be more specific, why do we have NdisInitializeListHead along with
> InitializeListHead?
>
> –
> Amit Manocha
>
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@acm.org
> To unsubscribe send a blank email to xxxxx@lists.osr.com
To understand the answer to this question, one must have some idea of origins of NDIS. I’ll write down what I know about it, and I’m sure others will jump in and flame me as needed 
NDIS is an acronym for “Network Driver Interface Specification”. It was intended to be cross-platform (DOS, Windows, OS/2, WinNT, W2K, …), and has gone through several evolutionary iterations. The core NT team at MS wanted to make networking an integrated part of the OS, but the Windows 3.x/9x group wanted to maintain the cross-platform semantics they had developed. The Windows 3.x/9x group won the ensuing political battle. If the core team had their way, you probably wouldn’t encounter things like you have described. Funny thing is that part of the outcome from the NT development was the MS divorce from IBM OS/2, which makes their argument all the more peculiar (to say the least).
Nowdays, I don’t know of any other “cross-platform” that NDIS runs on - it’s Windows only.
-----Original Message-----
From: Amit Manocha [mailto:xxxxx@mynetsec.com]
Sent: Friday, May 02, 2003 7:30 AM
To: NT Developers Interest List
Subject: [ntdev] NDIS APIs .
Hi All,
While going through NDIS part of DDK, I am more of shocked to find that for
almost every operation (synchronization, list manipulation etc.) it has it’s
own set of functions.
Can anybody please throw the light on “Why do we have a separate class of
APIs Ndis* for NDIS development?”
To be more specific, why do we have NdisInitializeListHead along with
InitializeListHead?
–
Amit Manocha
You are currently subscribed to ntdev as: xxxxx@interactivesi.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
On Fri, 2003-05-02 at 07:46, Don Burn wrote:
I was recently involved with a NDIS/WDM miniport driver that used less
than 20 NDIS calls for the complete implementation. The bottom line is t
he calls are not needed except in the minds of the NDIS group.
…and WHQL?
-sd
Yes, WHQL requires them for a pure NDIS call, but that is
dictated by the NDIS group’s mindset.
Don Burn
Windows 2k/XP/2k3 Filesystem and Driver Consulting
----- Original Message -----
From: “Steve Dispensa”
To: “NT Developers Interest List”
Sent: Friday, May 02, 2003 11:09 AM
Subject: [ntdev] Re: NDIS APIs .
> On Fri, 2003-05-02 at 07:46, Don Burn wrote:
> > I was recently involved with a NDIS/WDM miniport driver that used less
> > than 20 NDIS calls for the complete implementation. The bottom line is
t
> > he calls are not needed except in the minds of the NDIS group.
>
> …and WHQL?
>
> -sd
>
>
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@acm.org
> To unsubscribe send a blank email to xxxxx@lists.osr.com
Shocked!
I guess you have never worked on portable code. An NT NDIS driver
should compile under Windows 9x and Windows Me as well as all flavors
of NT.
By isolating the functions to a small subset, it allows for very easy
porting of code to other environments.
Jamey
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Amit Manocha
Sent: Friday, May 02, 2003 5:30 AM
To: NT Developers Interest List
Subject: [ntdev] NDIS APIs .
Hi All,
While going through NDIS part of DDK, I am more of shocked to find that
for
almost every operation (synchronization, list manipulation etc.) it has
it’s
own set of functions.
Can anybody please throw the light on “Why do we have a separate class
of
APIs Ndis* for NDIS development?”
To be more specific, why do we have NdisInitializeListHead along with
InitializeListHead?
–
Amit Manocha
You are currently subscribed to ntdev as: xxxxx@storagecraft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
Actually, it is a good idea to make it portable. We are working on a
design for a project that will allow you to build SCSI miniports in an
EFI BIOS environment; NDIS may also follow. All we need to do is build a
library for the support routines for EFI and then recompile existing
drivers under EFI.
Jamey
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Don Burn
Sent: Friday, May 02, 2003 8:24 AM
To: NT Developers Interest List
Subject: [ntdev] Re: NDIS APIs .
Yes, WHQL requires them for a pure NDIS call, but that is
dictated by the NDIS group’s mindset.
Don Burn
Windows 2k/XP/2k3 Filesystem and Driver Consulting
----- Original Message -----
From: “Steve Dispensa”
To: “NT Developers Interest List”
Sent: Friday, May 02, 2003 11:09 AM
Subject: [ntdev] Re: NDIS APIs .
> On Fri, 2003-05-02 at 07:46, Don Burn wrote:
> > I was recently involved with a NDIS/WDM miniport driver that used
less
> > than 20 NDIS calls for the complete implementation. The bottom line
is
t
> > he calls are not needed except in the minds of the NDIS group.
>
> …and WHQL?
>
> -sd
>
>
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@acm.org
> To unsubscribe send a blank email to xxxxx@lists.osr.com
—
You are currently subscribed to ntdev as: xxxxx@storagecraft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
To maintain binary-compatible miniports across NT and Win9x.
For instance, NDIS_BUFFER is completely different on these platforms -
it is MDL in NT, and proprietary structure in Win9x.
Max
----- Original Message -----
From: “Amit Manocha”
Newsgroups: ntdev
To: “NT Developers Interest List”
Sent: Friday, May 02, 2003 4:29 PM
Subject: [ntdev] NDIS APIs .
> Hi All,
>
> While going through NDIS part of DDK, I am more of shocked to find
that for
> almost every operation (synchronization, list manipulation etc.) it
has it’s
> own set of functions.
> Can anybody please throw the light on “Why do we have a separate
class of
> APIs Ndis* for NDIS development?”
>
> To be more specific, why do we have NdisInitializeListHead along
with
> InitializeListHead?
>
> –
> Amit Manocha
>
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@storagecraft.com
> To unsubscribe send a blank email to
xxxxx@lists.osr.com
Yes, portability is a good thing, but there is little value in the
NDIS calls, and one could claim WDM is portable.
Now contrast that with the pain of dealing with a similar but
different set of calls for NDIS versus the kernel in general.
It is amazing how many NDIS developers forget that removing
an entry from a doubly linked list in WDM does not return NULL
but in NDIS it does. Now consider an NDIS/WDM driver you
have to carefully choose which version of a call to use, since in
many cases there is no blessed way to access the underlying kernel
structure in the NDIS wrapper.
Now throw in that the NDIS team is talking about signicant changes
with NDIS 6.0 that will require developers to rework their drivers,
isn’t it about time that the base primitives such as memory allocation,
synchronization, etc be migrated to the underlying technology.
Additionally, consider things like buffer management, which could
use some calls to expose the underly kernel mechanisms to the user.
Oh, yeah you mentioned SCSI, how many times does this group or
the newsgroups see a request for how to do a virtual SCSI miniport.
Bottom line is here is another case, where the old portablility layer
should be replaced with something that reflects the kernel API’s.
All current Microsoft OS’s support WDM (and some of the retired
ones do also), why do we need to struggle with compatibility layers
for needs that have not been present for some time.
Don Burn
Windows 2k/XP/2k3 Filesystem and Driver Consulting
----- Original Message -----
From: “Jamey Kirby”
To: “NT Developers Interest List”
Sent: Friday, May 02, 2003 12:07 PM
Subject: [ntdev] Re: NDIS APIs .
> Actually, it is a good idea to make it portable. We are working on a
> design for a project that will allow you to build SCSI miniports in an
> EFI BIOS environment; NDIS may also follow. All we need to do is build a
> library for the support routines for EFI and then recompile existing
> drivers under EFI.
>
> Jamey
>
Agreed.
So what does NDIS need to be portable to anymore? OS/2?
-----Original Message-----
From: Don Burn [mailto:xxxxx@acm.org]
Sent: Friday, May 02, 2003 11:27 AM
To: NT Developers Interest List
Subject: [ntdev] Re: NDIS APIs .
Yes, portability is a good thing, but there is little value in the
NDIS calls, and one could claim WDM is portable.
Now contrast that with the pain of dealing with a similar but
different set of calls for NDIS versus the kernel in general.
It is amazing how many NDIS developers forget that removing
an entry from a doubly linked list in WDM does not return NULL
but in NDIS it does. Now consider an NDIS/WDM driver you
have to carefully choose which version of a call to use, since in
many cases there is no blessed way to access the underlying kernel
structure in the NDIS wrapper.
Now throw in that the NDIS team is talking about signicant changes
with NDIS 6.0 that will require developers to rework their drivers,
isn’t it about time that the base primitives such as memory allocation,
synchronization, etc be migrated to the underlying technology.
Additionally, consider things like buffer management, which could
use some calls to expose the underly kernel mechanisms to the user.
Oh, yeah you mentioned SCSI, how many times does this group or
the newsgroups see a request for how to do a virtual SCSI miniport.
Bottom line is here is another case, where the old portablility layer
should be replaced with something that reflects the kernel API’s.
All current Microsoft OS’s support WDM (and some of the retired
ones do also), why do we need to struggle with compatibility layers
for needs that have not been present for some time.
Don Burn
Windows 2k/XP/2k3 Filesystem and Driver Consulting
----- Original Message -----
From: “Jamey Kirby”
To: “NT Developers Interest List”
Sent: Friday, May 02, 2003 12:07 PM
Subject: [ntdev] Re: NDIS APIs .
> Actually, it is a good idea to make it portable. We are working on a
> design for a project that will allow you to build SCSI miniports in an
> EFI BIOS environment; NDIS may also follow. All we need to do is build a
> library for the support routines for EFI and then recompile existing
> drivers under EFI.
>
> Jamey
>
—
You are currently subscribed to ntdev as: xxxxx@interactivesi.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
> To be more specific, why do we have NdisInitializeListHead along with
InitializeListHead?
I don’t believe a good reason could be given. Some might claim platform
independence, others might claim a simplified API, both of these are
completely bogus if we are talking about NDIS, that is the NDIS that is
completely different from revision to revision and in which cross platform
binaries are in general not possible, and where possible are generally cut
short by WHQL. I think NDIS was originally an attempt at a some sort of
some sort of standard, but today it is a millstone around your neck. Happy
swimming.
–
Bill McKenzie
Compuware Corporation
Watch your IRPs/IRBs/URBs/NDIS pkts with our free WDMSniffer tool:
http://frontline.compuware.com/nashua/patches/utility.htm
I wrote a long response to these two posts, but I decided to not post
it; I think not posting it makes my point.
Jamey
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Vince Bridgers
Sent: Friday, May 02, 2003 9:40 AM
To: NT Developers Interest List
Subject: [ntdev] Re: NDIS APIs .
Agreed.
So what does NDIS need to be portable to anymore? OS/2?
-----Original Message-----
From: Don Burn [mailto:xxxxx@acm.org]
Sent: Friday, May 02, 2003 11:27 AM
To: NT Developers Interest List
Subject: [ntdev] Re: NDIS APIs .
Yes, portability is a good thing, but there is little value in the
NDIS calls, and one could claim WDM is portable.
Now contrast that with the pain of dealing with a similar but
different set of calls for NDIS versus the kernel in general.
It is amazing how many NDIS developers forget that removing
an entry from a doubly linked list in WDM does not return NULL
but in NDIS it does. Now consider an NDIS/WDM driver you
have to carefully choose which version of a call to use, since in
many cases there is no blessed way to access the underlying kernel
structure in the NDIS wrapper.
Now throw in that the NDIS team is talking about signicant changes
with NDIS 6.0 that will require developers to rework their drivers,
isn’t it about time that the base primitives such as memory allocation,
synchronization, etc be migrated to the underlying technology.
Additionally, consider things like buffer management, which could
use some calls to expose the underly kernel mechanisms to the user.
Oh, yeah you mentioned SCSI, how many times does this group or
the newsgroups see a request for how to do a virtual SCSI miniport.
Bottom line is here is another case, where the old portablility layer
should be replaced with something that reflects the kernel API’s.
All current Microsoft OS’s support WDM (and some of the retired
ones do also), why do we need to struggle with compatibility layers
for needs that have not been present for some time.
Don Burn
Windows 2k/XP/2k3 Filesystem and Driver Consulting
----- Original Message -----
From: “Jamey Kirby”
To: “NT Developers Interest List”
Sent: Friday, May 02, 2003 12:07 PM
Subject: [ntdev] Re: NDIS APIs .
> Actually, it is a good idea to make it portable. We are working on a
> design for a project that will allow you to build SCSI miniports in an
> EFI BIOS environment; NDIS may also follow. All we need to do is build
a
> library for the support routines for EFI and then recompile existing
> drivers under EFI.
>
> Jamey
>
—
You are currently subscribed to ntdev as: xxxxx@interactivesi.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
—
You are currently subscribed to ntdev as: xxxxx@storagecraft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com