> As it is I think they actually are
responding, but not to external pressure, but rather to their own internal
awareness that there is a problem out here in driver developer land that
no
amount of whql will help.
True. I hope the end result is positive and not “miniports for all and to
all many sleepless nights trying to figure out how to get around the hand
tying driver model that wasn’t well thought out”. But, things do seem
pretty positive overall so far from what I see.
They didn’t do that with architectural magic bullets, they
did it with disciplined software development processes and a refusal to
ship
crap.
Amen to that. The peter principle seems to have run amok in the high tech
industries. Yours is the only company I have ever heard of that gave a rat
about process, aside from BlueWater Systems of course 
Its a management
stupidity problem that I really thought the dot gone phenomenon would have
helped curb.
Anyway, geez I have generated enough bits flying on the wires for this
thread.
–
Bill McKenzie
“Mark Roddy” wrote in message news:xxxxx@ntdev…
>
> I actually agree with everything you say, except that it is also a
> management problem. If every third party hardware vendor out there was
> screaming at Microsoft on a regular basis, and had been doing so for the
> last six or seven years, about the sorry state of driver development, and
> why it is at least partially Microsoft’s fault, then perhaps the great
> behemoth would have responded earlier. As it is I think they actually are
> responding, but not to external pressure, but rather to their own internal
> awareness that there is a problem out here in driver developer land that
no
> amount of whql will help.
>
> As long as the standard business model for driver development is ‘don’t
> worry, be crappy, but be first’, not much is going to change.
>
> Maybe my perspective is screwed by the last few years of working with a
> company that for 20 years has regularly delivered systems with 5-9s
> reliability, and is doing so, after nearly heroic effort, on x86 platforms
> and w2k software. They didn’t do that with architectural magic bullets,
they
> did it with disciplined software development processes and a refusal to
ship
> crap.
>
> –
> ===
> Mark Roddy
> Consultant, Microsoft DDK MVP
> Hollis Technology Solutions
> xxxxx@hollistech.com
> www.hollistech.com
> 603-321-1032
> For Windows Driver training see www.azius.com
> ===
>
>
> “Bill McKenzie” wrote in message
news:xxxxx@ntdev…
> >
> > >‘We’ are writing crappy drivers for at
> > >least two reasons: some of ‘we’ are incompetent and don’t understand
how
> to
> > >do this right, and a lot of our employers don’t give a rat’s ass about
> > >reliability.
> >
> > > I didn’t say why many driver writers were incompetent, I simply
> observed
> > > that they are, and that little is being done at the management level
to
> > > change that.
> >
> > Ah, I mistook competance in general to competance in driver writing
> > specifically in your argument. I guess my point is, many of the folks
out
> > there are completely competant coders, but they are working with an API
> that
> > is ill documented, ill demonstrated, and takes years to get right even
if
> > you have source access, (which I don’t BTW). This is not a problem you
> can
> > fix at the management level in most companies that need a driver written
> for
> > some application. You can send said competant coders to classes from
now
> > till the cows come home, (yeah I am from Texas), and it isn’t going to
> solve
> > the problem IMHO.
> >
> > I am absolutely amazed at how much the driver community at large still
> > doesn’t ‘know’. For instance I think Tim Johns brought up the fact that
> no
> > where is it documented that you can safely call IoCallDriver in your
> driver
> > at DISPATCH_LEVEL for USB, 1394, SERIAL, et al busses. So, there is no
> way
> > to know this for certain without source access. This is forced
> incompetance
> > I guess. My assertion has always been and still is that the problem is
> > information availability. The driver model is too robust, and the
source
> is
> > closed which is fine, and I don’t have a problem with, provided you
> document
> > every piece of every API thoroughly, and provide really good samples.
> > Otherwise yeah, people are going to write crappy drivers no matter how
> > talented they may be and no matter what restrictions you put in place.
I
> > don’t see what any manager could do to fix this problem.
> >
> >
> > All that said, I am definitely not saying that there are enough
companies
> > willing to spend the time and money to get their engineers trained.
This
> > lack is hurting everyone and I agree with that. I just don’t see it as
a
> > primary reason that there are crappy drivers out there.
> >
> > –
> > Bill McKenzie
> >
> >
> >
> > “Roddy, Mark” wrote in message
> news:xxxxx@ntdev…
> > >
> > > I didn’t say why many driver writers were incompetent, I simply
> observed
> > > that they are, and that little is being done at the management level
to
> > > change that.
> > >
> > >
> > >
> > > > -----Original Message-----
> > > > From: Bill McKenzie [mailto:xxxxx@bsquare.com]
> > > > Sent: Monday, April 29, 2002 4:44 PM
> > > > To: NT Developers Interest List
> > > > Subject: [ntdev] Re: Philosophical Rant [was Re: Writing
> > > > Drivers in Ja va]
> > > >
> > > >
> > > > Mark,
> > > >
> > > > I think you have wholly missed the mark on why most drivers
> > > > are crappy. The BIG reason is the API is way too robust,
> > > > (read its way to easy to hang oneself). Add to this a SEVERE
> > > > lack of documentation and samples and of course you are going
> > > > to end up with a mess. I am surprised that all works as well
> > > > as it does on the Windows platforms.
> > > >
> > >
> > >
> >
> >
> >
> >
>
>
>
>