Fair enough, Doron, about COM, that is. My assumption was that the dev
was interested in learning to write drivers in general, which is why I
said UMDF might not be the best choice in that case, but I definitely
see your point about going from user to kernel. My statement about
support for UMDF is based on reading this list, because there is to date
one book on the subject, and fewer samples in the WDK. In my opinion,
there is more material about KMDF than UMDF, and it’s not even close. I
don’t personally see any obvious reason why that would change, but, as
you correctly pointed out, I hadn’t considered the idea of user mode
developers writing drivers. I have to say that I still have my doubts,
but only time will tell.
Overall, what I was trying to say was that, assuming interest in drivers
in general (which may not be correct), given that he knows neither, I
would personally chose KMDF over UMDF.
mm
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
Sent: Thursday, July 26, 2007 12:40
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] UMDF Timer,
I take a bit of exception to what you wrote. UMDF and KMDF are the
same, they present the same rules, structure and programming patterns.
They differ in how they expose their APIs and callbacks, but if you look
at the COM vs flat APIs/callbacks, they match nearly 1:1. As for public
support, both the KMDF and UMDF dev and test teams are on NTDEV and
always ready to help. As for you guys helping UMDF folks, I think that
will grow in time, just like in the beginning very few non MSFT folks
answered KMDF questions.
In my mind, that is a real issue, as I’ve yet to meet the kernel
developer who would rather spend his or her
time doing COM.
You are missing the point. The point of UMDF is to help programmers
used to COM and writing normal UM applications to be able to write
driver, to lower the barrier of entry in writing a UMDF driver. Having
a KM driver writer move up and dealing with COM was secondary.
d
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Martin O’Brien
Sent: Wednesday, July 25, 2007 5:56 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] UMDF Timer,
Let me preface all of this by saying that I really don’t much about
UMDF.
For WDF, I believe that is all there is at the moment. The OSR book is
forthcoming. It sounds like you’ve got the right idea about how to
begin - using samples and the WDK. Unless you have a specific reason
for using UMDF, it is, in my opinion, probably not the best thing to
learn first. I may be easier or harder; I really don’t know. I don’t
know very much about UMDF. The two issues, in my mind, are that most
drivers can’t be written in UMDF, and, in my opinion, not very many
people on this list are presently using UMDF, and I’m not sure how much
that is going to change among existing driver writers (total opinion),
as the implementation is quite different from KMDF, and, for reasons
that I will never understand, Microsoft has once again chosen to base
another technology on COM. In my mind, that is a real issue, as I’ve
yet to meet the kernel developer who would rather spend his or her time
doing COM. So, all in all, there are considerably fewer resources for
UMDF than KMDF. While the same argument can be made for KMDF v. other
driver styles - and that is a real issue at the moment - in my opinion,
overall, KMDF is well worth it, because it really is nice. If this is
your first driver and you are using software only samples, I personally
would consider starting with a native NT style driver (like IOCTL)
purely as a one time step, because it is less of a learning curve than
KMDF is initially, and then look at KMDF once you feel that you have a
grip on the environment. The reason I say this is because, truth be
told, the real learning curve is going to be learning to use WinDbg for
kernel debugging, and the simplest driver possible as a first step is
paramount. That being said, for software only drivers, all the
frameworks, in my opinion, result in something that is harder to
understand than a native DDK style driver. Once hardware comes in to
play, KMDF is clearly the way to go.
mm
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@yahoo.com
Sent: Wednesday, July 25, 2007 20:32
To: Windows System Software Devs Interest List
Subject: [ntdev] UMDF Timer,
Hi,
Just trying to get to grips with driver development. Working my way
through some of the skeletion examples etc.
I’m trying to make a software only UMDF driver and I want a implement a
timer so i can do work periodicaily.
Where should this timer be implemented. CMyDriver::Initialize in
driver.cpp??
And the function I want the timer to trigger where does could that go.
Maybe I’m trying to run before I can crawel here, so if someone could
point be towards some reading material on software only drivers I would
be much appricated. Or an Example of a timer implementation would be
great.
Have already ordered “Developing Drivers with the Microsoft Windows
Driver Foundation” Should i just hold out for that.
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
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
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