Another major benefit is that the courses they teach are applicable to both
the green novice and someone who has some experience. You get to keep the
handouts (the diagrams are very useful). If you are not a novice but are
puzzled by some question in your current project/pursuit the instructors are
very approachable during breaks and lunch. Peter was always been willing
to answer my questions even if it was just ideas of new approaches to my
problem.
The fact that the OP has several experienced coworkers available but he is
asking us to teach him is an interesting data point. He is correct in that
it requires different skills and personalities to be able to teach. I was
in one class while working at Iomega from a company other than OSR and I
just remember something about application code being where that course was
most applicable. However, I remember a lot about the OSR courses even
though they all happened more than 9 years ago. I still have the class
handouts from those courses.
Having learned the ‘old’ NT 4 world of drivers, I find that knowledge very
useful even in today’s Windows 7 driver world. Even in the restrictive
world of miniports (almost any kind, AFAIK) that knowledge is still useful
because either the miniport or the port driver has to use the same base OS
in however it decides to build or work within the sandbox. NDIS is very
restrictive in that most native calls are prohibited unless they have been
wrapped either via defines or a function call substitute. If you trace into
the port driver most of the time you find just normal OS calls being used on
your behalf. It does have advantages in that all the PnP and Power
decisions are done by Microsoft code and the miniport is called at some
function with a ‘do this because I said so’ theme. In most port drivers
they ensure no requests are in progress when they make those calls which
simplifies development of the miniport. The disadvantage is when you need
to get out of the box.
wrote in message news:xxxxx@ntdev…
>
>
> I think that is EXCEPTIONALLY BAD advice. Epic bad. And obviously from
> somebody who has no clue what we teach in our seminars.
>
> What’s ALL IMPORTANT is understanding the architecture… what the role of
> your driver is in the overall system, how it gets requests and how it
> services them. Everything else is trivia. You can look up the names of
> the functions, get sample INF files… but if you don’t know that you
> can’t touch pageable memory at IRQL DISPATCH_LEVEL, you’re screwed plain
> and simple. If you don’t understand the concept of execution context
> (specific and arbitrary) you are totally fucked.
>
> The fact that you call IoCompleteRequest or WdfRequestComplete or
> NdisMXxxxx doesn’t matter. What matters is that you understand the
> environment in which your solution is operating, and the constraints
> within which that solution must be crafted.
>
> Peter
> OSR
>
>