Re: Frameworks [WAS: Cost of developing a device driver]
- From: "Gary G. Little" <glittle@xxxxxxxxx>
- Date: Sun, 23 Oct 2005 22:29:29 GMT
>From my experience with DriverWorks, I would not go beyond WDF for kernel
mode development. There was to many "gotcha's" with DW that required digging
deep into the DDK to resolve. Without the 10 years or raw experience I had
in the kernel, there were issues with the DW drivers I developed that I
don't think I could have resolved, power management being the biggest
problem. And truth being told ... nearly every 3rd party framework or
toolkit out there will lag behind the latest release of the OS. It took many
months for DW to support the new features of SP2 such as cancel safe queues.
--
Gary G. Little
"Don Burn" <burn@xxxxxxxxxxxxxxxx> wrote in message
news:O2KHTP%231FHA.460@xxxxxxxxxxxxxxxxxxxxxxx
> From: "Bill McKenzie" <bm01_REMOVE_@xxxxxxx>
>> Once again, I said software development, not kernel software development.
>> Just because Windows kernel development is stuck in the stone age doesn't
>> mean the rest of the software world has stood still. Virtually all
>> software
>> developers use toolkits, frameworks, etc. Just not this special little
>> group. We are smarter than that, progress be damned.
>
> Bill,
>
> In the general case of software development I totally agree. I would
> actually love to see a good framework for Windows kernel development (I
> never used Bluewater so I plead ignorance if this did meet the needs).
> So far I have not seen a toolkit that gave me a payback worth the costs in
> reliability, debugging and dealing with Microsoft. I am hopeful that the
> WDK will meet these needs, but I will take the wait and see attitude.
>
> As to your general complaint about why aren't we using frameworks. I
> believe a lot of it is the more mission critical a product is, the more
> conservative the management and to some degree the developers. Having
> worked with fault tolerance and interacted a bunch with medical products
> people, I will tell you the windows kernel folks are a bunch of radicals
> in comparison.
>
> But most OS work is done conservatively. I've been around long enough
> that I was part of the high-level language versus assembler wars. By the
> mid to late 70's, no one would write an application in assembler if they
> could help it, but the OS guys were still arguing whether or not to use a
> high-level language for many things.
>
> One other problem is you are starting with an existing base. Most
> developers take existing code for a driver and turn it into a new driver.
> If they already are comfortable with the old driver why are they going to
> jump to a new model? I know many folks don't use WPP tracing, because
> they already have a model with DbgPrint statements, I will be curious to
> see if Vista turning off DbgPrint by default pushes people to WPP.
>
> The other thing with frameworks (or higher level abstractions in
> general), is that we are not developing new OS'es so they have to
> interface to old stuff. This is where many things break down or at least
> are not a clean design, which hurts the overall acceptance of a framework.
> This was an argument in the assembler versus high-level language (HLL)
> wars, the HLL code didn't interface well to the defined call interfaces
> that used registers! The HLL wars were really won by new OS'es that
> started out with HLL code. I don't see anyone writing a new OS with
> higher level abstractions.
>
> I'm not against toolkits, but they have an uphill climb to
> acceptance.
>
>
>
> --
> Don Burn (MVP, Windows DDK)
> Windows 2k/XP/2k3 Filesystem and Driver Consulting
> Remove StopSpam from the email to reply
>
>
>
.
- References:
- Frameworks [WAS: Cost of developing a device driver]
- From: Don Burn
- Frameworks [WAS: Cost of developing a device driver]
- Prev by Date: Re: Cost of developing a device driver?
- Next by Date: Re: SAN sample code
- Previous by thread: Frameworks [WAS: Cost of developing a device driver]
- Next by thread: Re: Frameworks [WAS: Cost of developing a device driver]
- Index(es):
Relevant Pages
|
