If the OS gives an abstract enough interface, none of those
problems exist. If however the OS is an amoebalike thing that
wants to minimize what hardware drivers can do, this kind of
problem will pop up all over the place, and let me say it once,
serve them right. They’re shooting themselves on the foot, big
and hard. A solid OS doesn’t break because of a driver, and if a
driver breaks the system - because it mishandles the hardware -
that’s not the OS’s problem nor is that a problem that should
concern the OS. The OS doesn’t own the machine, nor does it
orchestrate anything, it’s just a service program that should do
what it’s told.
As for Norton, I managed SoftICE, BoundsChecker, TrueTime,
TrueCoverage, DriverWorks, DriverNetworks, DriverMonitor, and I
didn’t have any of those issues. The problem, mind you, is the
bizantyne architecture we driver writers have to go through to
get our products working, and let me tell you, the least I have
to negotiate it, the better off I feel.
Alberto.
----- Original Message -----
From: “Gary G. Little”
Newsgroups: ntdev
To: “Windows System Software Devs Interest List”
Sent: Tuesday, August 09, 2005 11:02 PM
Subject: Re:[ntdev] SPAM-LOW: Re: SPAM-LOW: Re: Re:Referencing a
RegKey Object from handle
> You forget one thing. That driver must exist in an environment
> that is not only orchestrated by an OS, but one that is also
> colored and harmonized with by a multitude of other kernel
> drivers provided by a multitude of deveopers and vendors. Most
> of those developers ASSUME that your driver is doing basically
> the same thing as they are, trying to perform the task at hand
> without casuing a ripple that will kill someone else. Your
> driver may work fine in SP2, using undocumented structures and
> function calls but will it in SP3 or Vista? The truth is you
> cannot guarante that you can correct any deltas that may exist
> in SPs before they casue some other vendors driver to crash.
> That is going to lead to uneeded stress and work by the poor
> schmuck trying to do things right. You cannot guarnatee that
> what you do when you decide to run naked through the hardware,
> is not going to cause someone else grief.
>
> Norton AV is proof enough. It has to be uninstalled to
> install to many of the Microsoft released updates, and an
> uninstalled AV is absolutely useless.
>
> –
> the personal opinion of
> Gary G. Little
>
> “Alberto Moreira” wrote in message
> news:xxxxx@ntdev…
>> No, dude, experience. Years of it. A device driver should be
>> machine code on iron - basically it should misbehave because
>> it doesn’t handle the hardware appropriately, or because
>> there’s a programming error, and so on. If a piece of code
>> must spend most of its time negotiating APIs which are
>> basically there to channel a dev out of handling the
>> hardware, sorry, no sympathy from me.
>>
>> Alberto.
>>
>>
>> ----- Original Message -----
>> From: “Arlie Davis”
>> To: “Windows System Software Devs Interest List”
>>
>> Sent: Tuesday, August 09, 2005 11:11 AM
>> Subject: RE: SPAM-LOW: Re: SPAM-LOW: Re: Re:[ntdev]
>> Referencing a RegKey Object from handle
>>
>>
>>> Alberto writes:
>>>
>>>> The more one uses OS services, the more exposure
>>>> one has to nonsense and to uncontrollable behavior.
>>>
>>> Extremist nonsense and fingerpointing. I can cite just as
>>> many examples of
>>> device drivers that do incredibly stupid things than you can
>>> of OS flaws.
>>> And what is the end result of this reasoning? No OS, no
>>> drivers, just apps
>>> talking directly to hardware? Back to the fifties? Perhaps
>>> you should ship
>>> a sealed box, that contains only 100% pure, flawless Moreira
>>> code.
>>>
>>> We must be conservative at all interfaces between
>>> components – between
>>> hardware and software components, and between software
>>> components – to the
>>> degree that is rational and necessary, because those
>>> components change
>>> independently over time. Using undocumented and unsupported
>>> interfaces is
>>> an option, but should only be a last resort, and every
>>> effort should be made
>>> to reduce its impact.
>>>
>>> I suppose you’re still grumpy that the x64 compiler doesn’t
>>> support inline
>>> assembly, too.
>>>
>>> – arlie
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: xxxxx@lists.osr.com
>>> [mailto:xxxxx@lists.osr.com] On Behalf Of
>>> Alberto Moreira
>>> Sent: Monday, August 08, 2005 10:03 PM
>>> To: Windows System Software Devs Interest List
>>> Subject: SPAM-LOW: Re: SPAM-LOW: Re: Re:[ntdev] Referencing
>>> a RegKey Object
>>> from handle
>>>
>>> When it ships, it must be just code running on the machine.
>>> The more one
>>> uses OS services, the more exposure one has to nonsense and
>>> to
>>> uncontrollable behavior. The solution, to me at least, is
>>> obvious: talk to the hardware first, to the OS only when
>>> there’s no
>>> alternative. Minimizing one’s exposure to the OS minimizes
>>> one’s exposure to
>>> events one cannot control.
>>>
>>> So, the only real conservative approach is to talk to the
>>> hardware. That’s
>>> frozen functionality, mind you, it has been around for years
>>> and by and
>>> large it works wonders. Beyond that, it’s basically a kind
>>> of a lottery.
>>>
>>> Alberto.
>>>
>>>
>>> ----- Original Message -----
>>> From: “Arlie Davis”
>>> To: “Windows System Software Devs Interest List”
>>>
>>> Sent: Monday, August 08, 2005 5:05 PM
>>> Subject: RE: SPAM-LOW: Re: Re:[ntdev] Referencing a RegKey
>>> Object from
>>> handle
>>>
>>>
>>>> This isn’t about learning, or debugging. There are
>>>> numerous books on
>>>> Windows internals, targeted at device driver developers and
>>>> developers
>>>> in general. I’m particularly fond of Rajeev Nagar’s File
>>>> System
>>>> Internals, Gary Nebbett’s Windows NT/2000 Native API
>>>> Reference. There
>>>> are also lots of good web resources for this.
>>>>
>>>> This whole argument is about what you ship in your device
>>>> drivers –
>>>> the code that customers place their trust in. All
>>>> experience shows
>>>> that being conservative, especially with kernel-mode
>>>> components, is
>>>> important.
>>>>
>>>> – arlie
>>>
>>>
>>>
>>>
>>> —
>>> Questions? First check the Kernel Driver FAQ at
>>> http://www.osronline.com/article.cfm?id=256
>>>
>>> You are currently subscribed to ntdev as: xxxxx@ieee.org
>>> To unsubscribe send a blank email to
>>> xxxxx@lists.osr.com
>>
>>
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@ieee.org
> To unsubscribe send a blank email to
> xxxxx@lists.osr.com
