> well-documented code can also be written in any language. Given that
management is willing to spend the bucks to do so.
The management-who-are-not-developers-themselves often believe in Magic Cookies which will simplify the task (and reduce the
timeframe) 10 times.
The marketoids of toolkit producers know this well and beat exactly there.
The reality is not such. No such Magic Cookies. No toolkit will isolate the driver developer from the kernel. Also a toolkit can
increase problems - I saw a guy asking questions on some code written using the toolkit which uses KDevice and KIrp classes (what is
it)?
It was impossible to answer them without proper knowledge of the whole toolkit and KIrp methods. If this would be a raw C code
talking to kernel only - the question would be not so complex. In this OO code, the IRP handling was scattered over 15 or so
functions instead of 1 large function for each path.
Toolkits becomes a mean of confinement immediately when you want to do something really non-trivial. In this case, they increment
the number of problem instead of solving them.
One of my current tasks is supporting an FSD written by some other guys. It is 2MB of source. I manage to do this without major
problems - including rewriting huge pieces of it.
Surely this is plain C. If this would be C++ with deep inheritance chains - then my task would be terrifying and next to impossible
(or possible by complete rewrite if the author have designed the inheritance chain badly).
Large inheritance trees make it harder to fix bugs. Fixing a bug in base class to satisfy descendant B will break descendant C, and
so on.
BTW (to Bill M.) - PnP and Power paths in a usual driver are GREAT candidates for copy-paste 
Max
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