Anyone outside of MSFT see DMF coming?

I wish I could admit to only *one* failing.
-dc

Sent from my Windows 10 phone

>As long as you do it once this is not a big deal - after all, I accidentally wrote “hummer” instead of

“hammer” once (and got a fair share of well-deserved derision on NTDEV for it, of course).

That jewel would have been lost, too, under the initial Jan. 1, 2010 date for archive migration. :wink:

http:

Gabe</http:>

Well, THERE you go. THE definitive reason for keeping the archives “back to the beginning.”

Just so we can further derail this thread, and hide important information from the unsuspecting, as of yesterday we have confirmed that we CAN migrate all the data. The early posts are pretty funny, though, because almost all the corresponding users have since been deleted (due to their leaving NTDEV, changing email addresses, or whatever). So there are thread that have no recognizable usernames associated with them.

But… we WILL have them!

Peter
OSR
@OSRDrivers

If you call it a jewel…well, I just wonder what you are going to say about the following one

http://www.osronline.com/showThread.cfm?link=130088

Unfortunately, the most exciting part of it had been removed by our hosts ( which proves yet another time that deleting the stuff that made its way on the Internet is generally a bad idea), but it is still a true piece of classic. In fact, most of the " epic threads" would have been lost…

Certainly, some “exciting stuff” would still be left. For example, what do you think about the following one

http://www.osronline.com/showThread.cfm?link=268241

Anton Bassov

My GOODness… that “Mixing C and C++ files in a driver project” thread from 2008 was quite a good one, wasn’t it. I had forgotten how absolutely chock-full of goodness that thread was.

We were treated to Mr. Burn calling me a “stupid IDIOT for naming [my] files .CPP”, we had actual useful and intelligent contributions from the late David Craig, who I miss greatly (and to whom I should have conceded the point about using CPP file types in larger corporations), a long debate about whether Windows Vista was any good, the NBA, Packard Bell, INF file formats, the prescience of David Farley in 1996 for this cartoon: http:, as well as several other topics.

Contributions from soooo many luminaries of the Windows driver world: Mr. Craig, Mr. Burn, Mr. Bassov (of course), Mr. Roberts, the late great Mr. Divine, Mr. O’Brien, Mr. Patzke, Mr. Shatskih, Mr. Trent, Mr. Cattley, Mr. Roddy, Mr. Wieland, Mr. Shcnieder, Mr. Vodicka, Mr. Sinha, Mr. Noone, and of course… Mr. Kyler (whose primary contributions have been permanently deleted).

You can see here that it WILL be moved forward to the new Community site, in all its glory:
https:

Peter
OSR
@OSRDrivers</https:></http:>

Peter Viscarola wrote:

and of course… Mr. Kyler (whose primary contributions have been
permanently deleted).

I don’t know if anyone else is interested but it seems “Mr. Kyler” did quite well for himself after the “genocide” episode… sold his company to Dell for an “undisclosed amount”… wonder if he’s still lurking here, worrying about Anton’s email alias…

Apparently they got so impressed by his spinlock implementation
(http://www.osronline.com/showThread.cfm?link=122194, post No 90)
that they decided to buy his company for few dozen (or, maybe, even hundred) million USD just in order to have his “algorithm” in their patent portfolio. Therefore, you have to be careful whenever you decide to implement a spinlock as a tight polling loop of interlocked operations - you may get sued for patent violation…

Anton Bassov

I’d managed to purge all memory of Alberto - and now it’s back.

Mark Roddy

On Thu, Aug 23, 2018 at 6:37 PM xxxxx@hotmail.com <
xxxxx@lists.osr.com> wrote:

Apparently they got so impressed by his spinlock implementation
(http://www.osronline.com/showThread.cfm?link=122194, post No 90)
that they decided to buy his company for few dozen (or, maybe, even
hundred) million USD just in order to have his “algorithm” in their patent
portfolio. Therefore, you have to be careful whenever you decide to
implement a spinlock as a tight polling loop of interlocked operations -
you may get sued for patent violation…

Anton Bassov


NTDEV is sponsored by OSR

Visit the list online at: <
http://www.osronline.com/showlists.cfm?list=ntdev\>

MONTHLY seminars on crash dump analysis, WDF, Windows internals and
software drivers!
Details at http:
>
> To unsubscribe, visit the List Server section of OSR Online at <
> http://www.osronline.com/page.cfm?name=ListServer&gt;
></http:>

Hello,

I am Sam, from Microsoft Devices Group. I am on the team that developed DMF. I want to thank everyone for their time spent looking at DMF and giving feedback about DMF on this thread.

The purpose of my post is to iet you know that we will be discussing DMF at WinHEC in Taipei and Shenzhen this week and next in one session and labs. Furthermore, I will be available throughout the four days and I am able to discuss DMF with anyone who is interested. The sessions are only one hour long so there is only time for an introduction and discussion about some DMF topics. But, outside sessions I am able to have in-depth discussions with anyone interested.

DMF can be described in summary like this:

“DMF allows programmers to create Modules that receive WDF callbacks directly. DMF manages the lifetime of the Modules. Every Module is a WDFOBJECT. Modules can use other Modules to create other Modules. Modules can only communicate when they are in a Parent-Child relationship. DMF stores all the Modules in a tree and distributes WDF callbacks to all the Modules in the tree, then dispatches the callbacks to the Client driver. This makes it possible to do formal object oriented programming inside WDF drivers because each Module has its own logic for dealing with and WDF callback. The Client driver does not need to even know what callbacks any Module supports.”

Main page: https://github.com/Microsoft/DMF
Documentation: https://github.com/Microsoft/DMF/blob/master/Dmf/Documentation/Driver%20Module%20Framework.md
Samples: https://github.com/Microsoft/DMF/tree/master/DmfSamples

Soon, there will be more samples that are more complex.

This posting is provided “AS IS” with no warranties and confer no rights.

we will be discussing DMF at WinHEC in Taipei and Shenzhen

Please don’t get me started on why WinHEC is being held AGAIN in Taipei and Shenzhen. I can’t tell you how much that annoys me, and how utterly disrespectful I find that to the US and European driver development community. We have discussed this here in the past at length.

I get that’s not your issue, Sam… And I really don’t mean to “shoot the messenger” on this topic. So… I will shut up now.

Best of luck with your presentations (sincerely)… please feel free to post a link to your talk (or the slides) when they’re available.

Peter

PeterGV_via_GMAIL wrote:

Please don’t get me started on why …

&nbps;

&nbps;

&nbps;

Say it with me: “Non-Breaking SPace”…     :wink:

Say it with me: "Non-Breaking SPace

You have discovered a hidden cost of reading the forum via email. I can go back and revise history! “Edit” is my friend!

Peter

Hello,

The presentation and slides shown at WinHEC is now available on the web here:

https://www.WinHEC.com

Please look for the video called, “Introduction to Driver Module Framework”. This presentation gives a high level overview of the purpose of DMF and the problems it wants to solve. Release v1.1.1 is available on the GitHUB site and contains several improvements made based on recent feedback from users.

Main page: https://github.com/Microsoft/DMF
Documentation: https://github.com/Microsoft/DMF/blob/master/Dmf/Documentation/Driver Module Framework.md
Samples: https://github.com/Microsoft/DMF/tree/master/DmfSamples

Feeback email address: dmf-feedback@microsoft.com

This posting is provided “AS IS” with no warranties and confer no rights.

I watched the presentation on DMF optimistically and it was a heart sinking pitch.

I knew immediately there was something very wrong when he started talking about using handles. Handles are error prone, add code complexity, and are a leftover legacy that others stopped using decades ago. Ever heard of methods for an object? Jig.DoThis() is preferred over those farcical DMF_DmfDoThis(JigHandle) calls. And those nasty ultra long decorated function names become unnecessary.

Then I about shutoff the presentation when he gloated “the client gives a list of supported ioctls”. Ever heard of virtual function overrides? The client only writes the functions they care about and it magically works without the error prone process of synchronizing with a list of supported calls.

Then I watched in horror the slides with initializing code. My god, I have never seen such a mess. Look at all those lines of code and how wide they are. It should have been so much simpler, easier, and cleaner.

Recap: It’s great to see Microsoft clean up some of the WDF deficiencies with DMF. But the refusal of Microsoft to go the extra step and leverage the power of c++ means we are once again shackled with a sub-optimal framework that is cumbersome, ugly, hard to learn, error prone, and with an antiquated 1980’s look and feel.

Rourke wrote:

Then I watched in horror the slides with initializing code. My god, I have never seen such a mess. Look at all those lines of code and how wide they are. It should have been so much simpler, easier, and cleaner.

But they are consistent, not only with each other, but with WDF as
well.  That makes them relatively discoverable, and I applaud that.

Recap: It’s great to see Microsoft clean up some of the WDF deficiencies with DMF. But the refusal of Microsoft to go the extra step and leverage the power of c++ means we are once again shackled with a sub-optimal framework that is cumbersome, ugly, hard to learn, error prone, and with an antiquated 1980’s look and feel.

Although I largely agree with you, the sad fact is that a substantial
proportion of the dinosaur driver community is still allergic to C++. 
Microsoft had to target C, or it would have been ignored.

Is targeting the lowest common denominator (the dinosaurs) good for the future of the platform? After all WDF is C and available to all so there already is something for everyone. The state of the art framework should embrace state of the art language features that make sense instead of deliberately dragging everyone down to doing things the way their grandparents were taught.

@Rourke said:
I watched the presentation on DMF optimistically and it was a heart sinking pitch.

I knew immediately there was something very wrong when he started talking about using handles. Handles are error prone, add code complexity, and are a leftover legacy that others stopped using decades ago. Ever heard of methods for an object? Jig.DoThis() is preferred over those farcical DMF_DmfDoThis(JigHandle) calls. And those nasty ultra long decorated function names become unnecessary.

Then I about shutoff the presentation when he gloated “the client gives a list of supported ioctls”. Ever heard of virtual function overrides? The client only writes the functions they care about and it magically works without the error prone process of synchronizing with a list of supported calls.

Then I watched in horror the slides with initializing code. My god, I have never seen such a mess. Look at all those lines of code and how wide they are. It should have been so much simpler, easier, and cleaner.

Recap: It’s great to see Microsoft clean up some of the WDF deficiencies with DMF. But the refusal of Microsoft to go the extra step and leverage the power of c++ means we are once again shackled with a sub-optimal framework that is cumbersome, ugly, hard to learn, error prone, and with an antiquated 1980’s look and feel.

Thank you for taking time to watch the presentation and give your comments. I would like to address your comments:

  1. A primary goal was to make DMF look and feel like WDF as much as possible for several reasons:

    a) DMF is built using WDF and many of the concepts in DMF are borrowed from WDF.

    b) To make it easy for WDF programmers to understand how to use DMF, we wanted DMF look and feel like WDF.

    c) We wanted C Client Drivers (especially existing C drivers) to be able to use DMF as easily as they use WDF. Thus all the interfaces are compatible with C and C++ (instead of just C++).

  2. The code in the slides was designed to make it easy to read in a very large room. Please look at the code in the DMF repository. You will see it is well documented and stylistically clean and consistent with how most Windows device drivers are written. There are abundant comments. I specifically stated in the presentation that the on the slides presented for readability and so that it would fit on the slide.

Please note further that DMF is not just a a library. DMF is designed specifically so that programmers can easily make thair own Modules in a way that the interfaces are always compatible with other Modules and drivers that use DMF. Many decisions about DMF were made with that in mind.

Thank you again for your feedback. I hope I have addressed your comments thoughtfully.

You are welcome to send feedback to dmf-feedback@microsoft.com in addition to this forum. We have received a lot feedback and we have addressed many comments with recent updates.

This posting is provided “AS IS” with no warranties and confer no rights.

On Nov 26, 2018, at 7:01 PM, Rourke wrote:
>
> Is targeting the lowest common denominator (the dinosaurs) good for the future of the platform? After all WDF is C and available to all…

Technically, WDF is C++ with a C wrapper, exactly the same as DMF.

> The state of the art framework should embrace state of the art language features that make sense instead of deliberately dragging everyone down to doing things the way their grandparents were taught.

Although it hurts me, I have to disagree. The kernel should not be the place where we live on the cutting edge of language features. It needs to be reliable, predictable, and stable. Now, I would argue that even C++11 falls into that category at this point, but inertia in the Windows world is a heavy burden.

Tim Roberts, timr@probo.com
Providenza & Boekelheide, Inc.

This is the 21st Century. A well constrained native C++ approach to driver development would be most welcome at this point, even by those who think C++ is a terrible language (like me). There are devs these days, good devs, who’ve never know any other approach than OOP.

Let’s also be clear: DMF is the product of one (very talented) team at MSFT, that has been generously open sourced and “donated” to the Community. DMF is not a Microsoft supported method for developing drivers. It does not necessarily represent Microsoft’s view of how the platform should evolve (to the extent that there even is such a thing).

Peter

1 Like

I recall when handles started to appear in the 1980s in places like Dos and Novell Netware to name a few. There were a lot of respected, old school developers who balked at this new fangled approach. They were used to interacting with operating system data structures directly and resisted being insulated from this by function calls. They also wrote flags and bit masks in hexadecimal because they did not want anything shielding them from what was happening. They did not want driver kits making enums or #defines because it buried information that belonged in their code. And I was there.

Thus, the value of the old crowd defending the old ways in influencing strategic decisions should be listened to cautiously. When people see how much better code they can write with new language features no one will want to go back to the ways of their grandparents. And when that day comes the windows platform will benefit tremendously. Just look around outside the driver box; people are running circles around our productivity.

By cutting edge language features I actually mean just simple things to make life better as I highlighted in my original post would have tremendous benefits. Even though some of these things are 40 years old some here I suspect don’t even know of them. There are also good reasons to use even the most recent language additions. Bit literals come to mind. Just use what makes sense.

If we were the 1980’s DMF would be a very fine and welcome development kit. It’s very consistent with the conventions used at that time and on par with what Novell Netware was doing with handles and modules way back then. But we are in the technology field for heaven’s sake. For us in the driver world it is like Microsoft telling us to manufacture cars on a 1980’s assembly line and expecting output to be on par with a 21st century gigafactory. Some of us understand what the competition has and can’t help but notice we are at a great disadvantage, but we will do our best with what we have to work with.