A while ago someone (Mark Roddy?) mentioned a kernel C++ library
developed by Oney.
Question was - is/will it be somehow available?
Any news?
[Alternatively, if we could only ask BB to work with Walter for
a couple of hours… The code will be GPLed, of course… ]
Walter is back in the driver business. He is hanging out on
microsoft.public.development.device.drivers. I would recommend asking him.
I believe the code was in relation to his book, so do not expect it to be
just handed over.
Hopefully the code is never GPL’ed ever, since it will then not be used for
commercial projects.
–
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
wrote in message news:xxxxx@ntdev…
>A while ago someone (Mark Roddy?) mentioned a kernel C++ library
> developed by Oney.
>
> Question was - is/will it be somehow available?
>
> Any news?
>
> [Alternatively, if we could only ask BB to work with Walter for
> a couple of hours… The code will be GPLed, of course…]
It was Walter’s own development library that he used to springboard many of
the examples in his book. Last comment from him was that, no, he would not
release it. That said … Mark Roddy has one at HollisTech.com. Go take a
look at that, but your best bet is to stay with KMDF and quit screwing
around. 
–
The personal opinion of
Gary G. Little
“Don Burn” wrote in message news:xxxxx@ntdev…
> Walter is back in the driver business. He is hanging out on
> microsoft.public.development.device.drivers. I would recommend asking
> him. I believe the code was in relation to his book, so do not expect it
> to be just handed over.
>
> Hopefully the code is never GPL’ed ever, since it will then not be used
> for commercial projects.
>
>
> –
> 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
>
> wrote in message news:xxxxx@ntdev…
>>A while ago someone (Mark Roddy?) mentioned a kernel C++ library
>> developed by Oney.
>>
>> Question was - is/will it be somehow available?
>>
>> Any news?
>>
>> [Alternatively, if we could only ask BB to work with Walter for
>> a couple of hours… The code will be GPLed, of course…]
>
>
>
> Hopefully the code is never GPL’ed ever
Looks like I forgot to add a to my suggestion…
-------------- Original message --------------
From: “Don Burn”
> Walter is back in the driver business. He is hanging out on
> microsoft.public.development.device.drivers. I would recommend asking him.
> I believe the code was in relation to his book, so do not expect it to be
> just handed over.
>
> Hopefully the code is never GPL’ed ever, since it will then not be used for
> commercial projects.
>
>
> –
> 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
>
> wrote in message news:xxxxx@ntdev…
> >A while ago someone (Mark Roddy?) mentioned a kernel C++ library
> > developed by Oney.
> >
> > Question was - is/will it be somehow available?
> >
> > Any news?
> >
> > [Alternatively, if we could only ask BB to work with Walter for
> > a couple of hours… The code will be GPLed, of course…]
>
>
>
> —
> 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
> but your best bet is to stay with KMDF and quit screwing around.
Unless of course you like to be able to debug crashes when they happen and
your running in a real enterprise. Then, without source, KMDF is a very
nice, but sadly unusable entity.
Bill M.
“Gary G. Little” wrote in message
news:xxxxx@ntdev…
> It was Walter’s own development library that he used to springboard many
> of the examples in his book. Last comment from him was that, no, he would
> not release it. That said … Mark Roddy has one at HollisTech.com. Go
> take a look at that, but your best bet is to stay with KMDF and quit
> screwing around.
>
> –
> The personal opinion of
> Gary G. Little
>
>
> “Don Burn” wrote in message news:xxxxx@ntdev…
>> Walter is back in the driver business. He is hanging out on
>> microsoft.public.development.device.drivers. I would recommend asking
>> him. I believe the code was in relation to his book, so do not expect it
>> to be just handed over.
>>
>> Hopefully the code is never GPL’ed ever, since it will then not be used
>> for commercial projects.
>>
>>
>> –
>> 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
>>
>> wrote in message news:xxxxx@ntdev…
>>>A while ago someone (Mark Roddy?) mentioned a kernel C++ library
>>> developed by Oney.
>>>
>>> Question was - is/will it be somehow available?
>>>
>>> Any news?
>>>
>>> [Alternatively, if we could only ask BB to work with Walter for
>>> a couple of hours… The code will be GPLed, of course…]
>>
>>
>>
>
>
>
> It was Walter’s own development library that he used to springboard many of
the examples in his book.
IIRC, we were talking about something new, not directly related to the book.
Mark Roddy has one at HollisTech.com.
Gut! [How did I miss it?]
quit screwing around.
If you say so…
-------------- Original message --------------
From: “Gary G. Little”
> It was Walter’s own development library that he used to springboard many of
> the examples in his book. Last comment from him was that, no, he would not
> release it. That said … Mark Roddy has one at HollisTech.com. Go take a
> look at that, but your best bet is to stay with KMDF and quit screwing
> around.
>
> –
> The personal opinion of
> Gary G. Little
>
>
> “Don Burn” wrote in message news:xxxxx@ntdev…
> > Walter is back in the driver business. He is hanging out on
> > microsoft.public.development.device.drivers. I would recommend asking
> > him. I believe the code was in relation to his book, so do not expect it
> > to be just handed over.
> >
> > Hopefully the code is never GPL’ed ever, since it will then not be used
> > for commercial projects.
> >
> >
> > –
> > 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
> >
> > wrote in message news:xxxxx@ntdev…
> >>A while ago someone (Mark Roddy?) mentioned a kernel C++ library
> >> developed by Oney.
> >>
> >> Question was - is/will it be somehow available?
> >>
> >> Any news?
> >>
> >> [Alternatively, if we could only ask BB to work with Walter for
> >> a couple of hours… The code will be GPLed, of course…]
> >
> >
> >
>
>
>
> —
> 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
Eris, but I’m sick of hearing this. KMDF is just *exactly* as unusable
as Windows itself in this regard. You can’t step into the version of
(hypothetical example) ZwOpenFile that MS just changed in the latest
hotfix either.
The only reason for rejecting KMDF in a “real enterprise” is that
perhaps you think it’s less stable because it’s such new code. Of
course, vast swaths of Vista were (re)written from scratch too… and by
people some of whom I’m willing to bet are much less skilled programmers
than the KMDF team… so maybe that’s off limits too…
KMDF is just part of the OS. It calls your driver code slightly
differently than the WDM part of the OS, but there’s nothing unique
about that.
Bill McKenzie wrote:
> but your best bet is to stay with KMDF and quit screwing around.
Unless of course you like to be able to debug crashes when they happen and
your running in a real enterprise. Then, without source, KMDF is a very
nice, but sadly unusable entity.Bill M.
“Gary G. Little” wrote in message
> news:xxxxx@ntdev…
>> It was Walter’s own development library that he used to springboard many
>> of the examples in his book. Last comment from him was that, no, he would
>> not release it. That said … Mark Roddy has one at HollisTech.com. Go
>> take a look at that, but your best bet is to stay with KMDF and quit
>> screwing around.
>>
>> –
>> The personal opinion of
>> Gary G. Little
>>
>>
>> “Don Burn” wrote in message news:xxxxx@ntdev…
>>> Walter is back in the driver business. He is hanging out on
>>> microsoft.public.development.device.drivers. I would recommend asking
>>> him. I believe the code was in relation to his book, so do not expect it
>>> to be just handed over.
>>>
>>> Hopefully the code is never GPL’ed ever, since it will then not be used
>>> for commercial projects.
>>>
>>>
>>> –
>>> 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
>>>
>>> wrote in message news:xxxxx@ntdev…
>>>> A while ago someone (Mark Roddy?) mentioned a kernel C++ library
>>>> developed by Oney.
>>>>
>>>> Question was - is/will it be somehow available?
>>>>
>>>> Any news?
>>>>
>>>> [Alternatively, if we could only ask BB to work with Walter for
>>>> a couple of hours… The code will be GPLed, of course…]
>>>
>>>
>>
>>
>
>
>
–
Ray
(If you want to reply to me off list, please remove “spamblock.” from my
email address)
About the vast swaths of Vista which were rewritten: there is a vast code
base of twenty years of application programming from the real world which
they and the world uses as a test case. And about calling KMDF just
*exactly* as usuable as ZwOpenFile, apart from the latter having matured for
twenty years and this being brand new, this is also not a base kernel API
but a framework built on top of it which is a huge difference.
When you find yourself on a quagmire, it might take a while before you find
out while your sinking more and more below which means it can be too late to
go back . And if you find yourself in the dark, which means no source, the
only thing left you do is turn back if things under your feet are starting
to feel just a bit wobbly or things are starting to smell funny.
For a better comparison with some other recently introduced framework: for a
lot of those who trusted in the minifilter model and recklessly embraced it
back then, it may now be far too late to turn unless it’s to stone.
/Daniel
“Ray Trent” wrote in message
news:xxxxx@ntdev…
> Eris, but I’m sick of hearing this. KMDF is just exactly as unusable as
> Windows itself in this regard. You can’t step into the version of
> (hypothetical example) ZwOpenFile that MS just changed in the latest
> hotfix either.
>
> The only reason for rejecting KMDF in a “real enterprise” is that perhaps
> you think it’s less stable because it’s such new code. Of course, vast
> swaths of Vista were (re)written from scratch too… and by people some of
> whom I’m willing to bet are much less skilled programmers than the KMDF
> team… so maybe that’s off limits too…
>
> KMDF is just part of the OS. It calls your driver code slightly
> differently than the WDM part of the OS, but there’s nothing unique about
> that.
>
> Bill McKenzie wrote:
>>> but your best bet is to stay with KMDF and quit screwing around.
>>
>> Unless of course you like to be able to debug crashes when they happen
>> and your running in a real enterprise. Then, without source, KMDF is a
>> very nice, but sadly unusable entity.
>>
>> Bill M.
>>
>>
>> “Gary G. Little” wrote in message
>> news:xxxxx@ntdev…
>>> It was Walter’s own development library that he used to springboard many
>>> of the examples in his book. Last comment from him was that, no, he
>>> would not release it. That said … Mark Roddy has one at
>>> HollisTech.com. Go take a look at that, but your best bet is to stay
>>> with KMDF and quit screwing around.
>>>
>>> –
>>> The personal opinion of
>>> Gary G. Little
>>>
>>>
>>> “Don Burn” wrote in message news:xxxxx@ntdev…
>>>> Walter is back in the driver business. He is hanging out on
>>>> microsoft.public.development.device.drivers. I would recommend asking
>>>> him. I believe the code was in relation to his book, so do not expect
>>>> it to be just handed over.
>>>>
>>>> Hopefully the code is never GPL’ed ever, since it will then not be used
>>>> for commercial projects.
>>>>
>>>>
>>>> –
>>>> 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
>>>>
>>>> wrote in message news:xxxxx@ntdev…
>>>>> A while ago someone (Mark Roddy?) mentioned a kernel C++ library
>>>>> developed by Oney.
>>>>>
>>>>> Question was - is/will it be somehow available?
>>>>>
>>>>> Any news?
>>>>>
>>>>> [Alternatively, if we could only ask BB to work with Walter for
>>>>> a couple of hours… The code will be GPLed, of course…]
>>>>
>>>>
>>>
>>>
>>
>>
>>
>
> –
> Ray
> (If you want to reply to me off list, please remove “spamblock.” from my
> email address)
>
Periodically a question receives the rather dumb answer “You should use
KMDF” (or some other new framework MS developed).
These frameworks help solve *specific* problems (they are not clearly
stated in the docs). If you tread away from those narrow
paths, you find yourself in deep stuff.
Oh yeah… There are computers out there that don’t have Vista installed
and they have the numbers.
Just ask yourself *why are there so many driver models* (keyboard,
video, network, etc)
The only real benefit KMDF brings is the handling of power and pnp
complications.
Andrei
PS: take a look at the new IP helper API; all the callback types lack
the calling convention definition and guess what, it’s not working
Or the older CreateNamedPipe has a nice parameter “dwOpenMode” and two
flags sharing the same value 0x80000. (FILE_FLAG_FIRST_PIPE_INSTANCE,
WRITE_OWNER)
Daniel Terhell wrote:
About the vast swaths of Vista which were rewritten: there is a vast
code base of twenty years of application programming from the real
world which they and the world uses as a test case. And about calling
KMDF just *exactly* as usuable as ZwOpenFile, apart from the latter
having matured for twenty years and this being brand new, this is also
not a base kernel API but a framework built on top of it which is a
huge difference.When you find yourself on a quagmire, it might take a while before you
find out while your sinking more and more below which means it can be
too late to go back . And if you find yourself in the dark, which
means no source, the only thing left you do is turn back if things
under your feet are starting to feel just a bit wobbly or things are
starting to smell funny.For a better comparison with some other recently introduced framework:
for a lot of those who trusted in the minifilter model and recklessly
embraced it back then, it may now be far too late to turn unless it’s
to stone./Daniel
“Ray Trent” wrote in message
> news:xxxxx@ntdev…
>> Eris, but I’m sick of hearing this. KMDF is just exactly as
>> unusable as Windows itself in this regard. You can’t step into the
>> version of (hypothetical example) ZwOpenFile that MS just changed in
>> the latest hotfix either.
>>
>> The only reason for rejecting KMDF in a “real enterprise” is that
>> perhaps you think it’s less stable because it’s such new code. Of
>> course, vast swaths of Vista were (re)written from scratch too… and
>> by people some of whom I’m willing to bet are much less skilled
>> programmers than the KMDF team… so maybe that’s off limits too…
>>
>> KMDF is just part of the OS. It calls your driver code slightly
>> differently than the WDM part of the OS, but there’s nothing unique
>> about that.
>>
>> Bill McKenzie wrote:
>>>> but your best bet is to stay with KMDF and quit screwing around.
>>>
>>> Unless of course you like to be able to debug crashes when they
>>> happen and your running in a real enterprise. Then, without source,
>>> KMDF is a very nice, but sadly unusable entity.
>>>
>>> Bill M.
>>>
>>>
>>> “Gary G. Little” wrote in message
>>> news:xxxxx@ntdev…
>>>> It was Walter’s own development library that he used to springboard
>>>> many of the examples in his book. Last comment from him was that,
>>>> no, he would not release it. That said … Mark Roddy has one at
>>>> HollisTech.com. Go take a look at that, but your best bet is to
>>>> stay with KMDF and quit screwing around.
>>>>
>>>> –
>>>> The personal opinion of
>>>> Gary G. Little
>>>>
>>>>
>>>> “Don Burn” wrote in message news:xxxxx@ntdev…
>>>>> Walter is back in the driver business. He is hanging out on
>>>>> microsoft.public.development.device.drivers. I would recommend
>>>>> asking him. I believe the code was in relation to his book, so do
>>>>> not expect it to be just handed over.
>>>>>
>>>>> Hopefully the code is never GPL’ed ever, since it will then not be
>>>>> used for commercial projects.
>>>>>
>>>>>
>>>>> –
>>>>> 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
>>>>>
>>>>> wrote in message news:xxxxx@ntdev…
>>>>>> A while ago someone (Mark Roddy?) mentioned a kernel C++ library
>>>>>> developed by Oney.
>>>>>>
>>>>>> Question was - is/will it be somehow available?
>>>>>>
>>>>>> Any news?
>>>>>>
>>>>>> [Alternatively, if we could only ask BB to work with Walter for
>>>>>> a couple of hours… The code will be GPLed, of course…]
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>> –
>> Ray
>> (If you want to reply to me off list, please remove “spamblock.” from
>> my email address)
>>
>
>
> —
> 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
>
>Eris, but I’m sick of hearing this. KMDF is just *exactly* as unusable as
Windows itself in this regard.
I am sick of hearing people recommend KMDF versus getting a handle on the
complexities of WDM, which they will need anyway. I guess we will both just
have to remain sick.
There is one, rather outstanding, difference between KMDF and Windows’ other
APIs or DDIs today. Namely, I can choose not to use it.
I don’t as much worry about the stability of KMDF as I do the available
resources for it. There is well over ten years of collective experience
with WDM and the other driver models to build from. KMDF? Well we have
Doron, Peter W., et al…for now. And on the topic of stability who knows?
It seems pretty good so far, but I wouldn’t bet my enterprise on it
yet…especially without being able to look at it. Even the best developers
make mistakes. These guys are some of the best…but they made mistakes
that is a mathematical certainty.
And, the biggest issue I have with KMDF is that it is now a complete
departure away from its stated goal. The whole idea of KMDF, at least as it
was presented to me, was to help make 3rd party drivers more robust. I
don’t believe now, that that was ever really the intention. If it were, why
would you not release source to the framework? If for no other reason,
think about the literally thousands of existing WDM drivers that cannot
afford a complete rewrite in a new framework, but COULD quite reasonably
benefit from the learnings that could be had from the source of KMDF. The
KMDF group has uncovered what many of us have been begging for for years and
that is all of the undocumented interdependencies of PnP, Power and I/O.
Why not let the rest of us, the third party driver developers, in on the
secrets?
The KMDF group did a phenominal job on this framework right up and to the
point of not pushing hard enough for source release. So now, the whole
thing is a wash IMHO. Until you have to use it for Logo purposes, I think
you would be crazy to use it. That is my personal take, and my
recommendation to anyone who asks.
Bill M.
“Ray Trent” wrote in message
news:xxxxx@ntdev…
> Eris, but I’m sick of hearing this. KMDF is just exactly as unusable as
> Windows itself in this regard. You can’t step into the version of
> (hypothetical example) ZwOpenFile that MS just changed in the latest
> hotfix either.
>
> The only reason for rejecting KMDF in a “real enterprise” is that perhaps
> you think it’s less stable because it’s such new code. Of course, vast
> swaths of Vista were (re)written from scratch too… and by people some of
> whom I’m willing to bet are much less skilled programmers than the KMDF
> team… so maybe that’s off limits too…
>
> KMDF is just part of the OS. It calls your driver code slightly
> differently than the WDM part of the OS, but there’s nothing unique about
> that.
>
> Bill McKenzie wrote:
>>> but your best bet is to stay with KMDF and quit screwing around.
>>
>> Unless of course you like to be able to debug crashes when they happen
>> and your running in a real enterprise. Then, without source, KMDF is a
>> very nice, but sadly unusable entity.
>>
>> Bill M.
>>
>>
>> “Gary G. Little” wrote in message
>> news:xxxxx@ntdev…
>>> It was Walter’s own development library that he used to springboard many
>>> of the examples in his book. Last comment from him was that, no, he
>>> would not release it. That said … Mark Roddy has one at
>>> HollisTech.com. Go take a look at that, but your best bet is to stay
>>> with KMDF and quit screwing around.
>>>
>>> –
>>> The personal opinion of
>>> Gary G. Little
>>>
>>>
>>> “Don Burn” wrote in message news:xxxxx@ntdev…
>>>> Walter is back in the driver business. He is hanging out on
>>>> microsoft.public.development.device.drivers. I would recommend asking
>>>> him. I believe the code was in relation to his book, so do not expect
>>>> it to be just handed over.
>>>>
>>>> Hopefully the code is never GPL’ed ever, since it will then not be used
>>>> for commercial projects.
>>>>
>>>>
>>>> –
>>>> 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
>>>>
>>>> wrote in message news:xxxxx@ntdev…
>>>>> A while ago someone (Mark Roddy?) mentioned a kernel C++ library
>>>>> developed by Oney.
>>>>>
>>>>> Question was - is/will it be somehow available?
>>>>>
>>>>> Any news?
>>>>>
>>>>> [Alternatively, if we could only ask BB to work with Walter for
>>>>> a couple of hours… The code will be GPLed, of course…]
>>>>
>>>>
>>>
>>>
>>
>>
>>
>
> –
> Ray
> (If you want to reply to me off list, please remove “spamblock.” from my
> email address)
>
This is true for any new technology, there is a risk in using KMDF (which I
think is relatively small), but also a benefit.
Given the small budget of most USB-whatever devices “please make the driver
in 10 minutes plzhndlthx” and the (generally) very low quality of these
drivers, using the KMDF will most likely be a plus for the ecosystem. Maybe
the strongest argument against KMDF is that you have less information about
it available, but for simple and small projects that shouldn’t be a
problem.
Hopefully some people will take the risk, more will follow until it is
widely adopted. I understand the caution but that would not be my personal
choice. I’m not patient enough to wait 10 years to see if something is
realiable.
The question is are you an early adopter or not?
–
Edouard A.
KMDF?
Most drivers do not need to be able to corrupt the OS. It is a pity that the
effort did not go into introducing a driver privelege that does not extend
that far…
Now that would be enterprise, even starship, level…
M
“Mike Kemp” wrote in message news:xxxxx@ntdev…
>
> Most drivers do not need to be able to corrupt the OS. It is a pity that
> the effort did not go into introducing a driver privelege that does not
> extend that far…
>
Gee, that is exactly what UMDF is for. Now if you are saying get riid of
the kernel mode drivers ability to do this, all one would need to do is
come up with a new interface that does everything that Windows has
supported for the last 15 years (of course that should not take any time
right), and then tell everyone to throw out every driver and start over
again.
Now imagine the howls and lawsuits. Microsoft had a ton of legal actions
on the PatchGuard front from people like Symantec and McAfee because they
stonpped on 64-bit the ability to patch certain area which MALWARE loved to
touch. Obviously this was just a ploy to assert the Microsoft monopoly!!!
Now imagine what would be said if they took all the capabilities away, and
required a complete rewrite of every driver.
–
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
Mike Kemp wrote:
KMDF?
Most drivers do not need to be able to corrupt the OS. It is a pity
that the effort did not go into introducing a driver privelege that
does not extend that far…
I believe the results of that effort are called “UMDF”.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Comments inline:
“Bill McKenzie” wrote in message
news:xxxxx@ntdev…
> I am sick of hearing people recommend KMDF versus getting a handle on the
> complexities of WDM, which they will need anyway. I guess we will both
> just have to remain sick.
There is getting a handle and there is understanding all the sublety of it.
I doubt you or any of us understand the latter, since among others
Microsoft did not as they found out in developing KMDF.
> There is one, rather outstanding, difference between KMDF and Windows’
> other APIs or DDIs today. Namely, I can choose not to use it.
Sorry, the above is not always true. There are a number of classes of
drivers Microsoft is requiring the use of KMDF to get the driver signed.
> I don’t as much worry about the stability of KMDF as I do the available
> resources for it. There is well over ten years of collective experience
> with WDM and the other driver models to build from. KMDF? Well we have
> Doron, Peter W., et al…for now. And on the topic of stability who
> knows? It seems pretty good so far, but I wouldn’t bet my enterprise on
> it yet…especially without being able to look at it. Even the best
> developers make mistakes. These guys are some of the best…but they
> made mistakes that is a mathematical certainty.
Where were your complaints on the various class drivers over the years?
The storage group has shipped drivers that cannot pass driver verifier.
There was a USB class driver that caused the WHQL tests to fail (oops not
fail you had to just read though tons of documents to find that you could
ignore those failures, unless you wanted the device to support those
features and then you were out of luck). Right now the current WDK has a
number of driver sources that fail to pass PreFast or SDV and if you look
at the bugs they are real and will cause crashes. So where was your
outrage there?
> And, the biggest issue I have with KMDF is that it is now a complete
> departure away from its stated goal. The whole idea of KMDF, at least as
> it was presented to me, was to help make 3rd party drivers more robust.
> I don’t believe now, that that was ever really the intention. If it
> were, why would you not release source to the framework? If for no other
> reason, think about the literally thousands of existing WDM drivers that
> cannot afford a complete rewrite in a new framework, but COULD quite
> reasonably benefit from the learnings that could be had from the source
> of KMDF. The KMDF group has uncovered what many of us have been begging
> for for years and that is all of the undocumented interdependencies of
> PnP, Power and I/O. Why not let the rest of us, the third party driver
> developers, in on the secrets?
Now we are comming to your real complaint. I was there with you at the
first WinHEC we gave feedback and ageed that source was important. Yes
source access should be had, but to ignore or advocate against KMDF
strictly on the lack of source is stupid.
The lack of source does not make KMDF a failure on the purpose of improving
drivers. Sorry, I don’t know how many of us will really study the 300+
state state machine that represents that “undocumented interdependencies of
PnP, Power and I/O”. Right now I am writing a driver that has to be WDM
(it has to run in text mode setup and KMDF cannot) and I am cursing all the
pain I am in trying to get PNP/power right and this is a simple filter.
If you wanted to complain about the things KMDF lacks, then ok. My list is
over a page of single liners and talking to a number of senior Microsoft
people at WinHEC I found my list is only a small percentage of total items
they have.
> The KMDF group did a phenominal job on this framework right up and to the
> point of not pushing hard enough for source release. So now, the whole
> thing is a wash IMHO. Until you have to use it for Logo purposes, I
> think you would be crazy to use it. That is my personal take, and my
> recommendation to anyone who asks.
It was my understanding that the source release was hung up by legal.
Dealing with Microsoft legal is frightening, they are so afraid of being
sued that anything new is going to take forever. Condemming the KMDF team
because they could not get there is unfair to people who worked long and
hard to give us a good framework.
Bill if source is the key to quality, where was your fight to get source of
the WHQL tests? I would argue having those sources would be a much higher
priority. With those one could create additional tests, or tests for
drivers that WHQL does not cover. Source code for KMDF will be a useful
tool, but KMDF is a good tool even if it does not provide source.
–
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 hate to continue this…but
> There is one, rather outstanding, difference between KMDF and Windows’
> other APIs or DDIs today. Namely, I can choose not to use it.Sorry, the above is not always true. There are a number of classes of
drivers Microsoft is requiring the use of KMDF to get the driver signed.
Sad but true. Eventually, I have always assumed this would be the case, you
will have to use KMDF in all applicable situations and probably in a couple
of applications where it isn’t applicable
Where were your complaints on the various class drivers over the years?
The storage group has shipped drivers that cannot pass driver verifier.
There was a USB class driver that caused the WHQL tests to fail (oops not
fail you had to just read though tons of documents to find that you could
ignore those failures, unless you wanted the device to support those
features and then you were out of luck). Right now the current WDK has a
number of driver sources that fail to pass PreFast or SDV and if you look
at the bugs they are real and will cause crashes. So where was your
outrage there?
I have ALWAYS complained about bad drivers and ESPECIALLY bad minidrivers
and class drivers. I screamed bloody murder at NDIS for years which is one
reason I was VERY interested in affecting the direction of this framework if
I could. The last thing on earth we ever needed was another miniport
model!!! Have you read any of my 1394 material? Again, we can’t choose in
those cases. We should choose rightly where we can.
Now we are comming to your real complaint. I was there with you at the
first WinHEC we gave feedback and ageed that source was important. Yes
source access should be had, but to ignore or advocate against KMDF
strictly on the lack of source is stupid.
Oh c’mon lets be honest shall we? You, and I remember distinctly, were one
of the very few who were quite outspoken and adimant about source NOT being
provided.
It was my understanding that the source release was hung up by legal.
Dealing with Microsoft legal is frightening, they are so afraid of being
sued that anything new is going to take forever. Condemming the KMDF
team because they could not get there is unfair to people who worked long
and hard to give us a good framework.
Whatever…I don’t buy the argument. Is it a software company or a law
firm? I am hearing excuses. Someone at some level of management has
authority to fix this with a word.
Bill if source is the key to quality, where was your fight to get source
of the WHQL tests? I would argue having those sources would be a much
higher priority. With those one could create additional tests, or tests
for drivers that WHQL does not cover. Source code for KMDF will be a
useful tool, but KMDF is a good tool even if it does not provide source.
Thats your argument…go ahead and argue it. The OP asked about something
that led to KMDF. I have been 100% consistent on this from the very start.
I have said numerous times and I quote “If source is provided I will be the
framework’s biggest proponent, however if it is not provided I will be its
biggest opponent.”
You didn’t even touch my most important point about existing drivers and the
learning from KMDF. The vast majority of drivers that I run across and have
to work on today are existing drivers written before KMDF. These companies
can’t just go rewrite these drivers, that would be suicide. They have to
maintain them. Most of the drivers for Windows today have already been
written. That is the main reason, and I believe I have stated that reason
numerous times, for wanting source released for KMDF. I mean it is
completely written using published APIs right?? What’s the mystery?
If Microsoft were actually concerned about helping improve the quality of
3rd party drivers as they have often claimed, I believe they would try to
get as much of this information out there as possible as quickly as
possible. Instead they are hiding it?? Okay, so now I don’t believe
them…sorry I just calls em how I sees em. No axe to grind, no
beef…Microsoft has always been really good to me…I just don’t believe
the statements on this whole source/3rd party driver issue…it doesn’t pass
muster with me.
Bill M.
“Don Burn” wrote in message news:xxxxx@ntdev…
> Comments inline:
>
> “Bill McKenzie” wrote in message
> news:xxxxx@ntdev…
>> I am sick of hearing people recommend KMDF versus getting a handle on the
>> complexities of WDM, which they will need anyway. I guess we will both
>> just have to remain sick.
>
> There is getting a handle and there is understanding all the sublety of
> it. I doubt you or any of us understand the latter, since among others
> Microsoft did not as they found out in developing KMDF.
>
>> There is one, rather outstanding, difference between KMDF and Windows’
>> other APIs or DDIs today. Namely, I can choose not to use it.
>
> Sorry, the above is not always true. There are a number of classes of
> drivers Microsoft is requiring the use of KMDF to get the driver signed.
>
>> I don’t as much worry about the stability of KMDF as I do the available
>> resources for it. There is well over ten years of collective experience
>> with WDM and the other driver models to build from. KMDF? Well we have
>> Doron, Peter W., et al…for now. And on the topic of stability who
>> knows? It seems pretty good so far, but I wouldn’t bet my enterprise on
>> it yet…especially without being able to look at it. Even the best
>> developers make mistakes. These guys are some of the best…but they
>> made mistakes that is a mathematical certainty.
>
> Where were your complaints on the various class drivers over the years?
> The storage group has shipped drivers that cannot pass driver verifier.
> There was a USB class driver that caused the WHQL tests to fail (oops not
> fail you had to just read though tons of documents to find that you could
> ignore those failures, unless you wanted the device to support those
> features and then you were out of luck). Right now the current WDK has a
> number of driver sources that fail to pass PreFast or SDV and if you look
> at the bugs they are real and will cause crashes. So where was your
> outrage there?
>
>> And, the biggest issue I have with KMDF is that it is now a complete
>> departure away from its stated goal. The whole idea of KMDF, at least as
>> it was presented to me, was to help make 3rd party drivers more robust. I
>> don’t believe now, that that was ever really the intention. If it were,
>> why would you not release source to the framework? If for no other
>> reason, think about the literally thousands of existing WDM drivers that
>> cannot afford a complete rewrite in a new framework, but COULD quite
>> reasonably benefit from the learnings that could be had from the source
>> of KMDF. The KMDF group has uncovered what many of us have been begging
>> for for years and that is all of the undocumented interdependencies of
>> PnP, Power and I/O. Why not let the rest of us, the third party driver
>> developers, in on the secrets?
>
> Now we are comming to your real complaint. I was there with you at the
> first WinHEC we gave feedback and ageed that source was important. Yes
> source access should be had, but to ignore or advocate against KMDF
> strictly on the lack of source is stupid.
>
> The lack of source does not make KMDF a failure on the purpose of
> improving drivers. Sorry, I don’t know how many of us will really study
> the 300+ state state machine that represents that “undocumented
> interdependencies of PnP, Power and I/O”. Right now I am writing a driver
> that has to be WDM (it has to run in text mode setup and KMDF cannot) and
> I am cursing all the pain I am in trying to get PNP/power right and this
> is a simple filter.
>
> If you wanted to complain about the things KMDF lacks, then ok. My list
> is over a page of single liners and talking to a number of senior
> Microsoft people at WinHEC I found my list is only a small percentage of
> total items they have.
>
>> The KMDF group did a phenominal job on this framework right up and to the
>> point of not pushing hard enough for source release. So now, the whole
>> thing is a wash IMHO. Until you have to use it for Logo purposes, I
>> think you would be crazy to use it. That is my personal take, and my
>> recommendation to anyone who asks.
>
> It was my understanding that the source release was hung up by legal.
> Dealing with Microsoft legal is frightening, they are so afraid of being
> sued that anything new is going to take forever. Condemming the KMDF
> team because they could not get there is unfair to people who worked long
> and hard to give us a good framework.
>
> Bill if source is the key to quality, where was your fight to get source
> of the WHQL tests? I would argue having those sources would be a much
> higher priority. With those one could create additional tests, or tests
> for drivers that WHQL does not cover. Source code for KMDF will be a
> useful tool, but KMDF is a good tool even if it does not provide source.
>
>
>
> –
> 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
>
>
“Whatever…I don’t buy the argument. Is it a software company or a law
firm? I am hearing excuses. Someone at some level of management has
authority to fix this with a word.”
Bill, I agree with you that this is not what I want, but I don’t understand why you don’t believe that this is not a plausable reason. No one ever said that lawyers were reasonable. Of course there is someone there who has the authority to do whatever he or wants, but to go against legal would make one accountable for the decision. What the consequences would be, who knows, but as they are Microsoft, they are going to get sued from some reason that may be good or it may be silly, but it’s inevitable. I agree with you 100% that lawyers rarely produce results that anyone really wants, and most of the time they just pad their own pockets, but, for better or worse, that’s how companies tend to make decisions, because of fear/fear tactics of disastorous consequences. In this case, that I really like KMDF notwithstanding, look at the cost/benefit. While I agree with you 100% that source would be really helpful, and, left to my own devices and wants, I would do so, I think one reason that exists to no do so is to prevent people from creating private builds. I’m not saying that this is the reason, or that it necessarily is even possible in practice, but I would wonder about it. Fundamentally, assuming that there is perception of legal downside, what exactly do you expect to offset this? Source code is not going to determine whether this product fails or not, in my opinion. It’s also free, and those who reject it are still going to be Microsoft customers/developers. It’s hard to override legal, and I don’t see how one could possibly make a cost/benefit case here, that it isn’t my wish notwithstanding.
mm
Bill McKenzie wrote:
benefit from the learnings that could be had from the source of KMDF. The
KMDF group has uncovered what many of us have been begging for for years and
that is all of the undocumented interdependencies of PnP, Power and I/O.
Why not let the rest of us, the third party driver developers, in on the
secrets?
Why not reveal *all* the undocumented interdependencies in the operating
system? Now, some of those, no doubt, are simply neglected or poorly
covered in the documentation. However, I bet the majority are
undocumented *intentionally*. As in: "*don't* rely on this interdependency".
Besides the laudable goal of helping the helpless avoid many of the WDM
pitfalls, the point of KMDF, as far as I can tell, was to create a DDI
that Microsoft *could* document more or less completely. It is intended
to be straightforward and orthogonal enough to be expressible in English
as well as C++, and yet still have something they are able to maintain
and improve.
KMDF is a good step in the right direction, but it's clearly not all the
way there yet. It's *way* too early for Microsoft to be locking
themselves into this first brand new implementation by exposing, and
thereby implicitly documenting, its internals for the world to see.
Go read Raymond Chen's blog for a while (ok, ignore the last 6 months or
so 
if you're unclear on the headaches Microsoft endures because of
yahoo programmers relying on undocumented behaviors. The number of
"compatibility hacks" needed by Windows is utterly absurd already.
If Microsoft *wants* to reveal the intricacies that they found while
developing KMDF, I have every confidence in their ability to *document*
those. The KMDF team (or maybe their tech writers? 
are manifestly
capable of quite eloquent expression.
Ray
(If you want to reply to me off list, please remove "spamblock." from my
email address)
Bill McKenzie wrote:
Whatever…I don’t buy the argument. Is it a software company
or a law firm?
That’s not really fair. In large institutions (including places like MIT),
it is not uncommon for lawyers to be able to stop or hold up (for many
years) things that should be a no-brainer from getting done. And that works
both ways. It can stop/delay the release of code as well as getting access
to code…all due to lawyer paranoia.
I am hearing excuses.
No, you are hearing reasons.
Someone at some level of management has authority to fix this with
a word.
I imagine so, if you’re high enough up in the food chain. But you can’t
blame the KMDF guys for that. Blaming the lawyers, however, is a different
story
Thanks, Don, UMDF is on my list the next time I need a driver. When I
started my last one UMDF was predicted for some time in the future and for
Vista only.
As a point of information, my requirement was simply to communicate with my
1394 device streaming isoch data (at realtime priority level) to and from it
and exchanging async data (less critical). I did this all ok in user mode on
OSX. Would you say that as far as I describe it this is within the ability
of UMDF? If so it is indeed a great leap forward, especially if it will run
on XP (we don’t go further back than that).
I can see why you can’t invalidate old drivers, legacy support must
continue, it is MS’s cross to bear. But the ability to specifically permit
them one by one as Vista seems to permit is (was) the ideal point to start
the change to a scaled priority approach don’t you think?
I for one was shocked when I started writing this driver how much I could
do - MS seemed to be giving me carte blanche to do anything with or under
the OS, when all I wanted was an interface, and I’d rather just our product
crashed than the whole machine (given that I suffer from occasional
imperfection, rare amongst driver writers)…
Best regards, Mike
BTW Re the source code hot potato: I wonder if today’s EU ruling against MS
will cause the release of source code (at least in Europe, it may remain
legally unavailable in the US). It seems that if MS can make better
applications by having access to the source code then it would fall foul…
----- Original Message -----
From: Don Burn
Newsgroups: ntdev
To: Windows System Software Devs Interest List
Sent: Friday, September 14, 2007 5:41 PM
Subject: Re:[ntdev] Re:Oney C++ lib
“Mike Kemp” wrote in message news:xxxxx@ntdev…
>
> Most drivers do not need to be able to corrupt the OS. It is a pity that
> the effort did not go into introducing a driver privelege that does not
> extend that far…
>
Gee, that is exactly what UMDF is for. Now if you are saying get riid of
the kernel mode drivers ability to do this, all one would need to do is
come up with a new interface that does everything that Windows has
supported for the last 15 years (of course that should not take any time
right), and then tell everyone to throw out every driver and start over
again.
Now imagine the howls and lawsuits. Microsoft had a ton of legal actions
on the PatchGuard front from people like Symantec and McAfee because they
stonpped on 64-bit the ability to patch certain area which MALWARE loved to
touch. Obviously this was just a ploy to assert the Microsoft monopoly!!!
Now imagine what would be said if they took all the capabilities away, and
required a complete rewrite of every driver.
–
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
—
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