I recently ran across some recently written WDM code. The reason given for using WDM over KMDF was performance. I’ve never considered KMDF to be significantly slower than WDM, but I’m willing to accept I’m wrong.
What circumstances would make choosing WDM over KMDF valid?
In what path was WDM used? In what device class is it? What type of io request flow does the driver have? Packet size, number of requests/second, etc are all important factors.
d
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com
Sent: Wednesday, November 7, 2012 4:51 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] KMDF performance
I recently ran across some recently written WDM code. The reason given for using WDM over KMDF was performance. I’ve never considered KMDF to be significantly slower than WDM, but I’m willing to accept I’m wrong.
What circumstances would make choosing WDM over KMDF valid?
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
I can’t see why you would want WDM, there are a number of approaches
that can be used if there is a specific operation that needs speedups.
Don Burn
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
“xxxxx@gmail.com” wrote in message
news:xxxxx@ntdev:
> I recently ran across some recently written WDM code. The reason given for using WDM over KMDF was performance. I’ve never considered KMDF to be significantly slower than WDM, but I’m willing to accept I’m wrong.
>
> What circumstances would make choosing WDM over KMDF valid?
Anything SPECIFIC? A great many sins have been covered-up by saying they were committed in the interest of “performance.”
When taken as a whole, end-to-end, a given KMDF driver is rarely slower than a comparable WDM driver. There may be specific, targeted, individual pieces of each driver that are faster or slower than the other… but unless those specific, individual, pieces are “make or break” for the driver then I’ve personally never seen “performance” as a valid reason to choose WDM over KMDF.
Just “performance”?? It sounds a lot like people back in the day who continued to write code in assembler language instead of a higher-level language because of “performance”… when the real reason was that they were too lazy or scared to learn how to write proper code in that higher-level language.
Peter
OSR
Pre-optimization in the absence of performance data rarely is productive,
and usually has a profound negative impact on the development time and
long-term maintainability of code.
If you don’t have the performance numbers for YOUR driver, you have no
basis for a decision about optimizations.
Lines-of-code optimizations usually gain single-digit-percentage
improvements except in very specialized cases (e.g., the inner loop of a
convolution algorithm). Architectural changes can give you orders of
magnitude improvement. Note that concepts like the “Fast I/O Path” were
developed because actual performance data indicated that the standard
mechanism was not giving adequate performance.
There were many articles on Win16 programming that were only one level
away from programming in assembly code, such as building dispatch tables
of pointers indexed by message number (and note that these tables had to
be HUGE). And there were those who said “MFC is inefficient”. Yeah, in
an absolute sense, but who cares? MFC code is easier to develop, and
easier to maintain, then raw Win32 API code, or even worse, “optimized”
code with direct-indexed dispatch tables. In fact, there are often two
complete traversals of the dispatch logic, one to decide which menu items
should be enabled and one to react to a menu item being clicked. But in a
machine that can execute several billion instructions per second, these
are not even detectable overheads.
Build your driver. Measure its performance. If you see problems, there
are optimizations that would not require dropping all the way back to WDM.
And most of the optimizations will probably be architectural.
joe
Anything SPECIFIC? A great many sins have been covered-up by saying they
were committed in the interest of “performance.”When taken as a whole, end-to-end, a given KMDF driver is rarely slower
than a comparable WDM driver. There may be specific, targeted, individual
pieces of each driver that are faster or slower than the other… but
unless those specific, individual, pieces are “make or break” for the
driver then I’ve personally never seen “performance” as a valid reason to
choose WDM over KMDF.Just “performance”?? It sounds a lot like people back in the day who
continued to write code in assembler language instead of a higher-level
language because of “performance”… when the real reason was that they
were too lazy or scared to learn how to write proper code in that
higher-level language.Peter
OSR
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminarsTo unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
xxxxx@gmail.com wrote:
I recently ran across some recently written WDM code. The reason given for using WDM over KMDF was performance. I’ve never considered KMDF to be significantly slower than WDM, but I’m willing to accept I’m wrong.
That’s silly. You do pay a small performance penalty in a UMDF driver,
but not KMDF. Whatever microscopic additional overhead it adds is more
than compensated by the improvements in robustness. It has been said in
this forum that there has never been a WDM driver that implemented power
management correctly.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Respectfully, in my experience, GDI programming was easier and easier to
debug than MFC. As no sane developer will start a new project using either
for the UI, it is probably a moot point, an perhaps it was a consequence of
my utter loathing of significant ‘features’ of C++, but I always found bugs
in MFC code particularly difficult to detect and the whole framework
fragile. GDI based code was long by comparison, but comparatively easy to
read and bugs tended to stand out, but this is all a dim memory for me now.
C# has taken over in our shop for UI development and fortunately I no longer
get sent any C++ or MFC based code to review.
wrote in message news:xxxxx@ntdev…
Pre-optimization in the absence of performance data rarely is productive,
and usually has a profound negative impact on the development time and
long-term maintainability of code.
If you don’t have the performance numbers for YOUR driver, you have no
basis for a decision about optimizations.
Lines-of-code optimizations usually gain single-digit-percentage
improvements except in very specialized cases (e.g., the inner loop of a
convolution algorithm). Architectural changes can give you orders of
magnitude improvement. Note that concepts like the “Fast I/O Path” were
developed because actual performance data indicated that the standard
mechanism was not giving adequate performance.
There were many articles on Win16 programming that were only one level
away from programming in assembly code, such as building dispatch tables
of pointers indexed by message number (and note that these tables had to
be HUGE). And there were those who said “MFC is inefficient”. Yeah, in
an absolute sense, but who cares? MFC code is easier to develop, and
easier to maintain, then raw Win32 API code, or even worse, “optimized”
code with direct-indexed dispatch tables. In fact, there are often two
complete traversals of the dispatch logic, one to decide which menu items
should be enabled and one to react to a menu item being clicked. But in a
machine that can execute several billion instructions per second, these
are not even detectable overheads.
Build your driver. Measure its performance. If you see problems, there
are optimizations that would not require dropping all the way back to WDM.
And most of the optimizations will probably be architectural.
joe
Anything SPECIFIC? A great many sins have been covered-up by saying they
were committed in the interest of “performance.”When taken as a whole, end-to-end, a given KMDF driver is rarely slower
than a comparable WDM driver. There may be specific, targeted, individual
pieces of each driver that are faster or slower than the other… but
unless those specific, individual, pieces are “make or break” for the
driver then I’ve personally never seen “performance” as a valid reason to
choose WDM over KMDF.Just “performance”?? It sounds a lot like people back in the day who
continued to write code in assembler language instead of a higher-level
language because of “performance”… when the real reason was that they
were too lazy or scared to learn how to write proper code in that
higher-level language.Peter
OSR
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminarsTo unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
It’s all about the protocols. Too many coders used MFC as if they were
programming for the raw API, and it doesn’t work well in that model. MFC
has a model for doing graphics, and if you follow it, the work is trivial
to get right. I have been programming in it since 1995 and have never had
the experiences you describe. It’s like the people who want Windows
drivers to look like their favorite RTOS and start doing things like
passing handles to event objects between user space and kernel space, in
the mistaken belief that events are somehow “faster” than
IoCompleteRequest (they aren’t; if anything, they can be slower). This
adds massive complexity to what should be a simple problem. I’ve watched
people who leared from the standard Windows API texts try to use MFC in
completely inappropriate ways, and complain bitterly when it doesn’t do
things the way they used to. (I was a 16-year veteran of the MFC
newsgroup, by the way). I can, or used to be able to, knock out an
MFC-based GUI app as fast as, or faster than, an VB programmer could.
It’s because I knew how to write to the MFC interface, and I never had
problems with “bugs”. Nor did I find the framework “fragile”. So I take
your view not with a grain of salt, but a very large sack of salt.
And I think you are confused about acronyms. GDI is doing graphics. I
have done some completely awesome graphics in MFC (for example, a shaded
cylinder that can be rotated to any angle in 3-space). There is GDI
programming, GUI programming (which includes menuing, controls, etc.) and
raw API programming. I never found an advantage to raw API programming,
and when I moved to MFC, my only distress was why it had taken me so long
to discover it.
In my Advanced Systems Programming class, I have the students build a
full-fledged GUI app using a dialog box, and we do it in 20 minutes, and
that is because I have to slow the pace to the slowest student. When I
build the same project myself, I can do the GUI part in under five
minutes. And get it right the first time.
It’s all in having the right paradigms in your head. Work against the
framework, and you’re screwed. Work with it, and things are easy.
Compare “inverted call” to the baroque event-notification crap people seem
to reinvent with frightening regularity. Building a complex solution to a
simple problem by ignoring the framework paradigms is a losing game.
joe
Respectfully, in my experience, GDI programming was easier and easier to
debug than MFC. As no sane developer will start a new project using
either
for the UI, it is probably a moot point, an perhaps it was a consequence
of
my utter loathing of significant ‘features’ of C++, but I always found
bugs
in MFC code particularly difficult to detect and the whole framework
fragile. GDI based code was long by comparison, but comparatively easy to
read and bugs tended to stand out, but this is all a dim memory for me
now.
C# has taken over in our shop for UI development and fortunately I no
longer
get sent any C++ or MFC based code to review.wrote in message news:xxxxx@ntdev…
Pre-optimization in the absence of performance data rarely is productive,
and usually has a profound negative impact on the development time and
long-term maintainability of code.If you don’t have the performance numbers for YOUR driver, you have no
basis for a decision about optimizations.Lines-of-code optimizations usually gain single-digit-percentage
improvements except in very specialized cases (e.g., the inner loop of a
convolution algorithm). Architectural changes can give you orders of
magnitude improvement. Note that concepts like the “Fast I/O Path” were
developed because actual performance data indicated that the standard
mechanism was not giving adequate performance.There were many articles on Win16 programming that were only one level
away from programming in assembly code, such as building dispatch tables
of pointers indexed by message number (and note that these tables had to
be HUGE). And there were those who said “MFC is inefficient”. Yeah, in
an absolute sense, but who cares? MFC code is easier to develop, and
easier to maintain, then raw Win32 API code, or even worse, “optimized”
code with direct-indexed dispatch tables. In fact, there are often two
complete traversals of the dispatch logic, one to decide which menu items
should be enabled and one to react to a menu item being clicked. But in a
machine that can execute several billion instructions per second, these
are not even detectable overheads.Build your driver. Measure its performance. If you see problems, there
are optimizations that would not require dropping all the way back to WDM.
And most of the optimizations will probably be architectural.
joe> [quote]
> The reason given for using WDM over KMDF was performance.
> [/quote]
>
> Anything SPECIFIC? A great many sins have been covered-up by saying
> they
> were committed in the interest of “performance.”
>
> [quote]
> I’ve never considered KMDF to be significantly slower than WDM, but I’m
> willing to accept I’m wrong.
> [/quote]
>
> When taken as a whole, end-to-end, a given KMDF driver is rarely slower
> than a comparable WDM driver. There may be specific, targeted,
> individual
> pieces of each driver that are faster or slower than the other… but
> unless those specific, individual, pieces are “make or break” for the
> driver then I’ve personally never seen “performance” as a valid reason
> to
> choose WDM over KMDF.
>
> Just “performance”?? It sounds a lot like people back in the day who
> continued to write code in assembler language instead of a higher-level
> language because of “performance”… when the real reason was that they
> were too lazy or scared to learn how to write proper code in that
> higher-level language.
>
> Peter
> OSR
>
> —
> 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/seminarsTo unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
> this forum that there has never been a WDM driver that implemented power
management correctly.
Including MS’s inbox ones?
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com
Pretty much, yes. All of the wdm based ones have had bugs in pnp or power over the years
d
debt from my phone
From: Maxim S. Shatskih
Sent: 11/8/2012 7:42 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] KMDF performance
this forum that there has never been a WDM driver that implemented power
management correctly.
Including MS’s inbox ones?
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com
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
Have you ever SEEN a state-diagram of the KMDF PnP/Power State Machine? To say that it’s enormous is not an understatement. Seriously. It took up several FEET of wall-space when last I looked.
Do you know how LONG it took two rather senior people to devise that state machine? Multiple years. WITH access to the source code, and WITH considerable WDM experience, and WITH directly daily access to the dev owners of the PnP and Power code in the OS.
Do you think there’s EVER been a driver for which anybody has done similar work? No chance.
Sure, the KMDF PnP/Power state machine is more generic, and has to work in every stack, and that DOES contribute to its complexity.
You might have a well-written WDM driver might have a PnP/Power state machine that works “pretty well” and which never exhibits any problems… but that probably just means that the edge conditions that the driver doesn’t handle simply haven’t been seen yet.
Peter
OSR
> Have you ever SEEN a state-diagram of the KMDF PnP/Power State Machine?
Yes 
But I was always thinking that MS’s guys who wrote things like SCSIPORT and USB stack do have proper contacts with the PnP/Power guys and thus inbox drivers are OK.
Also, MSDN contains the verbal documentation which corresponds to these diagrams, and yes it is possible to write the state machines according to it.
Also, passing PNPDTEST and PWRTEST is possible. Did this personally.
It took up several FEET of wall-space when last I looked.
Several A0 sheets.
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com
Max,
There is no way that the MSDN documentation conforms to the state
diagrams. When they showed them at the last DDC the diagrams were a
huge number of states, the documentation would take a book and probably
have errors!
Don Burn
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
“Maxim S. Shatskih” wrote in message
news:xxxxx@ntdev:
> > Have you ever SEEN a state-diagram of the KMDF PnP/Power State Machine?
>
> Yes
>
> But I was always thinking that MS’s guys who wrote things like SCSIPORT and USB stack do have proper contacts with the PnP/Power guys and thus inbox drivers are OK.
>
> Also, MSDN contains the verbal documentation which corresponds to these diagrams, and yes it is possible to write the state machines according to it.
>
> Also, passing PNPDTEST and PWRTEST is possible. Did this personally.
>
> >It took up several FEET of wall-space when last I looked.
>
> Several A0 sheets.
>
> –
> Maxim S. Shatskih
> Windows DDK MVP
> xxxxx@storagecraft.com
> http://www.storagecraft.com
As I said, you can write a PnP/Power state machine that *appears* to work, and that works in all mainline situations. But, without massive effort, there will be NUMEROUS edge conditions that your implementation does not handle.
These only test main-line power paths. Passing these tests is a test of the barest *minimum* correct PnP/Power functioning for a driver. This is relatively simple. Note I didn’t say EASY. I said “relatively simple”, compared to the comprehensive handling in KMDF.
Well, yes, but “several” doesn’t really capture the extent of it. When I last saw this diagram, it was something like seven feet long by maybe four feet high – that is indeed SEVERAL A0 sheets.
Here’s what I consider to be the definitive demonstration: How many WDM drivers have you seen that implement an integrated PnP and Power Management state machine? You know, one with actual STATES, that doesn’t rely on a few flags and that doesn’t merely ASSUME a whole lot about the order in which things are called?
Outside of OSR-written WDM drivers (which I am ABSOLUTELY NOT asserting are comprehensive in their PnP/Power handling IN ANY WAY) and KMDF, I’ve never seen a WDM driver done with a PnP/Power state machine. They merely assume “Oh, I got an X, that must mean I’ve already gotten a Y”…
Peter
OSR
Yes, Peter, there has been another: pci.sys in Windows 8.
I had to do it for a couple of reasons. PCI can’t be converted to WDF without breaking backward compatibility. Doron and I intentionally traded off some of PCI’s functionality when we built WDF because it would have tripled the size of the WDF state machines to be able to both act like PCI already happened to act and also act like we wanted it to act. Keeping PCI’s PDO behavior consistent involves never moving to WDF. We have no idea if the corner cases that would differ matter to any drivers out there, but we suspect they do. Hell, I broke one driver in Windows 8 by completing D0 IRPs at DISPATCH_LEVEL, something that the WDK clearly says will happen, but which the Windows 7 PCI driver never actually did.
And making PCI do aggressive runtime power management when the BIOS says it can and do what it always did when the BIOS says it can’t was complicated enough that I had to take the same approach that we took in WDF.
P.S. You’re exaggerating the time it took us to build the WDF implementation. I only worked on it for six months. Doron spent somewhat less than a year. It’s been tweaked and extended a few times since then, most notably for PoFx integration in Win8.
From: xxxxx@lists.osr.com on behalf of xxxxx@osr.com
Sent: Friday, November 09, 2012 6:30 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] KMDF performance
Have you ever SEEN a state-diagram of the KMDF PnP/Power State Machine? To say that it’s enormous is not an understatement. Seriously. It took up several FEET of wall-space when last I looked.
Do you know how LONG it took two rather senior people to devise that state machine? Multiple years. WITH access to the source code, and WITH considerable WDM experience, and WITH directly daily access to the dev owners of the PnP and Power code in the OS.
Do you think there’s EVER been a driver for which anybody has done similar work? No chance.
Sure, the KMDF PnP/Power state machine is more generic, and has to work in every stack, and that DOES contribute to its complexity.
You might have a well-written WDM driver might have a PnP/Power state machine that works “pretty well” and which never exhibits any problems… but that probably just means that the edge conditions that the driver doesn’t handle simply haven’t been seen yet.
Peter
OSR
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
YAY!
Very interesting what you say about PCI.SYS never being able to be a KMDF driver. I guess I’m not shocked. It’s obviously so more than just “another bus driver” – it really is a foundational component of the OS at this point.
[quote]
Hell, I broke one driver in Windows 8 by completing D0 IRPs at DISPATCH_LEVEL,
something that the WDK clearly says will happen, but which the Windows 7 PCI
driver never actually did.
[quote]
Too funny. But, indicative of all sorts of implicit assumptions in other drivers, I’m sure.
Thanks for correcting that.
That just goes to show how memory can trick you.
When I was thinking back and wrote that, I could have SWORN it was like 2 years worth of work. I’ve clearly mythologized the actual event :-0
Peter
OSR
Video, network and storage port drivers the most essential drivers on a
PC are still not KMDF. Are they on the way? I’m curios because I once made
a living of writing miniport drivers of them for some of the very popular
chips which can be found everywhere.
Calvin
On Fri, Nov 9, 2012 at 10:56 AM, wrote:
>
>
> YAY!
>
> Very interesting what you say about PCI.SYS never being able to be a KMDF
> driver. I guess I’m not shocked. It’s obviously so more than just
> “another bus driver” – it really is a foundational component of the OS at
> this point.
>
>
[quote]
> Hell, I broke one driver in Windows 8 by completing D0 IRPs at
> DISPATCH_LEVEL,
> something that the WDK clearly says will happen, but which the Windows 7
> PCI
> driver never actually did.
>
[quote]
>
> Too funny. But, indicative of all sorts of implicit assumptions in other
> drivers, I’m sure.
>
>
>
> Thanks for correcting that.
>
> That just goes to show how memory can trick you.
>
> When I was thinking back and wrote that, I could have SWORN it was like 2
> years worth of work. I’ve clearly mythologized the actual event :-0
>
> Peter
> OSR
>
> —
> 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
>
Nothing to do with perf, everything to do with compatibility. Changing to kmdf doesn’t add value and adds risk in terms of compat…and you still need the old port driver there for existing miniports
d
debt from my phone
From: Calvin Guan (news)
Sent: 11/9/2012 3:11 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] KMDF performance
Video, network and storage port drivers the most essential drivers on a PC are still not KMDF. Are they on the way? I’m curios because I once made a living of writing miniport drivers of them for some of the very popular chips which can be found everywhere.
Calvin
On Fri, Nov 9, 2012 at 10:56 AM, > wrote:
YAY!
Very interesting what you say about PCI.SYS never being able to be a KMDF driver. I guess I’m not shocked. It’s obviously so more than just “another bus driver” – it really is a foundational component of the OS at this point.
[quote]
Hell, I broke one driver in Windows 8 by completing D0 IRPs at DISPATCH_LEVEL,
something that the WDK clearly says will happen, but which the Windows 7 PCI
driver never actually did.
[quote]
Too funny. But, indicative of all sorts of implicit assumptions in other drivers, I’m sure.
Thanks for correcting that.
That just goes to show how memory can trick you.
When I was thinking back and wrote that, I could have SWORN it was like 2 years worth of work. I’ve clearly mythologized the actual event :-0
Peter
OSR
—
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
Well, I didn’t expect moving to KMDF will buy any perf. I was thinking that
ndis.sys, storport.sys may not be handling PNP/PO as elegant as KMDF does.
It’s possible to maintain the miniport existing interface while porting the
PNP/PO part to kmdf.
On the other hand, I do understand the risks of updating these 3 crucial
drivers unless they are completely broken on PNP/Po.
Calvin
On Fri, Nov 9, 2012 at 3:19 PM, Doron Holan wrote:
> Nothing to do with perf, everything to do with compatibility. Changing
> to kmdf doesn’t add value and adds risk in terms of compat…and you still
> need the old port driver there for existing miniports
>
>
> d
>
> debt from my phone
> ------------------------------
> From: Calvin Guan (news)
> Sent: 11/9/2012 3:11 PM
>
> To: Windows System Software Devs Interest List
> Subject: Re: [ntdev] KMDF performance
>
>
> Video, network and storage port drivers the most essential drivers on a
> PC are still not KMDF. Are they on the way? I’m curios because I once made
> a living of writing miniport drivers of them for some of the very popular
> chips which can be found everywhere.
>
> Calvin
>
> On Fri, Nov 9, 2012 at 10:56 AM, wrote:
>
>>
>>
>> YAY!
>>
>> Very interesting what you say about PCI.SYS never being able to be a KMDF
>> driver. I guess I’m not shocked. It’s obviously so more than just
>> “another bus driver” – it really is a foundational component of the OS at
>> this point.
>>
>>
[quote]
>> Hell, I broke one driver in Windows 8 by completing D0 IRPs at
>> DISPATCH_LEVEL,
>> something that the WDK clearly says will happen, but which the Windows 7
>> PCI
>> driver never actually did.
>>
[quote]
>>
>> Too funny. But, indicative of all sorts of implicit assumptions in other
>> drivers, I’m sure.
>>
>>
>>
>> Thanks for correcting that.
>>
>> That just goes to show how memory can trick you.
>>
>> When I was thinking back and wrote that, I could have SWORN it was like 2
>> years worth of work. I’ve clearly mythologized the actual event :-0
>>
>> Peter
>> OSR
>>
>> —
>> 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
>
I have spent the best part of the last decade reviewing code. Code of all
descriptions including everything from KM C & assembler code, to T-SQL
stored procedures and VB Script and everything I am compelled to look at, I
judge based on the same metrics. How difficult is it to
In my personal case, I don’t really care how quick and easy it is to author
an application using a wizard, I care about how difficult my job of
reviewing and correcting your work is. Any yes, I am arrogant or foolish
enough to insinuate that your work, even though you hold a PhD and have
taught programming for many years and I have no academic credentials what so
ever, would need correction.
I suppose it is also a matter of standards too. Around here, I am
responsible for establishing coding standards and then upholding them no
matter how many millions of dollars a day they may cost. It does tend to
make one very particular about certain things; or long for the days when one
actually wrote code.
wrote in message news:xxxxx@ntdev…
It’s all about the protocols. Too many coders used MFC as if they were
programming for the raw API, and it doesn’t work well in that model. MFC
has a model for doing graphics, and if you follow it, the work is trivial
to get right. I have been programming in it since 1995 and have never had
the experiences you describe. It’s like the people who want Windows
drivers to look like their favorite RTOS and start doing things like
passing handles to event objects between user space and kernel space, in
the mistaken belief that events are somehow “faster” than
IoCompleteRequest (they aren’t; if anything, they can be slower). This
adds massive complexity to what should be a simple problem. I’ve watched
people who leared from the standard Windows API texts try to use MFC in
completely inappropriate ways, and complain bitterly when it doesn’t do
things the way they used to. (I was a 16-year veteran of the MFC
newsgroup, by the way). I can, or used to be able to, knock out an
MFC-based GUI app as fast as, or faster than, an VB programmer could.
It’s because I knew how to write to the MFC interface, and I never had
problems with “bugs”. Nor did I find the framework “fragile”. So I take
your view not with a grain of salt, but a very large sack of salt.
And I think you are confused about acronyms. GDI is doing graphics. I
have done some completely awesome graphics in MFC (for example, a shaded
cylinder that can be rotated to any angle in 3-space). There is GDI
programming, GUI programming (which includes menuing, controls, etc.) and
raw API programming. I never found an advantage to raw API programming,
and when I moved to MFC, my only distress was why it had taken me so long
to discover it.
In my Advanced Systems Programming class, I have the students build a
full-fledged GUI app using a dialog box, and we do it in 20 minutes, and
that is because I have to slow the pace to the slowest student. When I
build the same project myself, I can do the GUI part in under five
minutes. And get it right the first time.
It’s all in having the right paradigms in your head. Work against the
framework, and you’re screwed. Work with it, and things are easy.
Compare “inverted call” to the baroque event-notification crap people seem
to reinvent with frightening regularity. Building a complex solution to a
simple problem by ignoring the framework paradigms is a losing game.
joe
Respectfully, in my experience, GDI programming was easier and easier to
debug than MFC. As no sane developer will start a new project using
either
for the UI, it is probably a moot point, an perhaps it was a consequence
of
my utter loathing of significant ‘features’ of C++, but I always found
bugs
in MFC code particularly difficult to detect and the whole framework
fragile. GDI based code was long by comparison, but comparatively easy to
read and bugs tended to stand out, but this is all a dim memory for me
now.
C# has taken over in our shop for UI development and fortunately I no
longer
get sent any C++ or MFC based code to review.wrote in message news:xxxxx@ntdev…
Pre-optimization in the absence of performance data rarely is productive,
and usually has a profound negative impact on the development time and
long-term maintainability of code.If you don’t have the performance numbers for YOUR driver, you have no
basis for a decision about optimizations.Lines-of-code optimizations usually gain single-digit-percentage
improvements except in very specialized cases (e.g., the inner loop of a
convolution algorithm). Architectural changes can give you orders of
magnitude improvement. Note that concepts like the “Fast I/O Path” were
developed because actual performance data indicated that the standard
mechanism was not giving adequate performance.There were many articles on Win16 programming that were only one level
away from programming in assembly code, such as building dispatch tables
of pointers indexed by message number (and note that these tables had to
be HUGE). And there were those who said “MFC is inefficient”. Yeah, in
an absolute sense, but who cares? MFC code is easier to develop, and
easier to maintain, then raw Win32 API code, or even worse, “optimized”
code with direct-indexed dispatch tables. In fact, there are often two
complete traversals of the dispatch logic, one to decide which menu items
should be enabled and one to react to a menu item being clicked. But in a
machine that can execute several billion instructions per second, these
are not even detectable overheads.Build your driver. Measure its performance. If you see problems, there
are optimizations that would not require dropping all the way back to WDM.
And most of the optimizations will probably be architectural.
joe> [quote]
> The reason given for using WDM over KMDF was performance.
> [/quote]
>
> Anything SPECIFIC? A great many sins have been covered-up by saying
> they
> were committed in the interest of “performance.”
>
> [quote]
> I’ve never considered KMDF to be significantly slower than WDM, but I’m
> willing to accept I’m wrong.
> [/quote]
>
> When taken as a whole, end-to-end, a given KMDF driver is rarely slower
> than a comparable WDM driver. There may be specific, targeted,
> individual
> pieces of each driver that are faster or slower than the other… but
> unless those specific, individual, pieces are “make or break” for the
> driver then I’ve personally never seen “performance” as a valid reason
> to
> choose WDM over KMDF.
>
> Just “performance”?? It sounds a lot like people back in the day who
> continued to write code in assembler language instead of a higher-level
> language because of “performance”… when the real reason was that they
> were too lazy or scared to learn how to write proper code in that
> higher-level language.
>
> Peter
> OSR
>
> —
> 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/seminarsTo unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer