What are the list of potential reasons one cannot or should not use KMDF for a driver and instead opt for the legacy ddk API’s?
Might be easier to answer if you describe what your project entails,
what device class it is in, and what your requirements are.
d
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@email.com
Sent: Saturday, June 09, 2007 10:06 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Reasons NOT to use KMDF
What are the list of potential reasons one cannot or should not use KMDF
for a driver and instead opt for the legacy ddk API’s?
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
> What are the list of potential reasons one cannot or should not use KMDF for a driver…
I am afraid you put your question a bit to the extreme - I cannot think of any reason why one
"cannot or should not " use KMDF, although I can name some reasons why someone *may* want to avoid it…
For example, some people (like myself) just prefer to do things at the lowest possible level, and avoid frameworks of any description in order to enjoy more flexibility (although it depends on what you are up to - if you write a driver that needs to deal with the power management, using KMDF may be not a bad option at all). Furthermore, don’t forget that any software may have some bugs in it, so that any extra layer of abstraction that simplifies the development at the same time increases the probability of integrating someone else’s bugs into your driver - after all, every coin has two sides of it…
In any case, I would not recommends KMDF to anyone who wants to learn how to write drivers -
taking into account the fact that your first driver projects are very unlikely to be the commercial ones(i.e. when you are pressed hard to do the development as fast as you can), I think it is better to spend some extra time writing code and watching the blue screen, so that you will eventually understand what is going on and what should be done. As they say, no pain, no gain…
Anton Bassov
I respectfully disagree. One of the major design goals for KMDF is that
it should be used for first time driver developers and then using the
stable basis of KMDF, branch out into other areas of interest, whatever
if may be. Certainly debugging bugs and understanding low level system
designs are essential for writing a good driver, but those skills come
with and making mistakes. KMDF lets you make fewer initial mistakes,
the number of mistakes you can make in a WDM driver is huge.
d
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@hotmail.com
Sent: Saturday, June 09, 2007 11:16 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Reasons NOT to use KMDF
What are the list of potential reasons one cannot or should not use
KMDF for a driver…
I am afraid you put your question a bit to the extreme - I cannot think
of any reason why one
"cannot or should not " use KMDF, although I can name some reasons why
someone *may* want to avoid it…
For example, some people (like myself) just prefer to do things at the
lowest possible level, and avoid frameworks of any description in order
to enjoy more flexibility (although it depends on what you are up to -
if you write a driver that needs to deal with the power management,
using KMDF may be not a bad option at all). Furthermore, don’t forget
that any software may have some bugs in it, so that any extra layer of
abstraction that simplifies the development at the same time increases
the probability of integrating someone else’s bugs into your driver -
after all, every coin has two sides of it…
In any case, I would not recommends KMDF to anyone who wants to learn
how to write drivers -
taking into account the fact that your first driver projects are very
unlikely to be the commercial ones(i.e. when you are pressed hard to do
the development as fast as you can), I think it is better to spend some
extra time writing code and watching the blue screen, so that you will
eventually understand what is going on and what should be done. As they
say, no pain, no gain…
Anton Bassov
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
> Might be easier to answer if you describe what your project
entails what device class it is in, and what your requirements are
I just want to know general suitability, not for a specific project. All things equal I would like to select KMDF in future drivers, but I need to know its limits and other areas to consider before selecting it. It would be nice if such a checklist was published somewhere. I can think of a few considerations:
-
KMDF cannot be used for boot start drivers. I would guess things like disk filters and other drivers that start around that time cannot use KMDF. Thus, I would like to know the line in technical terms of how early KMDF drivers can be loaded.
-
The giant support binary adds a lot of bloat that may be unexepcted and undesirable for size sensitive distributions.
-
UMDF for instance does not work on Windows 2003
-
Anton might have a point because Doron your analogy is so familiar it’s scary. For instance, my first Win32 project I used MFC. It was great as a newbie until something didn’t work and then I couldn’t understand how to fix it because it was hiding how things worked under the covers. I was totally disconnected. Not having the source code will make such situations even tougher to solve for people who don’t know what’s going on beneath it.
eof
> One of the major design goals for KMDF is that it should be used for first time driver
developers and then using the stable basis of KMDF, branch out into other areas of
interest, whatever if may be.
Certainly, if your very first driver experience happens to be a commercial product, you should DEFINITELY use KMDF - you just cannot afford to learn things the hard way because of the time constraints. I just made an assumption (apparently, judging from quite a few posts on OSR and ‘drivers’ NGs, quite bold one) that a serious company would not make a complete newbie write commercial-grade drivers, so that one would do his first-time driver development in his spare time and proceed to the commercial stuff only after having gained at least some basic knowledge of driver development…
KMDF lets you make fewer initial mistakes, the number of mistakes you can make in a
WDM driver is huge.
This is true…
However, I would say that WDM is the best when it comes to introduction to the general kernel-mode concepts (i.e. what can and what cannot be done at what IRQL; what one should do if current IRQL is too high for the requested operation and how the target operation can be postponed until IRQL drops to the level when it becomes possible; inter-processor synchronization issues, etc,etc,etc). These topics seem to be properly explained only in WDM documentation. This is why I take attempts to write, say, NDIS drivers by newbies rather sceptically, although NDIS is pretty much a world on its own - no matter what you do, you just need to know the general kernel-mode concepts in order to write a workable driver, and WDM documentation covers them fairly well…
Actually, the only thing I dislike about KMDF is that it can make a general impression that writing drivers is not that complex job, so that more and more newbies will be appointed to write commercial-grade drivers, and, hence, we will see more and more “my driver don’t work… please help… excuse my bad english” - style posts. Certainly, I don’t mind their questions, but I do mind the necessity of having to worry about the possible presence of their “masterpieces” in the same stack with my driver…
Anton Bassov
wrote in message news:xxxxx@ntdev…
>
> However, I would say that WDM is the best when it comes to introduction
> to the general kernel-mode concepts (i.e. what can and what cannot be
> done at what IRQL; what one should do if current IRQL is too high for the
> requested operation and how the target operation can be postponed until
> IRQL drops to the level when it becomes possible; inter-processor
> synchronization issues, etc,etc,etc). These topics seem to be properly
> explained only in WDM documentation. This is why I take attempts to
> write, say, NDIS drivers by newbies rather sceptically, although NDIS is
> pretty much a world on its own - no matter what you do, you just need to
> know the general kernel-mode concepts in order to write a workable
> driver, and WDM documentation covers them fairly well…
>
Actually, I have to strongly disagree. WDM is terrible for general
kernel-mode concepts, since you spend most of your time dealing with PnP.
Now, if you had argued about legacy NT model, I would have accpected this.
The problem, is that since its inception, WDM has a requirement that makes
a basic but complete driver huge. The great thing about KMDF, is you can
push all the PnP stuff off to the framework, but still use WDM for all
things down and dirty with the device or the system if you want. Yes the
KMDF documentation does not cover multi-processor sync completely, because
except for simple models, you are expected to dive into WDM.
Those of us who watched the evolution of KMDF from its first NDA session at
WinHEC 2002 to its release last year appreciate all the efforts the
development team made to make sure this was a framework you could easily
step out of. You can think of KMDF as IoPPSQ if you want to, i.e.
PnP/Power Safe Queue’s the same way most of use would not roll our own with
IoCSQ’s in WDM. Now there is a lot more to KMDF that just IoPPSQ, but if
you just use that you have still reduced your headaches and improved your
drivers reliability significantly.
–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply
Comments inline:
wrote in message news:xxxxx@ntdev…
>> Might be easier to answer if you describe what your project
>> entails what device class it is in, and what your requirements are
>
> I just want to know general suitability, not for a specific project. All
> things equal I would like to select KMDF in future drivers, but I need to
> know its limits and other areas to consider before selecting it. It would
> be nice if such a checklist was published somewhere. I can think of a few
> considerations:
>
> 1) KMDF cannot be used for boot start drivers. I would guess things like
> disk filters and other drivers that start around that time cannot use
> KMDF. Thus, I would like to know the line in technical terms of how early
> KMDF drivers can be loaded.
Sure it can be used for boot time drivers. There are some problems with
text mode install, but this is more of a bug than a restriction.
> 2) The giant support binary adds a lot of bloat that may be unexepcted
> and undesirable for size sensitive distributions.
The support binary is there anyway since Microsoft is shipping more and
more drivers with KMDF in the stock distributions.
> 3) UMDF for instance does not work on Windows 2003
So until now the questions were KMDF, don’t throw in UMDF to justify KMDF
decisions.
> 4) Anton might have a point because Doron your analogy is so familiar
> it’s scary. For instance, my first Win32 project I used MFC. It was great
> as a newbie until something didn’t work and then I couldn’t understand
> how to fix it because it was hiding how things worked under the covers. I
> was totally disconnected. Not having the source code will make such
> situations even tougher to solve for people who don’t know what’s going
> on beneath it.
>
Sorry, if you believe this then do not write in the kernel until you have
negotiated a source license for Windows. All KMDF is is another kernel
layer, the same as many other functions (if you step through a DDI in
assembler, you will probably recognize a lot of the calls). Yes, I wish
the documentation was better because there are places you will probably get
caught, but the pain is still a lot less than rolling the huge state
machine you need to do it raw.
Yes, I would like to see the source published, but I will then get sick and
tired of seeing postings “but when I looked at the source for versiion XXX
I found I could rely on it doing …, why did Microsoft break it in version
YYY”. When the item being relied on was never documented to work that way.
One of the great things about KMDF is that Doron, Elyias and others are
willing to not only look things up, but will try to convey the model behind
it, those of us who struggled with the early DDK documentation know how
precious this is.
–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply
KMDF for first-time driver writers:
ALMOST CERTAINLY! I’ve written about this at great length. See my previous postings here on this group and at http://www.osronline.com/article.cfm?article=489
Here at OSR, we teach people how to write Windows drivers. We’ve been doing this now for more than 10 years.
WDM: The amount of information one needs to master (not just become informed of, but actually MASTER) is *enormous* – As anybody who does it knows, it’s very, very, easy to make a subtle mistake. Think I exaggerate? Try explaining I/O Completion to a noob (assuming you understand it well enough to be able to do so!). See?
KMDF: The amount of information you need to know or master is MUCH lower. The level of consistency is much higher. The mistakes you make using the Framework are *much* more limited, MUCH easier to identify. Here’s how you explain I/O Completion to a noob learning KMDF: “If you get a request, you always must complete it by calling WdfRequestComplete (or a simialr function).”
In our experience teaching KMDF to newbies, we see that most mistakes they make are in the building/debugging process (installing and updating their driver, using WinDbg, etc). Actual KMDF errors are quite easily solved.
OTOH… Anton DOES have a point. If a noob learns KMDF, what they’re really learning is mostly tool kit syntax. They learn how to instantiate Framework Objects, register Event Processing Callbacks, and how to service events in those Callbacks. They’re not learning the subtleties of the underlying Windows architecture or I/O Subsystem. While they’ll grasp some of the fundamentals, they won’t *really* grok the underlying concepts. Compare, for example, the outlines for OSR’s WDM and WDF driver seminars (see www.osr.com) – You’ll see what I’m talking about.
Peter
OSR
>
Sorry, if you believe this then do not write in the kernel until you have
negotiated a source license for Windows. All KMDF is is another kernel
layer, the same as many other functions (if you step through a DDI in
assembler, you will probably recognize a lot of the calls). Yes, I wish
the documentation was better because there are places you will probably
get
caught, but the pain is still a lot less than rolling the huge state
machine you need to do it raw.Yes, I would like to see the source published, but I will then get sick
and
tired of seeing postings “but when I looked at the source for versiion XXX
I found I could rely on it doing …, why did Microsoft break it in
version
YYY”. When the item being relied on was never documented to work that
way.
One of the great things about KMDF is that Doron, Elyias and others are
willing to not only look things up, but will try to convey the model
behind
it, those of us who struggled with the early DDK documentation know how
precious this is.
This is the most frighting part…
If I’ve to hatch patterns, what are the expected ones ?
-
The very first you spelled out here
-
Well I found a bug ( or work around ) to get my driver works and I need
to change ver M.N of X framework and redistribute with my driver(s), how
could I do that? Doron help me out ! BTW, Doron I can not tell you what
was the change and what my driver is supposed to add on the existing
windows, since I’ve an NDA with my company. And also we can not wait for
you guys to take a look and comeback. It’s kinda urgent, and I know you
understand it very well. So I kinda appreciate a quick way to dispatch the
modified binaries of X framework to customers. -
I heard the X frameworks src code is published and those guys next to
my office are really happy dudes, and I’m using framework Y, and there is
no src code for it. Man what a luck I have. BTW, could you please please
tell me when you gentle folks going publish the source of framework Y. -
Now you guys already have X and Y published, but I find it hard to
figure out my bug with a very complex interaction with I/O Manager.
Actually I’m not sure how the whole APC works, so I need to step thru that
part of the code in source mode …
etc …
These could be very hypothetical in general, but I would be the first one
to go in that direction, simply because I need source for NDIS, Filter
Manager, and I would love to have the src for ntfs and the object manager
please…
Finally if I don’t get the src, I’m afraid I will to L*x coding…
If I’m very powerful or if the audience is polite I might not hear
anything. But I’ve a feeling that the whole world would reply to my final
stmt ( silently ) as " WHO THE F* CARES … go and go right now …
-pro
Request: Can we move the KMDF Source Code discussion to the KMDF Source Code Discussion thread? That way we can have everything in one, easy to locate, place and point our friends in Redmond to it.
I’ve got a couple of answers for Don… I’ll reply on over on the other thread…
Peter
OSR
>
- KMDF cannot be used for boot start drivers. I would guess things
like disk filters and other drivers that start around that time cannot
use KMDF. Thus, I would like to know the line in technical terms of how
early KMDF drivers can be loaded.
I do not believe this is true. In fact I’ll go out on a limb and declare that kmdf drivers can of course be boot start.
“For a boot driver, the loading scenario is different because the KMDF run-time library must be loaded before the driver. At installation, the co-installer reads the INF (or the registry) to determine whether the driver is a boot driver. If so, the co-installer both changes the start type of the KMDF service so that the Windows loader starts it at boot time and sets its load order so that it is loaded before the client driver.”
http://download.microsoft.com/download/9/c/5/9c5b2167-8017-4bae-9fde-d599bac8184a/KMDF-arch.doc
- The giant support binary adds a lot of bloat that may be unexepcted
and undesirable for size sensitive distributions.
The bloat is amortized over all KMDF drivers and can be ignored. This is not 1990. PCs have gigs of ram and 100s of gigs of disk space. Bloat? See vista. Bloat is so 20th century.
- UMDF for instance does not work on Windows 2003
You just changed subjects. Yes I would not rush into UMDF for this reason.
- Anton might have a point because Doron your analogy is so familiar
it’s scary. For instance, my first Win32 project I used MFC. It was
great as a newbie until something didn’t work and then I couldn’t
understand how to fix it because it was hiding how things worked under
the covers. I was totally disconnected. Not having the source code will
make such situations even tougher to solve for people who don’t know
what’s going on beneath it.
You do not have the source code for the WDK either. I happen to agree about the source issue being a problem, but given the fact that KMDF reduces the complexity of the source-less WDK, I do not see this as a show-stopping reason to avoid KMDF, merely an annoyance that should be done away with.
eof
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
Peter,
As anybody who does it knows, it’s very, very, easy to make a subtle mistake.
Think I exaggerate? Try explaining I/O Completion to a noob (assuming you understand
it well enough to be able to do so!). See?
Actually, quite a few problems may result not even from internal WDM complexity but purely from the lack of proper documentation. You gave just a wonderfull example - indeed, you have no chance to fully understand I/O Completion unless you see what IoCompleteRequest() actually does, and it somehow happens to be different from what MSDN describes. Few months ago I had a discussion with Calvin Guan about IoMarkIrpPending() in a completion routine - according to MSDN, you have to call it in a completion routine if Irp->PendingReturned is set, so that I quoted MSDN. However, Calvin were saying that there is no need for it whatsoever, and even gave an example of a situation when doing it will result in BSOD (i.e. if you have allocated IRP yourself and did not reserve an extra stack location in it - actually, this part was obvious anyway, so that I did not argue with Calvin here).
As it eventually turned out, Calvin was absolutely correct - Elyas Yakub got involved in our discussion,
and provided a relevant code snippet of IoCompleteRequest() implementation. Indeed, IoCompleteRequest() copies the state of PendingReturned flag to IRP from the current stack location before calling a completion routine, then calls a completion routine, and then,
if Irp->PendingReturned is set and IRP still has stack locations available, calls IoMarkIrpPending() itself right after IO completion routine returns control, i.e. your call to it is just unnecessary anyway.
This part is pretty harmless, but, in addition to learning about IoMarkIrpPending() , you also see why PDEVICE_OBJECT that is passed to the completion routine may be NULL (it happens if no more stack locations in IRP are left). This one is already much more serious - you are going to bluescreen if you don’t know this part, and MSDN does not seem to mention the very possibility of PDEVICE_OBJECT being NULL, let alone explaining why it happens…
They learn how to instantiate Framework Objects, register Event Processing Callbacks, and how > to service events in those Callbacks. They’re not learning the subtleties of the
underlying Windows architecture or I/O Subsystem.
Actually, my main concern here is not how well KMDF protects them from the rest of the system, but how well it protects *US* if our drivers have a misfortune to be on the same stack with theirs…
Anton Bassov
Doron Holan wrote:
Certainly debugging bugs and understanding low level system
designs are essential for writing a good driver, but those skills come
with and making mistakes. KMDF lets you make fewer initial mistakes,
the number of mistakes you can make in a WDM driver is huge.
True! I just finished up my third week as a driver developer, with my first driver almost complete using KMDF (it will start out being used internally but will probably become a commercial product). KMDF was extremely helpful preventing the “initial mistakes” - in fact, yesterday I set up WinDbg for the *first time ever* to track down a bug. One little bug, which the framework was nice enough to DbgPrint a warning about - I just grabbed the KMDF WPP log using WinDbg and it quickly revealed the problem.
Slightly off-topic: are there .ctl files for the KMDF WPP logs? I tried to grab the logs using tracelog/traceview, but there doesn’t seem to be enough information provided with the KMDF to make this possible. So I had to set up WinDbg with a remote debugging session, etc., which seems a bit of overkill just to watch some trace statements… I saw on various newsgroups that others had the same problem.
Anton Bassov wrote:
These topics seem to be properly explained only in WDM documentation.
Again true, but I don’t see anything wrong with this. I have the MS WDF book, but I also have Oney’s WDM and a couple older WDM books, which I referenced once or twice during my project. It is true that the KMDF docs don’t cover all the details, but they are covered in the WDM docs, and the KMDF docs usually had links into the WDM docs where necessary. So, I was quite satisfied with the scope of the KMDF docs.
Anton Bassov wrote:
Actually, the only thing I dislike about KMDF is that it can make a
general impression that writing drivers is not that complex job, so
that more and more newbies will be appointed to write commercial-grade
drivers
and Peter wrote:
While they’ll grasp some of the fundamentals, they won’t *really* grok
the underlying concepts.
It’s true that KMDF reduces the learning curve of kernel-mode (that’s what it’s for, after all). So, this will result in an increase of newbies. However, I believe that most people understand that writing real device drivers is still complex.
However, there’s another class of programmers that I think will account for a lot of the newbies attracted by KMDF: software-only device programmers. KMDF does really make those quite simple.
I’m planning to write a series of articles over the next month on writing software-only device drivers using KMDF. Hopefully, this will reduce the amount of newbie questions that don’t have to do with real device driver writing.
-Steve Cleary
Couldn’t agree more here with Don. I would strengthen it, and say
simply that WDM bites. In my mind, KMDF v. WDM is no choice at all. As
to whether one newly involved in drivers should go the NT4 model or
KMDF, I really don’t know, but I think it depends on what you want and
how much time you have. Under any sort of time pressure, the answer is,
in my mind, clearly KMDF. I think we all agree on the last part.
mm
>> xxxxx@acm.org 2007-06-10 09:10 >>>
wrote in message news:xxxxx@ntdev…
>
> However, I would say that WDM is the best when it comes to
introduction
> to the general kernel-mode concepts (i.e. what can and what cannot be
> done at what IRQL; what one should do if current IRQL is too high for
the
> requested operation and how the target operation can be postponed
until
> IRQL drops to the level when it becomes possible; inter-processor
> synchronization issues, etc,etc,etc). These topics seem to be
properly
> explained only in WDM documentation. This is why I take attempts to
> write, say, NDIS drivers by newbies rather sceptically, although NDIS
is
> pretty much a world on its own - no matter what you do, you just need
to
> know the general kernel-mode concepts in order to write a workable
> driver, and WDM documentation covers them fairly well…
>
Actually, I have to strongly disagree. WDM is terrible for general
kernel-mode concepts, since you spend most of your time dealing with
PnP.
Now, if you had argued about legacy NT model, I would have accpected
this.
The problem, is that since its inception, WDM has a requirement that
makes
a basic but complete driver huge. The great thing about KMDF, is you
can
push all the PnP stuff off to the framework, but still use WDM for all
things down and dirty with the device or the system if you want. Yes
the
KMDF documentation does not cover multi-processor sync completely,
because
except for simple models, you are expected to dive into WDM.
Those of us who watched the evolution of KMDF from its first NDA
session at
WinHEC 2002 to its release last year appreciate all the efforts the
development team made to make sure this was a framework you could
easily
step out of. You can think of KMDF as IoPPSQ if you want to, i.e.
PnP/Power Safe Queue’s the same way most of use would not roll our own
with
IoCSQ’s in WDM. Now there is a lot more to KMDF that just IoPPSQ, but
if
you just use that you have still reduced your headaches and improved
your
drivers reliability significantly.
–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam 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
“Martin O’Brien” wrote in message
news:xxxxx@ntdev…
> Couldn’t agree more here with Don. I would strengthen it, and say
> simply that WDM bites. In my mind, KMDF v. WDM is no choice at all. As
> to whether one newly involved in drivers should go the NT4 model or
> KMDF, I really don’t know, but I think it depends on what you want and
> how much time you have. Under any sort of time pressure, the answer is,
> in my mind, clearly KMDF. I think we all agree on the last part.
>
> mm
Actually, I still write a number of software only drivers with the legacy
model. I rarely can find justification for a software only driver to be
anything other than legacy (note the rarely, this is not an absolute). But
if you are dealing with real hardware I would definitely go with KMDF or
UMDF.
–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply
I would agree with this also. Didn’t realize that this was on the
table. Software only is 90% of what I do.
mm
>> xxxxx@acm.org 2007-06-10 15:22 >>>
“Martin O’Brien” wrote in message
news:xxxxx@ntdev…
> Couldn’t agree more here with Don. I would strengthen it, and say
> simply that WDM bites. In my mind, KMDF v. WDM is no choice at all.
As
> to whether one newly involved in drivers should go the NT4 model or
> KMDF, I really don’t know, but I think it depends on what you want
and
> how much time you have. Under any sort of time pressure, the answer
is,
> in my mind, clearly KMDF. I think we all agree on the last part.
>
> mm
Actually, I still write a number of software only drivers with the
legacy
model. I rarely can find justification for a software only driver to be
anything other than legacy (note the rarely, this is not an absolute).
But
if you are dealing with real hardware I would definitely go with KMDF
or
UMDF.
–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam 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
Don Burn wrote:
Actually, I still write a number of software only drivers with the legacy
model. I rarely can find justification for a software only driver to be
anything other than legacy (note the rarely, this is not an absolute). But
if you are dealing with real hardware I would definitely go with KMDF or
UMDF.
I’ve been wondering that all through this thread. I have to write a
software only driver. Should I use legacy or KMDF? It has to work
under 64bit Vista - only under 64bit Vista.
Cheers,
Paul.
What exactly do you mean with ‘software only driver’, does that include
filter drivers ?
/Daniel
“Don Burn” wrote in message news:xxxxx@ntdev…
> Actually, I still write a number of software only drivers with the legacy
> model. I rarely can find justification for a software only driver to be
> anything other than legacy (note the rarely, this is not an absolute).
> But if you are dealing with real hardware I would definitely go with KMDF
> or UMDF.
>
>
> –
Assuming you don’t mean filter or something like that, in my opinion,
just use a NT4 style driver.
mm
>> xxxxx@glidos.net 2007-06-10 16:00 >>>
Don Burn wrote:
Actually, I still write a number of software only drivers with the
legacy
model. I rarely can find justification for a software only driver to
be
anything other than legacy (note the rarely, this is not an
absolute). But
if you are dealing with real hardware I would definitely go with KMDF
or
UMDF.
I’ve been wondering that all through this thread. I have to write a
software only driver. Should I use legacy or KMDF? It has to work
under 64bit Vista - only under 64bit Vista.
Cheers,
Paul.
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