{"id":39,"date":"2006-10-10T23:53:05","date_gmt":"2006-10-10T23:53:05","guid":{"rendered":"https:\/\/driverentry.com.br\/en\/2006\/10\/10\/driver-plus-plus\/"},"modified":"2026-07-27T20:44:47","modified_gmt":"2026-07-27T20:44:47","slug":"driver-plus-plus","status":"publish","type":"post","link":"https:\/\/driverentry.com.br\/en\/2006\/10\/10\/driver-plus-plus\/","title":{"rendered":"Driver plus plus"},"content":{"rendered":"
\"\"<\/a><\/div>\n

Developing low-level software is really good. I personally love the kind of work I do. I have close friends who marvel at C++ beauty, how things appear to fit perfectly among STL, iterators and templates. My business is definitely another. Despite using C\/C++, Assembly and appreciating these languages a lot, I don’t deeply dedicate myself to study C++. My practical side to solve problems leads me to do some things that would make my fried Slug<\/a> want to beat me, but fortunately he is a calm person. \ud83d\ude1b<\/p>\n

After my brother (Kabloc<\/a>) had read my post Getting Started…,<\/a> he asked me whether it’s be possible tp use C++ instead of C for developing drivers. In this post I will summarize the problems to get an object-oriented Blue Screen. I will not opine whether C++ is better or worse than C to write drivers. This is a discussion that seems to have no end. If you participate in any discussion list about driver development, you know what I mean. I personally prefer create classes, namespaces and templates that address in a modular way to my problems. That seems to be more comfortable. In fact, we can feel a certain tendency in Kernel Mode development for object-oriented programming. This is something increasingly present with DDIs (device-driver interfaces) using COM model for communication between layers in Kernel and the coming of WDF<\/a>. Remember that using COM model does not mean using COM, but only the concept of derived interfaces well known as IUnknown<\/strong> to implement reference counters and exchange interfaces.<\/p>\n

First of all, let us build the sample project created in my previous post<\/a> to show a driver that makes use of a class. As the tradition dictates, we’ll start thinking it’s easy and simply use the CPP file extension at source below and see what happens.<\/p>\n

\n
#include<\/span>  <\/span><\/pre>\n
 <\/pre>\n
\/\/-f--> A class with a very original name<\/span><\/pre>\n
class<\/span> MyClass<\/pre>\n
{<\/pre>\n
public<\/span>:<\/pre>\n
    MyClass()<\/pre>\n
    {<\/pre>\n
        DbgPrint(\"Constructor %p\\n\"<\/span>, this<\/span>);<\/pre>\n
    }<\/pre>\n
 <\/pre>\n
    ~MyClass()<\/pre>\n
    {<\/pre>\n
        DbgPrint(\"Destructor %p\\n\"<\/span>, this<\/span>);<\/pre>\n
    }<\/pre>\n
 <\/pre>\n
    VOID SayHello(VOID)<\/pre>\n
    {<\/pre>\n
        DbgPrint(\"Hello from %p\\n\"<\/span>, this<\/span>);<\/pre>\n
    }<\/pre>\n
};<\/pre>\n
 <\/pre>\n
 <\/pre>\n
\/****<\/span><\/pre>\n
***<\/span><\/pre>\n
**      DriverEntry <\/span><\/pre>\n
*\/<\/span><\/pre>\n
 <\/pre>\n
NTSTATUS DriverEntry(IN PDRIVER_OBJECT  pDriverObject,<\/pre>\n
                     IN PUNICODE_STRING pusRegistryPath)<\/pre>\n
{<\/pre>\n
    MyClass Instance;<\/pre>\n
 <\/pre>\n
    \/\/-f--> A life sign<\/span><\/pre>\n
    DbgPrint(\"DriverEntry called\\n\"<\/span>);<\/pre>\n
 <\/pre>\n
    \/\/-f--> Hello...<\/span><\/pre>\n
    Instance.SayHello();<\/pre>\n
 <\/pre>\n
    \/\/-f--> Everything is fine so far<\/span><\/pre>\n
    return<\/span> STATUS_SUCCESS;<\/pre>\n
}<\/pre>\n<\/div>\n
Round #1…<\/strong><\/p>\n
\n
Compiling - krnclass.cpp for i386<\/pre>\n
...\\ntddk.h(2152) : error C2220: warning treated as error - no object<\/pre>\n
                    file generated<\/pre>\n
...\\ntddk.h(2152) : error C4162: '_ReturnAddress' : no function with<\/pre>\n
                    C linkage found<\/pre>\n
...\\ntddk.h(6889) : error C4162: '_InterlockedExchange' : no function<\/pre>\n
                    with C linkage found<\/pre>\n
...\\ntddk.h(6915) : error C4162: '_InterlockedIncrement' : no function<\/pre>\n
                    with C linkage found<\/pre>\n
...\\ntddk.h(6928) : error C4162: '_InterlockedDecrement' : no function<\/pre>\n
                    with C linkage found<\/pre>\n
...\\ntddk.h(6942) : error C4162: '_InterlockedExchangeAdd' : no function<\/pre>\n
                    with C linkage found<\/pre>\n
...\\ntddk.h(6972) : error C4162: '_InterlockedCompareExchange' : no<\/pre>\n
                    function with C linkage found<\/pre>\n
...\\ntddk.h(7024) : error C4162: '_InterlockedOr' : no function with C<\/pre>\n
                    linkage found<\/pre>\n
...\\ntddk.h(7034) : error C4162: '_InterlockedAnd' : no function with C<\/pre>\n
                    linkage found<\/pre>\n
...\\ntddk.h(7044) : error C4162: '_InterlockedXor' : no function with C<\/pre>\n
                    linkage found<\/pre>\n<\/div>\n
We find some definitions in ntddk.h that need to be compiled in C, and not in C++. This problem will also happen with the driver’s entry point DriverEntry<\/strong>. DDK expects to find this exported symbol as C. But this is still very easy to solve, just change the way we include this header and the way we declare our entry point so, that it’ll look as shown below.<\/p>\n
\n
extern<\/span> \"C\"<\/span><\/pre>\n
{<\/pre>\n
    #include<\/span> <\/pre>\n
}<\/pre>\n
 <\/pre>\n
...<\/pre>\n
 <\/pre>\n
extern<\/span> \"C\"<\/span><\/pre>\n
NTSTATUS DriverEntry(IN PDRIVER_OBJECT  pDriverObject,<\/pre>\n
                     IN PUNICODE_STRING pusRegistryPath)<\/pre>\n
{<\/pre>\n<\/div>\n
So, it has compiled properly. Loading this driver, we can see the following messages in DebugMon<\/a>.<\/p>\n
\"\"<\/div>\n
Are we done? Do we already have a driver in C++? Not yet. We can already enjoy some concepts like classes, templates and overloads, for example, but let’s see what happens when we try to use the new<\/em> operator.<\/p>\n
\n
extern<\/span> \"C\"<\/span><\/pre>\n
NTSTATUS DriverEntry(IN PDRIVER_OBJECT  pDriverObject,<\/pre>\n
                     IN PUNICODE_STRING pusRegistryPath)<\/pre>\n
{<\/pre>\n
    MyClass *pInstance = NULL;<\/pre>\n
 <\/pre>\n
    \/\/-f--> Creating an instance dynamically<\/span><\/pre>\n
    pInstance = new<\/span> MyClass();<\/pre>\n
 <\/pre>\n
    \/\/-f--> Crashphobia<\/span><\/pre>\n
    if<\/span> (!pInstance)<\/pre>\n
        return<\/span> STATUS_NO_MEMORY;<\/pre>\n
 <\/pre>\n
    \/\/-f--> Hello from heap<\/span><\/pre>\n
    pInstance->SayHello();<\/pre>\n
 <\/pre>\n
    \/\/-f--> Releasing<\/span><\/pre>\n
    delete<\/span> pInstance;<\/pre>\n
 <\/pre>\n
    \/\/-f--> Everything is fine so far<\/span><\/pre>\n
    return<\/span> STATUS_SUCCESS;<\/pre>\n
}<\/pre>\n
 <\/pre>\n<\/div>\n
Round #2…<\/strong><\/p>\n
\n
Linking Executable - objchk_wxp_x86\\i386\\krnclass.sys for i386<\/pre>\n
krnclass.obj : error LNK2019: unresolved external symbol \"void * __cdecl<\/pre>\n
               operator new(unsigned int)\" (??2@YAPAXI@Z) referenced in<\/pre>\n
               function _DriverEntry@8<\/pre>\n
krnclass.obj : error LNK2019: unresolved external symbol \"void __cdecl<\/pre>\n
               operator delete(void *)\" (??3@YAXPAX@Z) referenced in<\/pre>\n
               function \"public: void * __thiscall MyClass::`scalar<\/pre>\n
               deleting destructor'(unsigned int)\" (??_GMyClass@@QAEPAXI@Z)<\/pre>\n
objchk_wxp_x86\\i386\\krnclass.sys : error LNK1120: 2 unresolved externals<\/pre>\n<\/div>\n
Oops! To resolve these dependencies, we have to overload new<\/em> and delete <\/em>operators so, that allocations would be made through the ExAllocatePool()<\/a>. Let’s pass an additional parameter to the new operator so that we can choose between NonPagedPool<\/strong>, PagedPool<\/strong> and so on …<\/p>\n
\n
typedef<\/span> unsigned<\/span> int<\/span> size_t;<\/pre>\n
 <\/pre>\n
\/\/-f--> Overloading the new operator<\/span><\/pre>\n
__inline<\/span> void<\/span>* __cdecl<\/span> operator<\/span> new<\/span>(size_t size,<\/pre>\n
                                    POOL_TYPE pool)<\/pre>\n
{<\/pre>\n
    return<\/span> ExAllocatePool(pool, size);<\/pre>\n
}<\/pre>\n
 <\/pre>\n
\/\/-f--> Overloading the delete operator<\/span><\/pre>\n
__inline<\/span> void<\/span> __cdecl<\/span> operator<\/span> delete<\/span>(void<\/span> *pVoid)<\/pre>\n
{<\/pre>\n
    ExFreePool(pVoid);<\/pre>\n
}<\/pre>\n
 <\/pre>\n
...<\/pre>\n
 <\/pre>\n
    \/\/-f--> We should specify the pool type here<\/span><\/pre>\n
    pInstance = new<\/span>(NonPagedPool) MyClass();<\/pre>\n
 <\/pre>\n
...<\/pre>\n<\/div>\n
Now it compiles again and the memory allocations are made in the way it should do, but there is another problem that happens when you try to create static or global objects. Let’s demonstrate this by creating a global instance and again, trying to compile this example.<\/p>\n
Round #3…<\/strong><\/p>\n
\n
Linking Executable - objchk_wxp_x86\\i386\\krnclass.sys for i386<\/pre>\n
krnclass.obj : error LNK2019: unresolved external symbol _atexit<\/pre>\n
               referenced in function _$E1<\/pre>\n
objchk_wxp_x86\\i386\\krnclass.sys : error LNK1120: 1 unresolved externals<\/pre>\n<\/div>\n
Since we have no support to C++ in Kernel, we have no run-time that implements all static object initialization by calling all global constructors and destructors of them. This is a process somewhat complicated and it will require some more concepts. There is a very good article<\/a> from Matt Pietrek that describes this process. Looks like this will give us a lot of work, but fortunately there is a MSI that brings an implementation of Kernel C++ run-time at Hollis Technology Solutions<\/a> site . The package is an open source, and thus, it brings all the source code with it (including an example) and the libraries of this implementation.<\/p>\n
\"\"<\/div>\n
This run-time implementation is broader than described in this post and we will have enough to play with C++ in Kernel. For C users, it brings even the definitions of malloc()<\/strong> and free()<\/strong>. The only uncomfortable thing I found in this package is a need to replace the definition of our DriverEntry() <\/strong>entry point to CPP_DRIVER_ENTRY<\/strong>.<\/p>\n
\n
#include<\/span> <\/pre>\n
 <\/pre>\n
...<\/pre>\n
 <\/pre>\n
\/****<\/span><\/pre>\n
***<\/span><\/pre>\n
**      DriverEntry <\/span><\/pre>\n
*\/<\/span><\/pre>\n
CPP_DRIVER_ENTRY(IN PDRIVER_OBJECT  pDriverObject,<\/pre>\n
                 IN PUNICODE_STRING pusRegistryPath)<\/pre>\n
{<\/pre>\n
 <\/pre>\n
...<\/pre>\n<\/div>\n

<\/p>\n
I’ll leave an example for downloading about how to use this package, admitting that you have installed MSI on C:\\Library\\HtsCpp. This example may also serve as the basis for future posts that would use object orientation feature. Anyway, the following is a preview of how your SOURCES file should be.<\/p>\n
\n
TARGETNAME=KrnClass<\/pre>\n
TARGETPATH=obj<\/pre>\n
TARGETTYPE=DRIVER<\/pre>\n
 <\/pre>\n
!if \"$(DDKBUILDENV)\" == \"fre\"<\/pre>\n
BUILD_CONFIG=libFre<\/pre>\n
!else<\/pre>\n
BUILD_CONFIG=libChk<\/pre>\n
!endif<\/pre>\n
 <\/pre>\n
TARGETLIBS=C:\\Library\\HtsCpp\\$(BUILD_CONFIG)\\i386\\HtsCpp.lib<\/pre>\n
 <\/pre>\n
INCLUDES=C:\\Library\\HtsCpp\\sys\\inc;<\/pre>\n
 <\/pre>\n
SOURCES=KrnClass.cpp<\/pre>\n<\/div>\n
See you! \ud83d\ude42<\/p>\n
KrnClass.zip<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"
Developing low-level software is really good. I personally love the kind of work I do. I have close friends who marvel at C++ beauty, how things appear to fit perfectly among STL, iterators and templates. My business is definitely another. Despite using C\/C++, Assembly and appreciating these languages a lot, I don’t deeply dedicate myself […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"pagelayer_contact_templates":[],"_pagelayer_content":"","footnotes":""},"categories":[1],"tags":[],"class_list":["post-39","post","type-post","status-publish","format-standard","hentry","category-uncategorized"],"_links":{"self":[{"href":"https:\/\/driverentry.com.br\/en\/wp-json\/wp\/v2\/posts\/39","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/driverentry.com.br\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/driverentry.com.br\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/driverentry.com.br\/en\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/driverentry.com.br\/en\/wp-json\/wp\/v2\/comments?post=39"}],"version-history":[{"count":4,"href":"https:\/\/driverentry.com.br\/en\/wp-json\/wp\/v2\/posts\/39\/revisions"}],"predecessor-version":[{"id":312,"href":"https:\/\/driverentry.com.br\/en\/wp-json\/wp\/v2\/posts\/39\/revisions\/312"}],"wp:attachment":[{"href":"https:\/\/driverentry.com.br\/en\/wp-json\/wp\/v2\/media?parent=39"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/driverentry.com.br\/en\/wp-json\/wp\/v2\/categories?post=39"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/driverentry.com.br\/en\/wp-json\/wp\/v2\/tags?post=39"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}