Your description describes my point exactly. A short-cut in the driver
causes unnecessary support calls. I’m not comparing your expertise against
the people who wrote the OS. I am saying they are in a superior position to
understand the interactions between the various drivers. This is simply
because you couldn’t possibly have as much contact with all the other
devices as they do. They don’t arbitrarily make edicts and restrictions
just for the hell of it. It’s also not a matter of them not being bright
enough to figure out how to give you free reign. There is a reason for the
restriction or it wouldn’t be there. It’s usually there to prevent your
device from negatively impacting the overall system. Your device is not the
entire computer and it must play well with all the other devices in the
system. Otherwise the entire system, including your device is useless.
It’s a bit presumptuous of you to assume that your device is absolutely the
most important thing in the world and ignore all rules of system etiquette.
Again, I point to the Matrox lockup problem.
Now, try working in my field of real-time and process control for a while.
The system cannot go down, period. It also cannot be randomly hit with
unknown latencies. It has to be there and running correctly. NT/W2K is
laughed at by control engineers for this very reason. I would love to still
be using VMS because it didn’t go down, unless it had a 3rd party device
with a buggy driver. That’s just not an option in today’s climate.
Also, if you get to 99% complete 5 times faster and always crash at 99%
complete, you’ve gained nothing over the slower solution that always
completes. All I’m saying is play well and don’t crash the system or you
should face stiff consequences. This is the way all of engineering works.
Greg
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com