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

Home NTDEV

Before Posting...

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

More Info on Driver Writing and Debugging


The free OSR Learning Library has more than 50 articles on a wide variety of topics about writing and debugging device drivers and Minifilters. From introductory level to advanced. All the articles have been recently reviewed and updated, and are written using the clear and definitive style you've come to expect from OSR over the years.


Check out The OSR Learning Library at: https://www.osr.com/osr-learning-library/


What methodology for developing driver !!!!!!!

OSR_Community_UserOSR_Community_User Member Posts: 110,217
Hi all,

I want to begin writing Kernel mode driver for Windows NT/Win2K, what should
I know and understand before I begin? What methodology should I follow? Is
their any specific development cycle I need to follow? Is there any standard
test process I need to go about?

Any inputs or pointers will be highly appreciated..

Many Thanks,
Giri

Comments

  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    >I want to begin writing Kernel mode driver for Windows NT/Win2K, what should
    >I know and understand before I begin?

    I good thing to know is EXACTLY what interface you want the driver to
    present to user-mode. Often, I find my clients make hardware, and have no
    idea how they would like the device to look to software. For example, one
    device I know could be presented as:

    1) a read/write interface to a memory window, with user mode code
    understanding what's where, and issuing read/write commands to the correct
    "memory" addresses

    2) an interface of many IOCTL's, with the driver knowing how to make each
    one happen in the hardware, these are logical commands, like do some
    specific operation

    The choice comes down to: what should run in kernel mode, and what in user
    mode. The simple memory window interface may work just fine, with a user
    mode DLL providing a higher level API to applications. I might actually
    argue that as little kernel mode code as possible should be used, as bugs
    in kernel mode kode can bring down your system. Bugs in user-mode code are
    much less dangerous to the overall system stability. On the other hand,
    design #2 may be able to do things that are impossible with design #1, or
    do them better/faster.

    Some standard devices have the interface predefined, if you make a video
    card it's pretty well defined what interface the driver must present.

    Actually, my belief is the OS should have provided a clear definition of
    how devices should talk to apps, in a very consistent manner. In reality,
    we have a bunch of unique interface definitions. To me, reading a network
    packet, or a disk sector, or a live video capture frame, or a response from
    your smart card, are not really all that different, yet each of these has a
    pretty different interface from an application point of view.

    It's often quite tricky to even figure out exactly what style of driver is
    "most" appropriate. For example, I've been working on a WDM Pnp function
    driver. I keep debating if it would have been better to be a bus filter
    driver thingy, due to the legacy interface it has to present to apps.

    >What methodology should I follow?

    That's a religous question, and I tend to avoid discussing religion on the
    Internet. I find methodology is influenced by available programming
    languages, and since the driver language choices are C or C (some will
    argue C++ works too, and assembler fragments are good sometimes too), your
    design methodology choices is also limited.

    >Is their any specific development cycle I need to follow?

    Sure...

    Step 1, swear about Microsoft's kernel debugger a bunch now, as you will
    want to when it's more productive to keep your cool.

    Step 2, tell the marketing people they probably should have considered
    driver development time in the product delivery schedule BEFORE scheduling
    all the marketing glitz

    Step 3, take a vacation NOW, as you will not get one after you start

    Step 4, write the driver

    Step 5, test the driver,

    Step 6, beta test the driver with customers who don't mind their system's
    crashing

    Step 7, repeat steps 4 through 6 until your budget is used up

    Step 8, disclaim any knowledge about the project, to deflect the criticism
    that will occure because the driver still has bugs or is too slow after
    using up all the assigned budget

    Step 9, go to step 1 for the next project, which may be the next version of
    the driver you just wrote

    >Is there any standard test process I need to go about?

    Some devices have test programs available. Use these. There are also some
    generic test programs for a variety of things (like how does you driver
    respond when all memory is used up). Also test on SMP systems, with a
    variety of hardware configurations (like bus bridges). You do own SMP
    systems? And systems with bus bridges?. And have a bunch of peripheral
    configurations? Customers frown when they have this weeks #1 selling
    whatever, and YOUR device+driver conflicts with it.

    >Any inputs or pointers will be highly appreciated..

    Sign up for this list, and join us sometimes happy and sometimes frustrated
    driver writers. There is a HUGE amount of knowledge among the list members,
    and sometimes list members will share that knowledge on days when not too
    many things went wrong.

    - Jan
  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    Download the DDK from Microsoft.COM. Read the design guides, and study the
    samples.

    Jim


    -----Original Message-----
    From: Girish Desai [mailto:[email protected]]
    Sent: Sunday, May 07, 2000 11:51 PM
    To: NT Developers Interest List
    Subject: [ntdev] What methodology for developing driver !!!!!!!


    Hi all,

    I want to begin writing Kernel mode driver for Windows NT/Win2K, what should
    I know and understand before I begin? What methodology should I follow? Is
    their any specific development cycle I need to follow? Is there any standard
    test process I need to go about?

    Any inputs or pointers will be highly appreciated..

    Many Thanks,
    Giri


    ---
    You are currently subscribed to ntdev as: [email protected]
    To unsubscribe send a blank email to $subst('Email.Unsub')
  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    Hi :
    You may consider to attend some seminars, I attended the one which held by
    Oney.
    It really help me a lot

    Hope that may help
    Michael Cheng




    Jim Mateer @lists.osr.com on 2000/05/10 01:19:38 AM

    Please respond to "NT Developers Interest List"

    Sent by: [email protected]


    To: "NT Developers Interest List"
    cc:

    Subject: [ntdev] RE: What methodology for developing driver !!!!!!!



    Download the DDK from Microsoft.COM. Read the design guides, and study the
    samples.

    Jim


    -----Original Message-----
    From: Girish Desai [mailto:[email protected]]
    Sent: Sunday, May 07, 2000 11:51 PM
    To: NT Developers Interest List
    Subject: [ntdev] What methodology for developing driver !!!!!!!


    Hi all,

    I want to begin writing Kernel mode driver for Windows NT/Win2K, what
    should
    I know and understand before I begin? What methodology should I follow? Is
    their any specific development cycle I need to follow? Is there any
    standard
    test process I need to go about?

    Any inputs or pointers will be highly appreciated..

    Many Thanks,
    Giri


    ---
    You are currently subscribed to ntdev as: [email protected]
    To unsubscribe send a blank email to $subst('Email.Unsub')

    ---
    You are currently subscribed to ntdev as: [email protected]
    To unsubscribe send a blank email to $subst('Email.Unsub')
Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. Sign in or register to get started.

Upcoming OSR Seminars
OSR has suspended in-person seminars due to the Covid-19 outbreak. But, don't miss your training! Attend via the internet instead!
Kernel Debugging 13-17 May 2024 Live, Online
Developing Minifilters 1-5 Apr 2024 Live, Online
Internals & Software Drivers 11-15 Mar 2024 Live, Online
Writing WDF Drivers 20-24 May 2024 Live, Online