Windows drivers are traditionally written in C language (not C++) and Microsoft Corp. officially supports this variant only (see the " C++ for Kernel Mode Drivers: Pros and Cons" document of WINHEC 2004 Version at www.microsoft.com/whdc/driver/kernel/KMcode.mspx).

The advantages of C++ over C are widely known:

  • object-oriented programming style which makes the development of large projects easier
  • support of exceptions which simplifies the code of handling errors and makes the code more readable
  • support of templates (STL/ standard library)
  • great number of other improvements which makes the language more flexible and simplifies the development process.

Naturally, it would be great to use these advantages in driver development.

 

Theoretically, using C++ in drivers isn't forbidden since the compiler from DDK compiles code in C++ without any problem. However, some language tools are not supported by standard:

  • new and delete global statements are not presented here (this doesn't cause problems as new and delete statements can be implemented very easy)
  • constructors and destructors of global objects are not called (it's not a big problem either, as it's possible to create/initialize global objects with new statement )
  • there is no support for C++ exceptions
  • there is no support for Run-Time Type Information (RTTI) (as a rule, it doesn't cause problems because of doubtful usefulness of RTTI in drivers)

The most critical and unpleasant limitation is that C++ exceptions aren't supported - after all, exceptions are an exceptionally convenient mechanism for handling errors.

There is a kind of substitution for C++ exceptions - it' SEH (Structured Exception Handling), the standard Windows exception handling mechanism. This mechanism is less convenient than C++ exceptions and its main disadvantage is the following: when throwing an exception from a function, the destructors of the local objects constructed in this function are not called.

However, the limitations mentioned above are not fundamental for drivers. The part of C++ standard library ensures the functioning of the indicated language tools. There is no such library for the kernel mode of the operating system, but nothing prevents us from implementing this missing part of standard library and, to be honest, it was done by some unrecognized hero in the Internet.

There are two variants of this magic library (libcpp): in one variant the missing functionality is written originally by author, in another one only small part is written by hand, and the rest is adopted from Visual Studio (6th or 7th version, obj- and lib-files). The library provides functioning of all of the listed "problem" language tools.

When functioning of all language tools is provided, STL, the most powerful standard library of C++, can be used the most valuably, and also porting of other libraries from user-mode to kernel-mode is substantially simplified.

We must also mention that except for the listed advantages of using C++, there are some disadvantages:

  • Exceptions processing takes a lot of space in stack and this can cause its overflow as stack size in kernel mode is very small (about 12 Kb). That's why one should work with exceptions very carefully.
  • STL library often allocates a lot of small areas in dynamic memory that causes its fragmentation.
  • The architecture of exceptions was rebuilt much in 64-bit version of Windows and the 64-bit version of libcpp library does not exist at the moment. As a result, it's impossible to port the drivers which use it to Windows x64. Now we are doing research of this point and apparently we'll have to rewrite some parts of this library ourselves.

 

Take a look at the Apriorit proprietary technologies:

Audio recorder SDK for Windows

On-the-fly file encryption software development kit

Subscribe to updates