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/


RAII in kernel mode drivers

scott_smithscott_smith Member Posts: 34

The (kernel mode) audio driver I've been working on has lots of clutter/complexity due to lack of any RAII class use. In order to ensure single-entry single-exit (SESE), there's copious use of preprocessor macros containing goto. The code is also filled with explicit calls to IUnknown->Release() and other pairs of allocate/deallocate type functions.

I've been itching to look into replacing all the ISomeType pointers with _com_ptr_t<ISomeType>, but having read through a really long thread here about C vs C++ in kernel mode drivers (among other threads), I looked at the _com_ptr_t type (as defined in the standard Windows header files) and confirmed that it does indeed use exceptions.

Then I ran across a Microsoft header-only C++ library called Windows Implementation Libraries (WIL):

The Windows Implementation Libraries (WIL) is a header-only C++ library created to make life easier
for developers on Windows through readable type-safe C++ interfaces for common Windows coding patterns.

Some things that WIL includes to whet your appetite:

- Smart pointers and auto-releasing resource wrappers...

A quick glance at the com_ptr_t type there seems to indicate that they don't use exceptions (unless you define a preprocessor symbol to indicate that you want them. WIL is clearly not designed exclusively for the kernel environment; e.g. it includes types to wrap window handles and other stuff that only applies to user mode.

Still, I'm wondering whether anyone has used (or looked into using) WIL types in kernel code?


Scott Smith
Windows Developer since 1989

Comments

  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 8,090
    edited September 23

    I don’t know about WIL, but there’s no reason you can’t use smart pointers (std::unique_ptr, for example) or auto storage class instances (so called “instantiated on the stack”) to rid yourself of the mess.

    That’s what I do (in the rare case I need to do tear down more complex than ExFreePool).

    Peter

    Peter Viscarola
    OSR
    @OSRDrivers

  • scott_smithscott_smith Member Posts: 34
    edited September 23

    ...there’s no reason you can’t use smart pointers (std::unique_ptr, for example)

    Good point. I saw contradictory statements (in the long C vs C++ post) saying std::unique_ptr was/wasn't OK to use in kernel code, so I hadn't looked into it yet.

    I can write the trivial RAII wrappers for some things, but I wouldn't attempt anything with all the complex behavior of _com_ptr_t<T>, and that's what I'd be using most frequently.


    Scott Smith
    Windows Developer since 1989

  • Tim_RobertsTim_Roberts Member - All Emails Posts: 13,627

    Remember that _com_ptr_t is actually a Microsoft compiler extension, and requires a backing library that might not be kernel-compatible. You can certainly create your own wrapper, similar to ATL's CComPtr. That has no special compiler support.

    Tim Roberts, [email protected]
    Providenza & Boekelheide, Inc.

  • scott_smithscott_smith Member Posts: 34
    edited September 24

    Remember that _com_ptr_t is actually a Microsoft compiler extension...

    I had no idea that was the case.


    Scott Smith
    Windows Developer since 1989

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
OSR has suspended in-person seminars due to the Covid-19 outbreak. But, don't miss your training! Attend via the internet instead!
Writing WDF Drivers 7 Dec 2020 LIVE ONLINE
Internals & Software Drivers 25 Jan 2021 LIVE ONLINE
Developing Minifilters 8 March 2021 LIVE ONLINE