So, Anton, Microsoft acknowledged years ago that there were significant holes in their implementation, why do you think
you can get it right by yourself
OMG…
I am DEFINITELY not saying anything like that. If you bother yourself with checking my very first statement on this thread, you will see that I am asking “Why do you want to write a WDM driver in the year 2020,in the first place???”
The only thing that I am saying is that the assertion that I was/is arguing about is a very obvious (at least from my perspective) example of unnecessary hype. I am most certainly not saying that someone should try writing a PnP driver in WDM when WDF is available, which would be a very stupid thing indeed…
I was/is arguing about is a very obvious (at least from my perspective) example of unnecessary hype
Actually, the more I think about it, I would assert that the statement “there has NEVER been a WDM driver that handles power management correctly until KMDF came along” is either literally correct, or so very close to being literally correct that it’s not worth arguing.
Regardless of the statement’s literal correctness, consider the conclusions one is asked to come to from this statement. Among them:
In the days of WDM, drivers had enormous problems with PnP/Power handling – PnP/Power was The Number One problem pre-KMDF. That and IRP cancellation, actually, vie for first place in the pantheon of “Why WDM drivers crash.” This is true regardless of whether the drivers were in-box or third party provided.
The KMDF team solved this problem by creating The Definitive State Machine for handling PnP/Power. Creating this was a lot of work, and took vast amounts of “insider” resources (Windows source code, access to the dev owners of multiple components).
It is folly for anyone to think that they fully understand Power Management/PnP from the WDM perspective without having similar knowledge to that of the KMDF devs, or an understanding of The Definitive State Machine. And without such knowledge, how could an entirely “correct” WDM driver be developed? I GUESS if you had a monkey and a keyboard and waited LONG enough it might happen at random EVENTUALLY…
It is foolish to write a device driver that supports PnP/Power today using WDM, if WDF can be used for the purpose.
This, in turn, makes one wonder how Win2K and Windows XP managed to run not only without causing widespread
fires and explosions, but even without damaging the hardware on more or less regular basis …
Maybe you weren’t monitoring the forums at the turn of the century, when people were starting to try Win2K and early XP on laptops. The experience was not positive, in large part because drivers were Doing It Wrong.
The server experience was much better, of course, because such systems rarely get any power activity.
I think i am going on the right way. Are there any sources other than msdn that you can recommend to me? (e-books, class, article etc.)
That’s a good place to start. It’s impossible to tell how much experience you have. Clearly, you were good enough with the mechanics to get a simple driver to run, but what you’re missing is design and philosophy. A key part of living in the kernel ecosystem is understanding how drivers are connected to each other to make up a stack, and how you can participate in that stack in a tested and well-ordered way.
OSR has a “learning library” of articles on drivers they’ve collected over the decades. An OSR driver class would never be a bad idea. There are books on WDF/KMDF, although a lot of them focus on mechanics as well. Back issues of OSR’s NT Insider are a good resource.
Your ability to troll a thread astounds me, even after all these years
Well, I do what I can
An even casually competent engineer will understand that there is a world of difference between an implementation
being “correct” and an implementation working well enough “most of the time.”
Well, I don’t really know about you, but on my books. the very phrase "an implementation working well enough most of the time "
is just a very obvious euphemism for a “heisenbug”, i.e for a buggy software that mostly works as expected but may fail
in some edge cases, while a “correct” program is the one that works as expected in 100% cases. Please note that being “correct” does not necessarily imply being optimal, but the results a correct program produces are correct and 100% predictable. This is what makes it different from the one that ""works well enough most of the time”.
In context of this discussion, a “correct but not optimal” implementation of ACPI driver would imply, for example, not taking the full advantage of the laptop battery’s capabilities, while "working well enough most of the time " one would imply, for example, occasional CPU resets (I mean abrupt and unpredictable resets, rather than “polite” BSODs) due to overheating at the very minimum, and, probably, even occasional damage caused to the hardware in more extreme cases.
Clearly, the in-box WDM drivers handled PnP and Power right “most of the time.” That does not make them correct.
So were they “correct but not optimal” or "working well enough most of the time”?
try a little harder to make arguments that aren’t so obviously ignorant.
Well, as you can see it yourself, I try my best to provide a technically sound argumentation, while some other posters prefer
to stay on “ad hominem side”
Hi Tim < It’s impossible to tell how much experience you have. 17 Thank you for your help. I also thank everyone else who wants to help. For now, I will move away from the forum and work on the subject. I will try to progress with your suggestions. There will probably be other things I would like to ask you. See you till then. Best Regards.
I’m sure we miss the point by just deriding Anton.
Well, Marion, in fact, the only one who really missed the point here is Truly Yours.
This point is eternal and truly universal. It stands as “Don’t argue with those who are in a position to pull the plug out”, and I keep on missing this point all my life long…
