Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results

Before Posting...
Please check out the Community Guidelines in the Announcements and Administration Category.

Re: need advice learning driver development

Don_Burn_1Don_Burn_1 Member Posts: 4,311
> 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
«1

Comments

  • Calvin_Guan-3Calvin_Guan-3 Member Posts: 441
    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
  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    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
    >
  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 7,284
    <QUOTE>
    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.
    </QUOTE>

    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

    Peter Viscarola
    OSR
    @OSRDrivers

  • mmmm Member - All Emails Posts: 1,410
    +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

    <QUOTE>
    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.
    </QUOTE>

    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
  • Don_Burn_1Don_Burn_1 Member Posts: 4,311
    The other thing about OSR and for that manner any of the other classes
    is even if you know the material they bring a different perspective to
    the problem. I twice in the past took OSR classes that covered a lot of
    information "I knew" and in each case I found through their approach
    that there were aspects that I had not thought of.


    Don Burn (MVP, Windows DKD)
    Windows Filesystem and Driver Consulting
    Website: http://www.windrvr.com
    Blog: http://msmvps.com/blogs/WinDrvr




    > -----Original Message-----
    > From: M. M. O'Brien [mailto:xxxxx@gmail.com]
    > Posted At: Saturday, July 10, 2010 12:58 PM
    > Posted To: ntdev
    > Conversation: Re: need advice learning driver development
    > Subject: RE: 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
    >
    > <QUOTE>
    > 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.
    > </QUOTE>
    >
    > 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
    >
    >
    >
    > __________ Information from ESET Smart Security, version of virus
    signature
    > database 5267 (20100710) __________
    >
    > The message was checked by ESET Smart Security.
    >
    > http://www.eset.com
    >
  • David_J._CraigDavid_J._Craig Member Posts: 1,885
    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.

    <xxxxx@osr.com> wrote in message news:xxxxx@ntdev...
    > <QUOTE>
    > 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.
    > </QUOTE>
    >
    > 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
    >
    >
  • Maxim_S._ShatskihMaxim_S._Shatskih Member Posts: 10,396
    >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
  • Pavel_APavel_A Member Posts: 2,674
    "piyush jain" <xxxxx@gmail.com> 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
    > <xxxxx@gradovec.com>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
    >>
  • Pavel_APavel_A Member Posts: 2,674
    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" <xxxxx@gmail.com> 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
    >
    > <QUOTE>
    > 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.
    > </QUOTE>
    >
    > 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
    >
    >
  • Calvin_Guan-3Calvin_Guan-3 Member Posts: 441
    I just came across a youtube video series on windbg by Mark Russinovich.


    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

    <QUOTE>
    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.
    </QUOTE>

    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
  • anton_bassovanton_bassov Member Posts: 5,013
    >.....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
  • Prokash_Sinha-1Prokash_Sinha-1 Member - All Emails Posts: 1,214
    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" <xxxxx@gmail.com> 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 <xxxxx@gradovec.com>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
  • Don_Burn_1Don_Burn_1 Member Posts: 4,311
    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.
    >
    > http://www.eset.com
    >
  • anton_bassovanton_bassov Member Posts: 5,013
    > 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
  • Doron_HolanDoron_Holan Member - All Emails Posts: 10,435
    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
    d
  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 7,284
    We already established that taking a seminar is out for the OP. I didn't suggest he take one, in fact.

    <QUOTE>
    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.
    </QUOTE>

    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:

    <Q>
    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.
    </Q>

    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

    Peter Viscarola
    OSR
    @OSRDrivers

  • Calvin_Guan-3Calvin_Guan-3 Member Posts: 441
    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
  • James_HarperJames_Harper Member Posts: 1,615
    >
    > 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
  • Calvin_Guan-3Calvin_Guan-3 Member Posts: 441
    >> 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
  • Prokash_Sinha-1Prokash_Sinha-1 Member - All Emails Posts: 1,214
    > 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
  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    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
  • Chris_SchadeChris_Schade Member Posts: 67
    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 ;).
  • mmmm Member - All Emails Posts: 1,410
    >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
  • mmmm Member - All Emails Posts: 1,410
    >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
  • Aram_Havarneanu-2Aram_Havarneanu-2 Member Posts: 161
    > 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
  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 7,284
    <QUOTE>
    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'.
    </QUOTE>

    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

    Peter Viscarola
    OSR
    @OSRDrivers

  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    On Sun, 11 Jul 2010 13:53:15 -0400 (EDT)
    xxxxx@osr.com wrote:

    > 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??

    One example is numeric input and output. Everyone I've seen
    programming .NET applications uses the default ToString() and Parse()
    methods to handle numbers. It'll all work fine in your office, but send
    it to someone in mainland Europe and it'll start crashing because there
    will be a mixture of decimal separators in use. Likewise, send a
    WinForms application that you've spent lots of time placing controls on
    to someone in China and it'll probably look very different, and
    probably not very good (I believe this should be fixed with WPF). I've
    seen both these issues in applications that had been deployed for over a
    year, and were only found when customers complained about crashes and
    other problems. I even saw one (internal) application that started
    crashing when I changed the Windows country setting from US to UK!

    Just like in the driver world, there are tools that can point out
    issues like converting numbers from strings to floats and vice versa
    and teach the user to avoid them in future - but, despite for example
    the Code Analysis option being on the right-click menu in Visual
    Studio, too few people seem aware of it and end up shipping
    applications that fail to work in a large number of countries.

    --
    Bruce Cran
  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 7,284
    @Bruce: Two VERY good and easy-to-understand example. Nicely explained, thanks.

    So, that DOES prove what I said earlier... when it comes to .Net programming, I really don't know what I don't know!

    Peter
    OSR

    Peter Viscarola
    OSR
    @OSRDrivers

  • anton_bassovanton_bassov Member Posts: 5,013
    > with Windows drivers you must START with a chunk of knowledge before you can write "hello world"
    > or you risk crashing and burning.

    It really depends on what you mean by the term "driver"......

    If we assume that "driver" means just a KM module without any implication of its actual functionality, then the above statement is certainly false - after all, all that SCM-based "hello world" driver needs is practically do-nothing DriverEntry() and Unload() routines. Therefore, you can still gain knowledge incrementally while learning driver development.


    In fact, Pavel's advice is not that bad if we make a small adjustment to it - instead of dumbly screwing up a workable sample the way Pavel suggests you should use it as a reference while writing your driver from the scratch and incrementally adding functionality to it....


    Anton Bassov
  • Don_Burn_1Don_Burn_1 Member Posts: 4,311
    Actually Bruce's examples show how even a generic course can help. I
    know very little about .NET but having dealt with user space code in
    Unix (and mini-computer OS'es) for many years before moving into Windows
    device drivers, I have as one of my rules "Never trust an application
    that can running in an international environment, until you have tested
    it in all languages that will use it". As I said in a previous post
    over the years I took a number of OSR classes, and it is not the nuts
    and bolts that were the great value, it was the insight and rules of
    thumb that Peter, Tony and Mark conveyed that are the real value.


    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@osr.com [mailto:xxxxx@osr.com] Posted At: Sunday, July

    > 11, 2010 2:48 PM Posted To: ntdev
    > Conversation: Re: need advice learning driver development
    > Subject: RE: Re: need advice learning driver development
    >
    > @Bruce: Two VERY good and easy-to-understand example. Nicely
    > explained, thanks.
    >
    > So, that DOES prove what I said earlier... when it comes to .Net
    > programming, I really don't know what I don't know!
    >
    > Peter
    > OSR
    >
    >
    >
    > __________ Information from ESET Smart Security, version of virus
    > signature database 5269 (20100711) __________
    >
    > The message was checked by ESET Smart Security.
    >
    > http://www.eset.com
    >


    __________ Information from ESET Smart Security, version of virus
    signature database 5269 (20100711) __________

    The message was checked by ESET Smart Security.

    http://www.eset.com


    __________ Information from ESET Smart Security, version of virus
    signature database 5270 (20100711) __________

    The message was checked by ESET Smart Security.

    http://www.eset.com
Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Upcoming OSR Seminars
Developing Minifilters 29 July 2019 OSR Seminar Space
Writing WDF Drivers 23 Sept 2019 OSR Seminar Space
Kernel Debugging 21 Oct 2019 OSR Seminar Space
Internals & Software Drivers 18 Nov 2019 Dulles, VA