>need to learn driver development and I am surrounded by quite a few experienced guys (mostly 5+
yrs) in driver development.
Problem is that they don’t have time to babysit me
Ask them to explain the most major concepts to you. Then read the WDK samples.
A good book - like Walter Oney - is also good.
This is the simplest way if you cannot afford the courses.
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com
“piyush jain” wrote in message news:xxxxx@ntdev…
> I never at any point of time said that I will going a new project or i
> need
> to write a driver from scratch. I need to learn driver development and I
> am
> surrounded by quite a few experienced guys (mostly 5+ yrs) in driver
> development.
> Problem is that they don’t have time to babysit me (and their approach is
> not easy to understand–knowing and ‘to be able to teach’ are 2 different
> things) but they are happy to help me with doubts.
Then I have to aplogize, my advices were totally wrong for this case.
> Now, my request was simple. i need to learn and how do i go about it. if u
> see a person in my situation, how will u guide him? that all i asked, I
> think only few like Peter provided help and how to go about it; and to
> me, others are making unnecessary discussion !
Depends very much on your company and time frames.
Basically, you can apporoach your manager or these experienced guys,
and tell them: See, I know you can’t babysit me, but you also want the
project be ready in time and with good quality. What we can do about this?
Answer you want to hear would be like this:
a. Someone will help you to set up environment (WDK, debugger, vmware…),
show you where are samples and documentation, and show how
to build, run and debug a WDK ndis sample.
b. Based on WDK samples or whatever else available, you will try to
come with a prototype of needed driver. Time: (say) a week.
c. Then someone will code-review your stuff and give directions
for the next iteration.
Repeat steps b,c until done.
The key points are: make progress by small steps. Test.
Get feedback often (for this, bring good news often 
Never stay alone and frustrated.
> Please do not take any offense. I just wanted to be clear and wanted to
> make
> this tread useful even for others, who see it later.
Understood. But please note that most people here won’t be excited to
“babysit” beginners as well.
Beginners are expected to do their homework, google for answers for basic
questions ad so on.
Good luck.
– pa
> On Fri, Jul 9, 2010 at 10:45 PM, Calvin Guan
> wrote:
>
>> I believe OSR is good although I never have the luxury to get there.
>>
>> I agree with Pavel’s point. If I were the manager to start a new project
>> that is critical, I would hire experienced who has been there and done
>> that.
>> Initial quality and time to market are vital for a project to survive
>> IMO.
>> Instead of sending a fresh man to OSR, it makes more sense to hire osr
>> (or
>> whoever that is capable) to do the initial work.
>>
>> For sustaining effort, it’s ok for less experienced given that the
>> original
>> work does not require major overhaul or rewrite.
>>
>> Calvin
>>
>>
>>
>>
>> -----Original Message-----
>> From: xxxxx@lists.osr.com
>> [mailto:xxxxx@lists.osr.com] On Behalf Of Don Burn
>> Sent: Friday, July 09, 2010 8:22 AM
>> To: Windows System Software Devs Interest List
>> Subject: Re:[ntdev] need advice learning driver development
>>
>> > From: Pavel A. [mailto:xxxxx@fastmail.fm]
>>
>>
>> > With all due respect to OSR courses and others, they teach generic
>> knowledge,
>> > a lot more than one needs for a specific project, that requires time
>> and
>> > effort to understand.
>>
>> Have you actually taken an OSR class? Yes the knowledge is generic, but
>> most of it is applicable to many classes of drivers. The thing about
>> OSR and the other good instructors is not that they teach you the
>> subject matter, but they guide you into how to find the data you need.
>>
>>
>> Don Burn (MVP, Windows DKD)
>> Windows Filesystem and Driver Consulting
>> Website: http://www.windrvr.com
>> Blog: http://msmvps.com/blogs/WinDrvr
>>
I’ve never wrote that fundamental education is a bad thing or
that OSR classes are anything less than excellent.
My reply was given only to the OP in his specific situation and in no means
should be understood as general advice against any cources.
I beg for just a little common sense before jumping on me.
The OP asked a question on this list, so he already does
know about OSR classes. He already got advices to
take a class. So what is the chance he takes the class right now?
My bet is 0%.
Why?
Among other reasons - because the nearest WDM seminar starts only on 16 Aug.
and NDIS is not in the outline.
The guy can’t sit and do nothing for 1.5 months.
Sincere regards to the OSR team.
–pa
“M. M. O’Brien” wrote in message
news:xxxxx@ntdev…
> +1
>
> Also (pardon my amending THE OSR MASTER), it’s about knowing where to
> start,
> both in terms of the actual coding, but also and equally importantly, the
> docs and tools. Knowing that takes a HUGE bite out of the learning curve,
> especially for something like, say, WinDbg. Not exactly hard to spend one
> week in the windbg docs and get, you know, nowhere, whereas MVP Snoone
> will
> set you straight, at least as far as getting going.
>
>
>
> mm
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@osr.com
> Sent: Saturday, July 10, 2010 12:21 PM
> To: Windows System Software Devs Interest List
> Subject: RE:[ntdev] Re: need advice learning driver development
>
>
>
> 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
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
>
I just came across a youtube video series on windbg by Mark Russinovich.
http://www.youtube.com/watch?v=JSeNWvjhBfg&feature=related
Enjoy!
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of M. M. O’Brien
Sent: Saturday, July 10, 2010 9:58 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Re: need advice learning driver development
+1
Also (pardon my amending THE OSR MASTER), it’s about knowing where to start,
both in terms of the actual coding, but also and equally importantly, the
docs and tools. Knowing that takes a HUGE bite out of the learning curve,
especially for something like, say, WinDbg. Not exactly hard to spend one
week in the windbg docs and get, you know, nowhere, whereas MVP Snoone will
set you straight, at least as far as getting going.
mm
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@osr.com
Sent: Saturday, July 10, 2010 12:21 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Re: need advice learning driver development
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
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
>…NDIS is not in the outline. The guy can’t sit and do nothing for 1.5 months.
IIRC, NDIS is one of the most undocumented parts of Windows kernel. I would say the only possible way to learn it on your own is to go through ALL samples regardless of a project type (because you have a slim chance to understand what miniport does and why it does things this way if you don’t understand how protocol drivers work), read ndis.h ( this is particularly helpful if you are dealing with NDIS_version<6), read whatever documentation is available and disasm, disasm, disasm. In other words, the whole thing involves quite a lot of work and requires a certain degree of determination.
However, someone who already how NDIS works and knows what makes it tick can explain it to you, effectively saving you A LOT of efforts…
Anton Bassov
So to OP … I’m sure you might have asked the following questions already …
Do you have any time frame before you have to come up to speed?
Do you have any experience in kernel mode development? If so what OS environment? Any how can you bring some of the experience? And how can you unlearn some of the things that does not apply to windows OS?
Do you have basic background in OS and kernel ?
Do you have access to any reputable training? Sure OSR should be the first choice?
Do you have access to some of the books about windows driver writing and internals?
Is there any specific area you are tasked with ( say, NIC, storage, file system etc)?
And lot of indeterminate questions, that best be answered if you ask your self those questions and find answers for…
There is no cook book approach to learn and be productive in any field, and more so in driver writing. But I guess, if you just try to answer some of the above mentioned questions, you will be able to encompass what you need to know, when , and what speed… The approach is called “constrained optimization” :-).
-pro
On Jul 10, 2010, at 1:49 PM, Pavel A. wrote:
“piyush jain” wrote in message news:xxxxx@ntdev…
>> I never at any point of time said that I will going a new project or i need
>> to write a driver from scratch. I need to learn driver development and I am
>> surrounded by quite a few experienced guys (mostly 5+ yrs) in driver
>> development.
>> Problem is that they don’t have time to babysit me (and their approach is
>> not easy to understand–knowing and ‘to be able to teach’ are 2 different
>> things) but they are happy to help me with doubts.
>
> Then I have to aplogize, my advices were totally wrong for this case.
>
>> Now, my request was simple. i need to learn and how do i go about it. if u
>> see a person in my situation, how will u guide him? that all i asked, I
>> think only few like Peter provided help and how to go about it; and to
>> me, others are making unnecessary discussion !
>
> Depends very much on your company and time frames.
> Basically, you can apporoach your manager or these experienced guys,
> and tell them: See, I know you can’t babysit me, but you also want the
> project be ready in time and with good quality. What we can do about this?
>
> Answer you want to hear would be like this:
>
> a. Someone will help you to set up environment (WDK, debugger, vmware…),
> show you where are samples and documentation, and show how
> to build, run and debug a WDK ndis sample.
>
> b. Based on WDK samples or whatever else available, you will try to
> come with a prototype of needed driver. Time: (say) a week.
>
> c. Then someone will code-review your stuff and give directions
> for the next iteration.
>
> Repeat steps b,c until done.
>
> The key points are: make progress by small steps. Test.
> Get feedback often (for this, bring good news often
> Never stay alone and frustrated.
>
>> Please do not take any offense. I just wanted to be clear and wanted to make
>> this tread useful even for others, who see it later.
>
> Understood. But please note that most people here won’t be excited to “babysit” beginners as well.
> Beginners are expected to do their homework, google for answers for basic questions ad so on.
>
> Good luck.
> – pa
>
>> On Fri, Jul 9, 2010 at 10:45 PM, Calvin Guan wrote:
>>
>>> I believe OSR is good although I never have the luxury to get there.
>>>
>>> I agree with Pavel’s point. If I were the manager to start a new project
>>> that is critical, I would hire experienced who has been there and done
>>> that.
>>> Initial quality and time to market are vital for a project to survive IMO.
>>> Instead of sending a fresh man to OSR, it makes more sense to hire osr (or
>>> whoever that is capable) to do the initial work.
>>>
>>> For sustaining effort, it’s ok for less experienced given that the original
>>> work does not require major overhaul or rewrite.
>>>
>>> Calvin
>>>
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: xxxxx@lists.osr.com
>>> [mailto:xxxxx@lists.osr.com] On Behalf Of Don Burn
>>> Sent: Friday, July 09, 2010 8:22 AM
>>> To: Windows System Software Devs Interest List
>>> Subject: Re:[ntdev] need advice learning driver development
>>>
>>> > From: Pavel A. [mailto:xxxxx@fastmail.fm]
>>>
>>>
>>> > With all due respect to OSR courses and others, they teach generic
>>> knowledge,
>>> > a lot more than one needs for a specific project, that requires time
>>> and
>>> > effort to understand.
>>>
>>> Have you actually taken an OSR class? Yes the knowledge is generic, but
>>> most of it is applicable to many classes of drivers. The thing about
>>> OSR and the other good instructors is not that they teach you the
>>> subject matter, but they guide you into how to find the data you need.
>>>
>>>
>>> Don Burn (MVP, Windows DKD)
>>> Windows Filesystem and Driver Consulting
>>> Website: http://www.windrvr.com
>>> Blog: http://msmvps.com/blogs/WinDrvr
>>>
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit: http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
NDIS is not documented, but in the past if you were willing to go the
NDIS/WDM route you could develop an NDIS miniport with almost no NDIS in
it. I suspect the same is true today with NDIS/KMDF. Of course this
only works for miniports not for all the other aspects of NDIS.
Don Burn (MVP, Windows DKD)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
-----Original Message-----
From: xxxxx@hotmail.com [mailto:xxxxx@hotmail.com]
Posted At: Saturday, July 10, 2010 8:00 PM
Posted To: ntdev
Conversation: Re: need advice learning driver development
Subject: RE: Re: need advice learning driver development>…NDIS is not in the outline. The guy can’t sit and do nothing for
1.5
months.IIRC, NDIS is one of the most undocumented parts of Windows kernel. I
would
say the only possible way to learn it on your own is to go through ALL
samples
regardless of a project type (because you have a slim chance to
understand
what miniport does and why it does things this way if you don’t
understand how
protocol drivers work), read ndis.h ( this is particularly helpful if
you are
dealing with NDIS_version<6), read whatever documentation is available
and
disasm, disasm, disasm. In other words, the whole thing involves quite
a lot
of work and requires a certain degree of determination.However, someone who already how NDIS works and knows what makes it
tick can
explain it to you, effectively saving you A LOT of efforts…Anton Bassov
__________ Information from ESET Smart Security, version of virus
signature
database 5268 (20100710) __________The message was checked by ESET Smart Security.
> NDIS is not documented, but in the past if you were willing to go the NDIS/WDM route you could
develop an NDIS miniport with almost no NDIS in it. I suspect the same is true today with NDIS/KMDF.
???
If you don’t use NDIS in your NIC driver how are you going to expose it to the protocol stack then???
The only thing you can do here is to implement a layered miniport, i.e. write WDM or KMDF driver that actually deals with the hardware details of your NIC, plus a virtual NDIS miniport driver that deals with above mentioned WDM or KMDF driver on its lower edge and with NDIS library on its upper one,effectively interfacing your NIC to NDIS.
Although there may be some reasons why you may want to go this way (for example, you may want to be able to queue separate DPCs for TxComplete and Rx events, i.e. something you are unable to do within NDIS framework), avoiding dealing with NDIS is DEFINITELY not among them…
Anton Bassov
What he meant was using NDIS for hw access (ie PCI). If you are not a PCI based NIC, you are a defector NDIS-WDM, now NDIS-KMDF, NIC
d
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@hotmail.com
Sent: Saturday, July 10, 2010 6:30 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Re: need advice learning driver development
NDIS is not documented, but in the past if you were willing to go the
NDIS/WDM route you could develop an NDIS miniport with almost no NDIS in it. I suspect the same is true today with NDIS/KMDF.
???
If you don’t use NDIS in your NIC driver how are you going to expose it to the protocol stack then???
The only thing you can do here is to implement a layered miniport, i.e. write WDM or KMDF driver that actually deals with the hardware details of your NIC, plus a virtual NDIS miniport driver that deals with above mentioned WDM or KMDF driver on its lower edge and with NDIS library on its upper one,effectively interfacing your NIC to NDIS.
Although there may be some reasons why you may want to go this way (for example, you may want to be able to queue separate DPCs for TxComplete and Rx events, i.e. something you are unable to do within NDIS framework), avoiding dealing with NDIS is DEFINITELY not among them…
Anton Bassov
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
We already established that taking a seminar is out for the OP. I didn’t suggest he take one, in fact.
No, no, a thousand times NO… This is PRECISELY what I’ve been saying is the wrong approach. This is exactly how to become a driver writer who should never be allowed to write a production driver for Windows.
One can certainly learn how to write C# .Net GUI apps by starting to hack on an example before you know what you’re doing, but you will take you AGES to learn how to write proper Windows drivers this way…
There are simply too many little details, “gottchas”, and issues for a new driver writer. Unless you know your OS fundamentals, you won’t even know what done LOOKS like. You run your driver… it works in your lab. Is it DONE? Just because it doesn’t blue screen does not mean it’s correct.
Or, let’s try: You send multiple asynchronous requests from your driver to driver X. MUST driver X complete those requests in order? Maybe in your experience driver X DOES complete them in order… but is what you’re observing the result of an architectural precept, a detail of implementation, or pure coincidence?
People who learn how to write Windows drivers by trial-and-error, without understanding architectural fundamentals, only have a partial picture… they don’t know what they don’t know.
To learn this, it doesn’t matter if you take a seminar, read some books, read The NT Insider, or read a bunch of papers on WHDC.
To quote my first post on this topic: http://www.osronline.com/ShowThread.cfm?link=185282#T11 – What you need to really understand are:
Thread and processes, key
data structures, how you get into and out of kernel mode, how requests are I/O
processed, IRQLs, I/O completion, synchronization. Of these you really need
to understand and internalize the flow of an I/O request from initiation at the
user application to completion. AND you need to understand IRQLs.
Only AFTER you know these things should you embark on steps (a), (b), and (c) – iterating through b and c, above.
So, OP… start reading. When you think you get it, start working your way through an example or two. But… NO HACKING ON SAMPLES until you understand the basics. Just like no driving your car until you know the traffic laws.
Peter
OSR
Once you overcome the learning curve, you will be going downhill. The curve
in my definition is how to build a driver, setup a debugger and load the
driver with debugger attached.
Writing driver (apart from dealing with the device technologies specific to
your hardware), is no more than RTFM and DISASM. The first part tells you
what have been said that one must know and remember. The latter tells you
what have not been said but you will need at some point of time.
Having reasonable understand of how the OS works will help you make sense of
what the documents say hence you could remember it and turn it into your
mother nature. Once you have the basic, you can learn anything in Windows
on your own.
Calvin
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of piyush jain
Sent: Friday, July 09, 2010 11:48 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] need advice learning driver development
I never at any point of time said that I will going a new project or i need
to write a driver from scratch. I need to learn driver development and I am
surrounded by quite a few experienced guys (mostly 5+ yrs) in driver
development.
Problem is that they don’t have time to babysit me (and their approach is
not easy to understand–knowing and ‘to be able to teach’ are 2 different
things) but they are happy to help me with doubts.
Now, my request was simple. i need to learn and how do i go about it. if u
see a person in my situation, how will u guide him? that all i asked, I
think only few like Peter provided help and how to go about it; and to me,
others are making unnecessary discussion !
Please do not take any offense. I just wanted to be clear and wanted to make
this tread useful even for others, who see it later.
On Fri, Jul 9, 2010 at 10:45 PM, Calvin Guan
wrote:
I believe OSR is good although I never have the luxury to get there.
I agree with Pavel’s point. If I were the manager to start a new project
that is critical, I would hire experienced who has been there and done that.
Initial quality and time to market are vital for a project to survive IMO.
Instead of sending a fresh man to OSR, it makes more sense to hire osr (or
whoever that is capable) to do the initial work.
For sustaining effort, it’s ok for less experienced given that the original
work does not require major overhaul or rewrite.
Calvin
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Don Burn
Sent: Friday, July 09, 2010 8:22 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] need advice learning driver development
> From: Pavel A. [mailto:xxxxx@fastmail.fm]
> With all due respect to OSR courses and others, they teach generic
knowledge,
> a lot more than one needs for a specific project, that requires time
and
> effort to understand.
Have you actually taken an OSR class? Yes the knowledge is generic, but
most of it is applicable to many classes of drivers. The thing about
OSR and the other good instructors is not that they teach you the
subject matter, but they guide you into how to find the data you need.
Don Burn (MVP, Windows DKD)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
—
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
—
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
— NTDEV is sponsored by OSR For our schedule of WDF, WDM, debugging and
other seminars visit: http://www.osr.com/seminars To unsubscribe, visit the
List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
>
Once you overcome the learning curve, you will be going downhill. The
curve in
my definition is how to build a driver, setup a debugger and load the
driver
with debugger attached.
That can be a bit of work to set up, but it’s all documented and is just
a matter of following the ‘bouncing ball’. It’s more process than
knowledge.
Writing driver (apart from dealing with the device technologies
specific to
your hardware), is no more than RTFM and DISASM. The first part tells
you what
have been said that one must know and remember. The latter tells you
what have
not been said but you will need at some point of time.Having reasonable understand of how the OS works will help you make
sense of
what the documents say hence you could remember it and turn it into
your
mother nature. Once you have the basic, you can learn anything in
Windows on
your own.
I can’t say I agree with your dismissal of driver writing as “not more
than RTFM and DISASM”. There is a lot you need to understand before you
start developing. A lot of it you can learn by doing it wrong and then
figuring out why it blew up in your face, but you still need that
understanding to get anywhere or else you can make some fundamentally
wrong design decisions. KMDF does take a lot of that pain out of driver
development though.
James
>> There is a lot you need to understand before you start developing.
Well, I never dismiss the necessity of understand before starting doing
something.
> A lot of it you can learn by doing it wrong and then figuring
> out why it blew up in your face, but you still need that understanding
> to get anywhere or else you can make some fundamentally wrong design
decisions.
> KMDF does take a lot of that pain out of driver development though.
I’m not advocating trial and error neither. But you need to build something
to prove and challenge your understanding of newly acquired knowledge. Many
times, you found yourself didn’t actually understand until you tried to
build something and it failed miserably. One may talk like a Phd when comes
to control theory on paper but he may end up getting an oscillator only when
he tried to build an amplifier and have no clue how to stabilized it in the
lab. I saw people like that.
To me, I found it’s more effective learning by read-exercise-read again. I
just can’t sit there reading all day long keeping my hands idle. YMMV.
Calvin
> Unless you know your OS fundamentals, you won’t even know what done LOOKS like. You run your driver… it works in your lab. Is it DONE? Just because it doesn’t blue screen does not mean it’s correct.
Or, let’s try: You send multiple asynchronous requests from your driver to driver X. MUST driver X complete those requests in order? Maybe in your experience driver X DOES complete them in order… but is what you’re observing the result of an architectural precept, a detail of implementation, or pure coincidence?
People who learn how to write Windows drivers by trial-and-error, without understanding architectural fundamentals, only have a partial picture… they don’t know what they don’t know.
They don’t know what they don’t know — This is the most scary part. It scares the hell out of my a??.
-pro
On Sat, 10 Jul 2010 22:22:30 -0400 (EDT)
xxxxx@osr.com wrote:
No, no, a thousand times NO… This is PRECISELY what I’ve been
saying is the wrong approach. This is exactly how to become a driver
writer who should never be allowed to write a production driver for
Windows.One can certainly learn how to write C# .Net GUI apps by starting to
hack on an example before you know what you’re doing, but you will
take you AGES to learn how to write proper Windows drivers this way…
It’s the same problem with .NET applications too: I’ve seen far too
many people who think that C# and .NET are so simple they can dive
right in - and they end up with a barely-working mess. Having a solid
grounding in userland Windows and the tools is fairly important in my
opinion so you can understand things like thread priorities, COM
apartments, Winsock, and finally how to actually solve problems when
they occur.
–
Bruce Cran
This definitely is an interesting discussion as I am sort-off in the same situtation as the OP (OSR is too far away, but I don’t work for a company and don’t have anyone experienced around me who could help).
The way I started doing things was reading the really basic papers/documents, to be able to build a nothing driver and setting up windbg connected to a VM so I could debug it.
Then bit by bit I tried to extend this driver with the knowledge I had and by looking at the samples that did simmilar work. The obvious downside of this approach as mentioned before is that I did not know what I had to know (e.g. I knew there was something called an IRQL, but I ignored it). So what I learned from this approach is that it is extremely easy to shoot yourself in the foot… I needed more knowledge.
I then picked up the Windows Internals book and started reading… it clearly explains things like IRQL, and gives you an understanding as to why you can’t access paged memory at DIRQL instead of just telling you “you just can’t”. I also took a course on Operating Systems at my university, eventhough we didn’t use Windows it was still very helpful.
The next step is getting the ‘Developing with WDF’ book (I’ve ordered it weeks ago… but somehow there is a huge delay).
So in essence… any learning approach is somewhat personal, if you ask 10 students how they prepare for a test you might get 10 different answers. So in your case I would definitely try to ask your experienced colleagues to help you get on your way but after that don’t rely on them too much, do a lot of reading and make sure that you to some degree know what you are talking about. When people see that you put a lot of effort in yourself they tend to be a lot more helpful when you are stuck somewhere. That’s true on this list and probably with colleagues as well but I have no experience there ;).
>To me, I found it’s more effective learning by read-exercise-read again. I
just can’t sit there reading all day long keeping my hands idle. YMMV.
Couldn’t agree more. There’s something magical about the whole think-type
exchange.
mm
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Calvin Guan
Sent: Sunday, July 11, 2010 12:10 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] need advice learning driver development
> There is a lot you need to understand before you start developing.
Well, I never dismiss the necessity of understand before starting doing
something.
> A lot of it you can learn by doing it wrong and then figuring out why
> it blew up in your face, but you still need that understanding to get
> anywhere or else you can make some fundamentally wrong design
decisions.
> KMDF does take a lot of that pain out of driver development though.
I’m not advocating trial and error neither. But you need to build something
to prove and challenge your understanding of newly acquired knowledge. Many
times, you found yourself didn’t actually understand until you tried to
build something and it failed miserably. One may talk like a Phd when comes
to control theory on paper but he may end up getting an oscillator only when
he tried to build an amplifier and have no clue how to stabilized it in the
lab. I saw people like that.
To me, I found it’s more effective learning by read-exercise-read again. I
just can’t sit there reading all day long keeping my hands idle. YMMV.
Calvin
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
>It’s the same problem with .NET applications too: I’ve seen far too many
people who think that C# and .NET are so simple they can dive right in - and
they end up with a barely-working mess.
Welcome to user mode!
mm
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Bruce Cran
Sent: Sunday, July 11, 2010 4:51 AM
To: Windows System Software Devs Interest List
Cc: xxxxx@osr.com
Subject: Re: [ntdev] Re: need advice learning driver development
On Sat, 10 Jul 2010 22:22:30 -0400 (EDT) xxxxx@osr.com wrote:
No, no, a thousand times NO… This is PRECISELY what I’ve been saying
is the wrong approach. This is exactly how to become a driver writer
who should never be allowed to write a production driver for Windows.One can certainly learn how to write C# .Net GUI apps by starting to
hack on an example before you know what you’re doing, but you will
take you AGES to learn how to write proper Windows drivers this way…
It’s the same problem with .NET applications too: I’ve seen far too many
people who think that C# and .NET are so simple they can dive right in - and
they end up with a barely-working mess. Having a solid grounding in
userland Windows and the tools is fairly important in my opinion so you can
understand things like thread priorities, COM apartments, Winsock, and
finally how to actually solve problems when they occur.
–
Bruce Cran
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
> It’s the same problem with .NET applications too: I’ve seen far too
many people who think that C# and .NET are so simple they can dive
right in - and they end up with a barely-working mess.
I think .NET (and to some extend C#) are prone to this. It allows
people without a clue to screw up while promising productivity' and other marketing nonsense. I find it very difficult to write good applications in .NET. Yeah, it's easier to write visual bullshit/demo things, but it's in no way easier to write correct production level stuff then the old ways’. C + Win32 API require some technical
know-how that filter a lot of clueless people.
Having a solid
grounding in userland Windows and the tools is fairly important in my
opinion so you can understand things like thread priorities, COM
apartments, Winsock, and finally how to actually solve problems when
they occur.
Most managers would not agree. Solid understanding people are
expensive. .NET programmers are cheap. Hey! They can build stuff, who
cares it’s sucks? Most .NET stuff is line-of-bussiness type of
applications. Internal stuff that’s not for sale, so the organizations
can just cope with whatever mess they produce.
–
Aram Hăvărneanu
Well, now we wander off topic…
It is entirely possible that when it comes to writing .Net apps, I am in the category of not knowing what I don’t know. Because *I* learned what I know of .Net programming from simple slash and burn hacking of the worst sort… precisely the kind of hackery that I constantly warn people off in learning driver development.
But it certainly SEEMS to me that I can write a very capable application… take some data, invoke some SOAP service, store some results, make a pretty something-or-other on the screen, masturbate some cool visual controls, get data from my serial port… without knowing a heck of a lot. I mean, seriously. If it works, have I not done it correctly? Now, I might not have done it OPTIMALLY, but… is it like kernel-mode programming where if I get it to work in my office, that tells me effectively nothing about whether it’ll work in my test lab or on my customer’s machine??
Now, surely… if you try to write something that’s more involved… adding multithreading, for example… you wind-up having to understand serialization. And, sure, not understanding serialization is certainly the sort of thing that wouldn’t necessarily show up when I test in my office.
But is .Net not intrinsically more “conceptually scalable” than Windows kernel-mode driver development? In other words, can’t I know relatively little and yet write relatively simple applications with confidence? And, then, if I need to write more complex apps, I learn a little more… and for yet MORE complex apps, I need to learn more STILL?? Whereas, with Windows drivers you must START with a chunk of knowledge before you can write “hello world” or you risk crashing and burning.
BTW, KMDF reduces the initial learning burden VERY considerably. I mean, miraculously in many cases. However, it does not relieve you of having to have SOME basic architecture stuff.
Peter
OSR