Hi,
from the former discussion of the discontinued W2K support of KMDF (1.0)
I kept in mind that it’s required to use the KMDF to obtain a driver
WHQL certification for Windows Vista. For driver/device classes
supported by the KMDF of course.
Is this true? I can’t find an ‘official’ statement at the WHQL pages. A
link would be highly appreciated. Thanks.
Absolutely not. There is absolutely, positively, no requirement to use KMDF to obtain WHQL certification for any driver.
Peter
OSR
wrote in message news:xxxxx@ntdev…
>
>
> Absolutely not. There is absolutely, positively, no requirement to use
> KMDF to obtain WHQL certification for any driver.
>
>
Actually, this was discussed on another forum, and there is a
requirement:in the Vista Logo Program:
“Third-party keyboard and mouse kernel-mode drivers must be ported to the
WDF KMDF model”.
This was confirmed by Doron.
–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
http://www.windrvr.com
Remove StopSpam from the email to reply
I stand corrected, and thank Don for his answer.
After doing some research, Don is (of course) correct. In addition, it seems I was wrong TWICE: SDIO drivers must also be written using KMDF.
In addition, it SEEMS from reading the Vista Logo Requirements doc that cellular phone drivers must be implemented using UMDF. It’s not entirely clear, but this seems to be the case.
I find this scandalous, and that’s putting it mildly. While I’m a big fan of KMDF/UMDF – a REALLY big fan – I think dictating the method of driver implementation is horribly unreasonable. Sure, enforce conformance requirements on driver/device – Define what it needs to do. But also tell me that I must write it using a particular framework? That’s just plain wrong.
Of course, it’s not like my opinion matters.
Peter
OSR
wrote in message news:xxxxx@ntdev…
>
>
> I stand corrected, and thank Don for his answer.
>
> After doing some research, Don is (of course) correct. In addition, it
> seems I was wrong TWICE: SDIO drivers must also be written using KMDF.
>
> In addition, it SEEMS from reading the Vista Logo Requirements doc that
> cellular phone drivers must be implemented using UMDF. It’s not entirely
> clear, but this seems to be the case.
>
>
> I find this scandalous, and that’s putting it mildly. While I’m a big
> fan of KMDF/UMDF – a REALLY big fan – I think dictating the method of
> driver implementation is horribly unreasonable. Sure, enforce
> conformance requirements on driver/device – Define what it needs to do.
> But also tell me that I must write it using a particular framework?
> That’s just plain wrong.
>
> Of course, it’s not like my opinion matters.
>
>
Doron explained the logic of the above with:
While I understand the desire, they seem to be overlooking a few obvious
points:
1. Even with KMDF you can produce a buggy driver, and thanks to the
flexibility of KMDF it is possible to have a driver that is KMDF that steps
outside of the framework for almost everything.
2. Right now KMDF is still new to the driver community, while I find
the framework nice, I know from previous experience I make a lot of
mistakes while first using a new tool. Does forcing things to use KMDF on
a short schedule therefore increase or decrease quality?
3. If there are known problems with certain classes of drivers,
where is the effort to increase the test coverage for those classes? Most
of use complain about WHQL tests, if they are having a problem fix the
tests, do assume “We will require a new tool so everything will be better”.
–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
http://www.windrvr.com
Remove StopSpam from the email to reply
> ----------
From: xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com] on behalf of xxxxx@osr.com[SMTP:xxxxx@osr.com]
Reply To: Windows System Software Devs Interest List
Sent: Wednesday, October 04, 2006 6:18 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] KMDF required for Vista certification?
> I find this scandalous, and that’s putting it mildly. While I’m a big fan of KMDF/UMDF – a REALLY big fan – I think dictating the method of driver implementation is horribly unreasonable. Sure, enforce conformance requirements on driver/device – Define what it needs to do. But also tell me that I must write it using a particular framework? That’s just plain wrong.
>
> Of course, it’s not like my opinion matters.
>
>
I’m second that. It is just horrible idea especially when KMDF sources aren’t available and there is no possibility to link it statically. That’s reasons why I won’t use KMDF until absolutely necessary.
Best regards,
Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]
I have never used KMDF (beyond a lab at Driver DevCon), and may never do
so (as I pretty much never see real hardware), so, although the decision
makes no sense to me, I have no particular feeling either way on this
issue. That being said, I think Don’s points are excellent. Shouldn’t
the focus be on testing, rather than a new tool, particularly one which,
based on my very basic understanding, has been excellently and
explicitly designed to allow one to drop down to the native level
without worrying about hidden locks, et. c. It seems to me that, if one
looks at the history of software failures, they have several things in
common, one of which is invariably the use of new and relatively
untested tool to attempt solve what generally boil down to personnel,
management and budgetary problems, the last of which is for the most
part intractable in many cases; i. e. - lack of dedicated resources for
testing. I think one of the major problems with any new tool, and, in
particular, mandating its use, is that its capabilities are evaluated by
its architects and original developers, and, in the process, some very
unattractive realities about the mistakes that the general public might
make, as well as poor decisions get ignored. This was certainly the
case with C++ - that Bjarne was able to translate real C programs to C++
with only a 2% performance drop is nice, but not all that meaningful, as
most of us are neither geniuses nor original architects. That being
said, we are not incompetent, as neither probably were the people at
Mentor Graphics, or any of the others who led the early large scale C++
projects outside of Murray Hill Labs, almost all of which failed
miserably. Different story today, but that took time, and requiring a
new tools use just doesn’t seem very sound to me.
MM
>> xxxxx@acm.org 2006-10-04 12:37 >>>
wrote in message news:xxxxx@ntdev…
>
>
> I stand corrected, and thank Don for his answer.
>
> After doing some research, Don is (of course) correct. In addition,
it
> seems I was wrong TWICE: SDIO drivers must also be written using
KMDF.
>
> In addition, it SEEMS from reading the Vista Logo Requirements doc
that
> cellular phone drivers must be implemented using UMDF. It’s not
entirely
> clear, but this seems to be the case.
>
>
> I find this scandalous, and that’s putting it mildly. While I’m a
big
> fan of KMDF/UMDF – a REALLY big fan – I think dictating the method
of
> driver implementation is horribly unreasonable. Sure, enforce
> conformance requirements on driver/device – Define what it needs to
do.
> But also tell me that I must write it using a particular framework?
> That’s just plain wrong.
>
> Of course, it’s not like my opinion matters.
>
>
Doron explained the logic of the above with:
While I understand the desire, they seem to be overlooking a few
obvious
points:
1. Even with KMDF you can produce a buggy driver, and thanks to
the
flexibility of KMDF it is possible to have a driver that is KMDF that
steps
outside of the framework for almost everything.
2. Right now KMDF is still new to the driver community, while I
find
the framework nice, I know from previous experience I make a lot of
mistakes while first using a new tool. Does forcing things to use KMDF
on
a short schedule therefore increase or decrease quality?
3. If there are known problems with certain classes of drivers,
where is the effort to increase the test coverage for those classes?
Most
of use complain about WHQL tests, if they are having a problem fix the
tests, do assume “We will require a new tool so everything will be
better”.
–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
http://www.windrvr.com
Remove StopSpam from the email to reply
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
About KMDF. I’m very much worried about the amount of KMDF questions here
on forums, most of which are due to a) people do not know WDM b) KMDF is
source-less. Without the kind help of Doron, these people would be stuck.
Note: MFC is provided with source, and KMDF to WDM is what is MFC to Win32.
Also note: MFC does not free the person from knowing Win32 itself, though
yes, the need in Win32 knowledge with MFC is very small - only to solve the
hard issues.
Any framework provides an illusion that “now all complexities are solved”.
Not so. The simple and streamlined things are done much easier, but, if the
hard issue arises - then the framework complicates the things a lot, the person
will need to know both the framework and the underlying platform.
without worrying about hidden locks, et. c. It seems to me that, if one
looks at the history of software failures, they have several things in
common, one of which is invariably the use of new and relatively
untested tool to attempt solve what generally boil down to personnel,
management and budgetary problems, the last of which is for the most
part intractable in many cases; i. e. - lack of dedicated resources for
testing. I think one of the major problems with any new tool, and, in
particular, mandating its use, is that its capabilities are evaluated by
its architects and original developers, and, in the process, some very
unattractive realities about the mistakes that the general public might
make, as well as poor decisions get ignored.
Correct. If the bla-bla architect - or just business people - mandate some
tool - then the chances of tool-based failure are very high. For instance - the
user wants some feature, and the tool just crashes trying to implement it, as
it was with ill memored PowerBuilder in mid 90ies.
case with C++ - that Bjarne was able to translate real C programs to C++
with only a 2% performance drop is nice, but not all that meaningful, as
most of us are neither geniuses nor original architects. That being
said, we are not incompetent, as neither probably were the people at
Mentor Graphics, or any of the others who led the early large scale C++
projects outside of Murray Hill Labs, almost all of which failed
IIRC Borland did the first production C++ compiler in 1990, before this, only
“cfront” existed. The first MS’s C++ compiler was IIRC 1992 or 1993, always a
32bit EXE itself - running under PharLap (PharLap embedded to the binary) on
DOS, in virtual DOS machine under PharLap on Windows 3.x and as native PE in
Windows 95/NT. This is how MSVC 1.5x worked.
The UNIX and open-source people turned to C++ MUCH later then people working
for DOS/Windows with Borland’s or MS’s tools.
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
According to the Intro to WDF page
(http://www.microsoft.com/whdc/driver/wdf/wdf-intro.mspx):
“For new device classes, such as the biometrics device class, Microsoft
plans to start using WDF in Windows Vista.”
I haven’t seen anything further on this in the WDK, but it hints that
existing biometrics WDM drivers will need to be rewritten with KMDF once a
device class is established for them.
Stan Mitchell
SourceQuest, Inc.
> ----------
From: xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com] on behalf of Maxim S. Shatskih[SMTP:xxxxx@storagecraft.com]
Reply To: Windows System Software Devs Interest List
Sent: Wednesday, October 04, 2006 10:32 PM
To: Windows System Software Devs Interest List
Subject: Re: Re:[ntdev] KMDF required for Vista certification?About KMDF. I’m very much worried about the amount of KMDF questions here
on forums, most of which are due to a) people do not know WDM b) KMDF is
source-less. Without the kind help of Doron, these people would be stuck.
Me too. I don’t use it so my impression is based only on the discussion in this list and I have to say it is discouraging. I understand not making sources available is lawyer’s and not developer’s decisions but it is wrong decision anyway. Having the source for a framework is essential. Developers should explain it to the lawyers and answer the question why to make it available. Anyway, the correct question is “why not?” and it’d be intresting to hear the answer.
Note: MFC is provided with source, and KMDF to WDM is what is MFC to Win32.
Good example.
Also note: MFC does not free the person from knowing Win32 itself, though
yes, the need in Win32 knowledge with MFC is very small - only to solve the
hard issues.
Any framework provides an illusion that “now all complexities are solved”.
Not so. The simple and streamlined things are done much easier, but, if the
hard issue arises - then the framework complicates the things a lot, the person
will need to know both the framework and the underlying platform.
Exactly.
Best regards,
Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]
You know, when this requirement was first articulated, I pitched a big
fit for quite some time for a lot of the same reasons people have
discussed here.
Then I calmed down and really thought about it.
First of all, KMDF is *nothing* like MFC. They serve entirely different
purposes and accomplish their goals in entirely different ways. KMDF is
much more like “the way WDM should have been done in the first place,
because damn that thing is crufty and awful and way too complicated”.
Another way of looking at it is that KMDF is a lot more like NDIS.
As for the “but we can’t statically link” argument: It’s part of the
dang OS. You don’t statically link to kernel32.dll either, but that
doesn’t seem to bother anyone (and think of what a nightmare *that*
would be). They fix bugs in that thing all the time and that doesn’t
seem to bother anyone. They don’t give you the source either, and that
doesn’t seem to bother anyone.
Where was the huge outrage when Microsoft “hid” all the installation
details in UpdateDriverForPlugAndPlayDevices rather than “letting”
driver writers call the SetupAPI functions directly themselves?
Sure, it’s new… but I suspect that a whole *lot* of kernel32.dll in
Vista is brand-spanking new too. At some level we have to trust MS to do
their job. Frankly, I know Doron reasonably well, and that gives me
quite a bit of confidence that KMDF is implemented as well if not better
than kernel32.dll was.
I don’t know anything about SDIO or cellphone drivers, but as for
mice/keyboards, I very much doubt that anyone writing one of those is
doing anything really all that complicated WRT the stuff that KMDF is
“hiding”. And if they are, that’s probably a pretty big red flag (insert
sheepish admission that I had to figure out a few tricky ways around how
KMDF does things during our port because our driver was being “bad”).
It’s not like Microsoft is saying you *can’t* write a WDM mouse/keyboard
driver, or even ship it to your customers, they’re just saying that
Microsoft doesn’t want to have anything to do with it if you do. I don’t
really want to have anything to do with it either…
Maxim S. Shatskih wrote:
About KMDF. I’m very much worried about the amount of KMDF questions here
on forums, most of which are due to a) people do not know WDM b) KMDF is
source-less. Without the kind help of Doron, these people would be stuck.
Note: MFC is provided with source, and KMDF to WDM is what is MFC to Win32.
Also note: MFC does not free the person from knowing Win32 itself, though
yes, the need in Win32 knowledge with MFC is very small - only to solve the
hard issues.
Any framework provides an illusion that “now all complexities are solved”.
Not so. The simple and streamlined things are done much easier, but, if the
hard issue arises - then the framework complicates the things a lot, the person
will need to know both the framework and the underlying platform.> without worrying about hidden locks, et. c. It seems to me that, if one
> looks at the history of software failures, they have several things in
> common, one of which is invariably the use of new and relatively
> untested tool to attempt solve what generally boil down to personnel,
> management and budgetary problems, the last of which is for the most
> part intractable in many cases; i. e. - lack of dedicated resources for
> testing. I think one of the major problems with any new tool, and, in
> particular, mandating its use, is that its capabilities are evaluated by
> its architects and original developers, and, in the process, some very
> unattractive realities about the mistakes that the general public might
> make, as well as poor decisions get ignored.Correct. If the bla-bla architect - or just business people - mandate some
tool - then the chances of tool-based failure are very high. For instance - the
user wants some feature, and the tool just crashes trying to implement it, as
it was with ill memored PowerBuilder in mid 90ies.> case with C++ - that Bjarne was able to translate real C programs to C++
> with only a 2% performance drop is nice, but not all that meaningful, as
> most of us are neither geniuses nor original architects. That being
> said, we are not incompetent, as neither probably were the people at
> Mentor Graphics, or any of the others who led the early large scale C++
> projects outside of Murray Hill Labs, almost all of which failedIIRC Borland did the first production C++ compiler in 1990, before this, only
“cfront” existed. The first MS’s C++ compiler was IIRC 1992 or 1993, always a
32bit EXE itself - running under PharLap (PharLap embedded to the binary) on
DOS, in virtual DOS machine under PharLap on Windows 3.x and as native PE in
Windows 95/NT. This is how MSVC 1.5x worked.The UNIX and open-source people turned to C++ MUCH later then people working
for DOS/Windows with Borland’s or MS’s tools.Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
–
Ray
(If you want to reply to me off list, please remove “spamblock.” from my
email address)
>You don’t statically link to kernel32.dll either, but that doesn’t seem to
bother anyone
The trouble is, kernel32 is present in 99.99% Windows installations, while
KMDF must be redistributed, with all the hassles of installing it.
They fix bugs in that thing all the time and that doesn’t seem to bother
anyone.
Yeah, right. For me, bugs in Windows are the *major* source of problems. I
can fix my own bugs, but I can’t fix Microsoft ones. And Microsoft won’t fix
them either, at least within a reasonable time frame, say a year or two. I
claim this based on my own experience in multiple cases.
They don’t give you the source either, and that doesn’t seem to bother
anyone.
Yes, it does.
“Ray Trent” wrote in message
news:xxxxx@ntdev…
> You know, when this requirement was first articulated, I pitched a big fit
> for quite some time for a lot of the same reasons people have discussed
> here.
>
> Then I calmed down and really thought about it.
>
> First of all, KMDF is nothing like MFC. They serve entirely different
> purposes and accomplish their goals in entirely different ways. KMDF is
> much more like “the way WDM should have been done in the first place,
> because damn that thing is crufty and awful and way too complicated”.
> Another way of looking at it is that KMDF is a lot more like NDIS.
>
> As for the “but we can’t statically link” argument: It’s part of the dang
> OS. You don’t statically link to kernel32.dll either, but that doesn’t
> seem to bother anyone (and think of what a nightmare that would be).
> They fix bugs in that thing all the time and that doesn’t seem to bother
> anyone. They don’t give you the source either, and that doesn’t seem to
> bother anyone.
>
> Where was the huge outrage when Microsoft “hid” all the installation
> details in UpdateDriverForPlugAndPlayDevices rather than “letting” driver
> writers call the SetupAPI functions directly themselves?
>
> Sure, it’s new… but I suspect that a whole lot of kernel32.dll in
> Vista is brand-spanking new too. At some level we have to trust MS to do
> their job. Frankly, I know Doron reasonably well, and that gives me quite
> a bit of confidence that KMDF is implemented as well if not better than
> kernel32.dll was.
>
> I don’t know anything about SDIO or cellphone drivers, but as for
> mice/keyboards, I very much doubt that anyone writing one of those is
> doing anything really all that complicated WRT the stuff that KMDF is
> “hiding”. And if they are, that’s probably a pretty big red flag (insert
> sheepish admission that I had to figure out a few tricky ways around how
> KMDF does things during our port because our driver was being “bad”).
>
> It’s not like Microsoft is saying you can’t write a WDM mouse/keyboard
> driver, or even ship it to your customers, they’re just saying that
> Microsoft doesn’t want to have anything to do with it if you do. I don’t
> really want to have anything to do with it either…
>
> Maxim S. Shatskih wrote:
>> About KMDF. I’m very much worried about the amount of KMDF questions
>> here
>> on forums, most of which are due to a) people do not know WDM b) KMDF is
>> source-less. Without the kind help of Doron, these people would be stuck.
>> Note: MFC is provided with source, and KMDF to WDM is what is MFC to
>> Win32.
>> Also note: MFC does not free the person from knowing Win32 itself,
>> though
>> yes, the need in Win32 knowledge with MFC is very small - only to solve
>> the
>> hard issues.
>> Any framework provides an illusion that “now all complexities are
>> solved”.
>> Not so. The simple and streamlined things are done much easier, but, if
>> the
>> hard issue arises - then the framework complicates the things a lot, the
>> person
>> will need to know both the framework and the underlying platform.
>>
>>> without worrying about hidden locks, et. c. It seems to me that, if one
>>> looks at the history of software failures, they have several things in
>>> common, one of which is invariably the use of new and relatively
>>> untested tool to attempt solve what generally boil down to personnel,
>>> management and budgetary problems, the last of which is for the most
>>> part intractable in many cases; i. e. - lack of dedicated resources for
>>> testing. I think one of the major problems with any new tool, and, in
>>> particular, mandating its use, is that its capabilities are evaluated by
>>> its architects and original developers, and, in the process, some very
>>> unattractive realities about the mistakes that the general public might
>>> make, as well as poor decisions get ignored.
>>
>> Correct. If the bla-bla architect - or just business people - mandate
>> some
>> tool - then the chances of tool-based failure are very high. For
>> instance - the
>> user wants some feature, and the tool just crashes trying to implement
>> it, as
>> it was with ill memored PowerBuilder in mid 90ies.
>>
>>> case with C++ - that Bjarne was able to translate real C programs to C++
>>> with only a 2% performance drop is nice, but not all that meaningful, as
>>> most of us are neither geniuses nor original architects. That being
>>> said, we are not incompetent, as neither probably were the people at
>>> Mentor Graphics, or any of the others who led the early large scale C++
>>> projects outside of Murray Hill Labs, almost all of which failed
>>
>> IIRC Borland did the first production C++ compiler in 1990, before this,
>> only
>> “cfront” existed. The first MS’s C++ compiler was IIRC 1992 or 1993,
>> always a
>> 32bit EXE itself - running under PharLap (PharLap embedded to the binary)
>> on
>> DOS, in virtual DOS machine under PharLap on Windows 3.x and as native PE
>> in
>> Windows 95/NT. This is how MSVC 1.5x worked.
>>
>> The UNIX and open-source people turned to C++ MUCH later then people
>> working
>> for DOS/Windows with Borland’s or MS’s tools.
>>
>> Maxim Shatskih, Windows DDK MVP
>> StorageCraft Corporation
>> xxxxx@storagecraft.com
>> http://www.storagecraft.com
>>
>>
>
> –
> Ray
> (If you want to reply to me off list, please remove “spamblock.” from my
> email address)
>
cristalink wrote:
The trouble is, kernel32 is present in 99.99% Windows installations, while
KMDF must be redistributed, with all the hassles of installing it.
Microsoft could fix that problem tomorrow using Windows Update if they
wanted to… hmmm… why don’t they? Of course, that wouldn’t get to
that high a fraction, but people that don’t get updates probably aren’t
installing your driver either.
> They fix bugs in that thing all the time and that doesn’t seem to bother
> anyone.Yeah, right. For me, bugs in Windows are the *major* source of problems. I
Of course. What I meant was that many people complain that KMDF will
change out from under their driver the next time MS fixes a bug in it,
and that’s why they want to statically link to it (because, the theory
goes, I guess, they’ve already SQA’d that version). They also complain
that they can’t step through KMDF or analyze the source to figure out
what is wrong with their driver. I was merely saying that the rest of
Windows works that way too, what’s special about this?
> They don’t give you the source either, and that doesn’t seem to bother
> anyone.Yes, it does.
Ray
(If you want to reply to me off list, please remove “spamblock.” from my
email address)
“Ray Trent” wrote in message
news:45245007.451ad95f.06fc.2747SMTPIN_ADDED@mx.google.com…
> cristalink wrote:
>> The trouble is, kernel32 is present in 99.99% Windows installations,
>> while KMDF must be redistributed, with all the hassles of installing it.
>
> Microsoft could fix that problem tomorrow using Windows Update if they
> wanted to… hmmm… why don’t they? Of course, that wouldn’t get to that
> high a fraction, but people that don’t get updates probably aren’t
> installing your driver either.
>
Sorry, but it is a mistake to think that poeple who don’t get updates aren’t
installing anyone’s driver. Windows update might be a nice avenue for
providing the WDF driver, but as someone who has written highly specialized
drivers that are installed on carefully controlled systems (no updates get
installed without a whole lot of scrutiny and even then only if they are
deemed by the user to be absolutely necessary. A system that is not tied to
the internet with no-one surfing the web or receiving email on it has a low
risk of encountering the security problems), I can’t be certain that a
system my driver will be installed on will have the WDF driver installed on
it if we were going to rely on Update as the distribution medium.
A drive writer needs to be able to be assured that all of its dependencies
are on the target user’s system. If they aren’t there, the driver writer
needs to be able to provide them.
>>> They fix bugs in that thing all the time and that doesn’t seem to bother
>>> anyone.
>>
>> Yeah, right. For me, bugs in Windows are the major source of problems.
>> I
>
> Of course. What I meant was that many people complain that KMDF will
> change out from under their driver the next time MS fixes a bug in it, and
> that’s why they want to statically link to it (because, the theory goes, I
> guess, they’ve already SQA’d that version). They also complain that they
> can’t step through KMDF or analyze the source to figure out what is wrong
> with their driver. I was merely saying that the rest of Windows works that
> way too, what’s special about this?
The difference here is kernelmode vs usermode. A user-mode DLL is less
likely to crash a system if someone’s application was expecting it to behave
one way and it behaved differently. It might crash the app but they system
is likely to keep running. In the kernel a subtle difference in behavior
that was not expected by a driver using it could cause A Bad Thing to
happen.
Beverly
>
>>> They don’t give you the source either, and that doesn’t seem to bother
>>> anyone.
>>
>> Yes, it does.
>
> Ok, fine… point made… but irrelevant to this discussion…
> –
> Ray
> (If you want to reply to me off list, please remove “spamblock.” from my
> email address)
>
> —
> 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
----- Original Message -----
From: “Ray Trent”
Newsgroups: ntdev
To: “Windows System Software Devs Interest List”
Sent: Wednesday, October 04, 2006 8:20 PM
Subject: Re:[ntdev] KMDF required for Vista certification?
> cristalink wrote:
>> The trouble is, kernel32 is present in 99.99% Windows installations,
>> while KMDF must be redistributed, with all the hassles of installing it.
>
> Microsoft could fix that problem tomorrow using Windows Update if they
> wanted to… hmmm… why don’t they? Of course, that wouldn’t get to that
> high a fraction, but people that don’t get updates probably aren’t
> installing your driver either.
>
>>> They fix bugs in that thing all the time and that doesn’t seem to bother
>>> anyone.
>>
>> Yeah, right. For me, bugs in Windows are the major source of problems.
>> I
>
> Of course. What I meant was that many people complain that KMDF will
> change out from under their driver the next time MS fixes a bug in it, and
> that’s why they want to statically link to it (because, the theory goes, I
> guess, they’ve already SQA’d that version). They also complain that they
> can’t step through KMDF or analyze the source to figure out what is wrong
> with their driver. I was merely saying that the rest of Windows works that
> way too, what’s special about this?
>
>>> They don’t give you the source either, and that doesn’t seem to bother
>>> anyone.
>>
>> Yes, it does.
>
> Ok, fine… point made… but irrelevant to this discussion…
> –
> Ray
> (If you want to reply to me off list, please remove “spamblock.” from my
> email address)
>
> —
> 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
> Microsoft could fix that problem tomorrow using Windows Update if they
wanted to… hmmm… why don’t they?
…if this is an exploitable security hole
OR
…if major MS’s client complains a lot
OR
…if MS’s support phone lines are very hot about the bug
These fixes are called QFE (Quick Fix Engineering), and then accumulated to a
Service Pack.
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
Arrrghh…
For ME, it’s not about whether you like KMDF, or if it’s more like kernel32 or MFC (though I really didn’t get that point), or whether you would trust Doron personally to write your driver or babysit your kid.
For ME, it’s not even about whether you think KMDF is a good tool. I think it 's a GREAT tool. Shit, let’s assume just for the sake of argument it’s inspired with Gxd-like qualities and it’s a PERFECT tool.
For ME, it’s about every single dev in the community being told – entirely arbitrarily – what tool they HAVE to use to accomplish a job. I just think that’s about 48 flavors of wrong. It’s about taking away my ability to make my own engineering decisions, and my company’s ability to make its own business decisions. It’s about telling me: “You’ve got a keyboard driver that works for Win2K and XP? That’s too bad for you mate, cuz you’ve gotta write a new one in KMDF that supports Vista and your company has to support them BOTH.”
Let me reiterate: I’m not against using KMDF or UMDF. I have, in actual fact, chosen to use KMDF in every single (potentially applicable, not filesystems obviously) project that OSR has undertaken since even BEFORE KMDF’s release. I will continue to do so, because I believe in the technology and (yes) the people who build it.
But tell me I have to use it? That makes me wanna do anything but…
P
I agree. I see something similar in that Vista requires (?) the use of NTFS
for the boot/system partition. I always prefer to use FAT32 for my boot
drive and all the partitions on it. I use NTFS for other drives to get
around the 4GB file size limit of FAT32. I can repair FAT32 with a hex
editor, while NTFS is not documented sufficiently to enable me to do the
same.
wrote in message news:xxxxx@ntdev…
>
>
> Arrrghh…
>
> For ME, it’s not about whether you like KMDF, or if it’s more like
> kernel32 or MFC (though I really didn’t get that point), or whether you
> would trust Doron personally to write your driver or babysit your kid.
>
> For ME, it’s not even about whether you think KMDF is a good tool. I
> think it 's a GREAT tool. Shit, let’s assume just for the sake of argument
> it’s inspired with Gxd-like qualities and it’s a PERFECT tool.
>
> For ME, it’s about every single dev in the community being told –
> entirely arbitrarily – what tool they HAVE to use to accomplish a job. I
> just think that’s about 48 flavors of wrong. It’s about taking away my
> ability to make my own engineering decisions, and my company’s ability to
> make its own business decisions. It’s about telling me: “You’ve got a
> keyboard driver that works for Win2K and XP? That’s too bad for you mate,
> cuz you’ve gotta write a new one in KMDF that supports Vista and your
> company has to support them BOTH.”
>
> Let me reiterate: I’m not against using KMDF or UMDF. I have, in actual
> fact, chosen to use KMDF in every single (potentially applicable, not
> filesystems obviously) project that OSR has undertaken since even BEFORE
> KMDF’s release. I will continue to do so, because I believe in the
> technology and (yes) the people who build it.
>
> But tell me I have to use it? That makes me wanna do anything but…
>
>
>
> P
>
>
I felt the same way about NTFS vs FAT32 until I realized that
repairing it was seldom necessary with NTFS and frequently necessary
with FAT32. In fact, I can’t remember the last time I had to repair a
NTFS volume.
Beverly
On 10/5/06, David J. Craig wrote:
> I agree. I see something similar in that Vista requires (?) the use of NTFS
> for the boot/system partition. I always prefer to use FAT32 for my boot
> drive and all the partitions on it. I use NTFS for other drives to get
> around the 4GB file size limit of FAT32. I can repair FAT32 with a hex
> editor, while NTFS is not documented sufficiently to enable me to do the
> same.
>
> wrote in message news:xxxxx@ntdev…
> >
> >
> > Arrrghh…
> >
> > For ME, it’s not about whether you like KMDF, or if it’s more like
> > kernel32 or MFC (though I really didn’t get that point), or whether you
> > would trust Doron personally to write your driver or babysit your kid.
> >
> > For ME, it’s not even about whether you think KMDF is a good tool. I
> > think it 's a GREAT tool. Shit, let’s assume just for the sake of argument
> > it’s inspired with Gxd-like qualities and it’s a PERFECT tool.
> >
> > For ME, it’s about every single dev in the community being told –
> > entirely arbitrarily – what tool they HAVE to use to accomplish a job. I
> > just think that’s about 48 flavors of wrong. It’s about taking away my
> > ability to make my own engineering decisions, and my company’s ability to
> > make its own business decisions. It’s about telling me: “You’ve got a
> > keyboard driver that works for Win2K and XP? That’s too bad for you mate,
> > cuz you’ve gotta write a new one in KMDF that supports Vista and your
> > company has to support them BOTH.”
> >
> > Let me reiterate: I’m not against using KMDF or UMDF. I have, in actual
> > fact, chosen to use KMDF in every single (potentially applicable, not
> > filesystems obviously) project that OSR has undertaken since even BEFORE
> > KMDF’s release. I will continue to do so, because I believe in the
> > technology and (yes) the people who build it.
> >
> > But tell me I have to use it? That makes me wanna do anything but…
> >
> >
> >
> > P
> >
> >
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
>
xxxxx@osr.com wrote:
But tell me I *have* to use it? That makes me wanna do anything but…
Sure, that’s annoying… on the other hand, they *aren’t* telling you
you have to use it, they’re just saying they don’t feel comfortable
certifying it as a well-written safe driver if you don’t.
Ray
(If you want to reply to me off list, please remove “spamblock.” from my
email address)
My basic question to xxxxx@synaptics.com is, based on what he actually
quoted, how happy he or she would have been if Microsoft had made the
same stipulation requiring WDM? Its existence, and, in this sense, the
existence of KMDF itself, would seem to nullify arguments to the extent
that some of us are overreacting to the situation, as if it couldn’t
possibly occur, or even that is unlikely. It already has. I don’t mean
that critically, as that’s just part of the software development cycle,
until there exists stipulations that one must use it. As I see it, it is
a hard requirement, because “It’s not like Microsoft is saying you
*can’t* write a WDM mouse/keyboard driver, or even ship it to your
customers, they’re just saying that Microsoft doesn’t want to have
anything to do with it if you do” doesn’t, and shouldn’t mean anything
to them.
>> xxxxx@cristalink.com 2006-10-04 19:48:14 >>>
You don’t statically link to kernel32.dll either, but that doesn’t
seem to
bother anyone
The trouble is, kernel32 is present in 99.99% Windows installations,
while
KMDF must be redistributed, with all the hassles of installing it.
They fix bugs in that thing all the time and that doesn’t seem to
bother
anyone.
Yeah, right. For me, bugs in Windows are the *major* source of
problems. I
can fix my own bugs, but I can’t fix Microsoft ones. And Microsoft
won’t fix
them either, at least within a reasonable time frame, say a year or
two. I
claim this based on my own experience in multiple cases.
They don’t give you the source either, and that doesn’t seem to bother
anyone.
Yes, it does.
“Ray Trent” wrote in message
news:xxxxx@ntdev…
> You know, when this requirement was first articulated, I pitched a
big fit
> for quite some time for a lot of the same reasons people have
discussed
> here.
>
> Then I calmed down and really thought about it.
>
> First of all, KMDF is nothing like MFC. They serve entirely
different
> purposes and accomplish their goals in entirely different ways. KMDF
is
> much more like “the way WDM should have been done in the first place,
> because damn that thing is crufty and awful and way too complicated”.
> Another way of looking at it is that KMDF is a lot more like NDIS.
>
> As for the “but we can’t statically link” argument: It’s part of the
dang
> OS. You don’t statically link to kernel32.dll either, but that
doesn’t
> seem to bother anyone (and think of what a nightmare that would
be).
> They fix bugs in that thing all the time and that doesn’t seem to
bother
> anyone. They don’t give you the source either, and that doesn’t seem
to
> bother anyone.
>
> Where was the huge outrage when Microsoft “hid” all the installation
> details in UpdateDriverForPlugAndPlayDevices rather than “letting”
driver
> writers call the SetupAPI functions directly themselves?
>
> Sure, it’s new… but I suspect that a whole lot of kernel32.dll in
> Vista is brand-spanking new too. At some level we have to trust MS to
do
> their job. Frankly, I know Doron reasonably well, and that gives me
quite
> a bit of confidence that KMDF is implemented as well if not better
than
> kernel32.dll was.
>
> I don’t know anything about SDIO or cellphone drivers, but as for
> mice/keyboards, I very much doubt that anyone writing one of those is
> doing anything really all that complicated WRT the stuff that KMDF is
> “hiding”. And if they are, that’s probably a pretty big red flag
(insert
> sheepish admission that I had to figure out a few tricky ways around
how
> KMDF does things during our port because our driver was being
“bad”).
>
> It’s not like Microsoft is saying you can’t write a WDM
mouse/keyboard
> driver, or even ship it to your customers, they’re just saying that
> Microsoft doesn’t want to have anything to do with it if you do. I
don’t
> really want to have anything to do with it either…
>
> Maxim S. Shatskih wrote:
>> About KMDF. I’m very much worried about the amount of KMDF
questions
>> here
>> on forums, most of which are due to a) people do not know WDM b)
KMDF is
>> source-less. Without the kind help of Doron, these people would be
stuck.
>> Note: MFC is provided with source, and KMDF to WDM is what is
MFC to
>> Win32.
>> Also note: MFC does not free the person from knowing Win32
itself,
>> though
>> yes, the need in Win32 knowledge with MFC is very small - only to
solve
>> the
>> hard issues.
>> Any framework provides an illusion that “now all complexities
are
>> solved”.
>> Not so. The simple and streamlined things are done much easier, but,
if
>> the
>> hard issue arises - then the framework complicates the things a lot,
the
>> person
>> will need to know both the framework and the underlying platform.
>>
>>> without worrying about hidden locks, et. c. It seems to me that,
if one
>>> looks at the history of software failures, they have several things
in
>>> common, one of which is invariably the use of new and relatively
>>> untested tool to attempt solve what generally boil down to
personnel,
>>> management and budgetary problems, the last of which is for the
most
>>> part intractable in many cases; i. e. - lack of dedicated resources
for
>>> testing. I think one of the major problems with any new tool, and,
in
>>> particular, mandating its use, is that its capabilities are
evaluated by
>>> its architects and original developers, and, in the process, some
very
>>> unattractive realities about the mistakes that the general public
might
>>> make, as well as poor decisions get ignored.
>>
>> Correct. If the bla-bla architect - or just business people -
mandate
>> some
>> tool - then the chances of tool-based failure are very high. For
>> instance - the
>> user wants some feature, and the tool just crashes trying to
implement
>> it, as
>> it was with ill memored PowerBuilder in mid 90ies.
>>
>>> case with C++ - that Bjarne was able to translate real C programs
to C++
>>> with only a 2% performance drop is nice, but not all that
meaningful, as
>>> most of us are neither geniuses nor original architects. That
being
>>> said, we are not incompetent, as neither probably were the people
at
>>> Mentor Graphics, or any of the others who led the early large scale
C++
>>> projects outside of Murray Hill Labs, almost all of which failed
>>
>> IIRC Borland did the first production C++ compiler in 1990, before
this,
>> only
>> “cfront” existed. The first MS’s C++ compiler was IIRC 1992 or 1993,
>> always a
>> 32bit EXE itself - running under PharLap (PharLap embedded to the
binary)
>> on
>> DOS, in virtual DOS machine under PharLap on Windows 3.x and as
native PE
>> in
>> Windows 95/NT. This is how MSVC 1.5x worked.
>>
>> The UNIX and open-source people turned to C++ MUCH later then people
>> working
>> for DOS/Windows with Borland’s or MS’s tools.
>>
>> Maxim Shatskih, Windows DDK MVP
>> StorageCraft Corporation
>> xxxxx@storagecraft.com
>> http://www.storagecraft.com
>>
>>
>
> –
> Ray
> (If you want to reply to me off list, please remove “spamblock.” from
my
> email address)
>
—
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