Building drivers is substantially different from building applications. No integrated development tools such as Microsoft Visual Studio exist to automatically handle most of the complexity of configuring and running the build process. Instead, you'll find that driver developers:
Use a text editor to create and edit the project's files.
A special-purpose code editor is typically used, but any text editor will work.
Use the command-line Build utility-included with the WDK-to build the driver.
This Build utility builds the driver binary and related files by using compilers, linkers, and preprocessors that are also included with the WDK.
In addition to source files, create a make file and several other supporting files that contain the instructions and data that the Build utility uses to perform the build.
All of these files must be created manually by using a text editor. Developers typically create supporting files for a project by copying the files that a similar sample uses and modifying the files as necessary.
The process of creating the supporting files and building the driver is similar for both UMDF and KMDF drivers. However, the two frameworks do have some general differences, controlled by the choice of programming language and the fact that they depend on different DDIs.
Consider the following issues when preparing to build UMDF drivers:
UMDF drivers are almost always written in C++.
UMDF drivers are basically a collection of COM objects, and C++ is the preferred language for developing COM-based programs. It's possible to implement UMDF drivers with C, but it's cumbersome and not often done.
UMDF does not support implementing drivers with managed languages such as C#.
UMDF code files have a .cpp prefix and use the C++ compiler.
The code files must include Wudfddi.h.
This standard header file contains the declarations for the DDI that UMDF drivers use.
The driver must bind to the UMDF libraries.
Consider the following issues when preparing to build KMDF drivers:
KMDF drivers are written in C.
C++ can be used for kernel-mode development in only a limited way. You can safely use some basic C++ features like inline variable declaration, but the object-oriented features of C++ produce code that is not guaranteed to work correctly in kernel mode. For example, the compiler might not allocate memory from the correct pool.
Info See "C++ for Kernel Mode Drivers: Pros and Cons" on the WHDC Web site for a discussion of C++ and kernel-mode drivers-online at http://go.microsoft.com/fwlink/?LinkId=80060.
KMDF code files can use the .c extension to invoke the C compiler. However, many driver projects use the .cpp extension to invoke the C++ compiler.
The use of the .cpp extension is a recommended practice. The C++ compiler works well with C code and provides better error detection and type safety than the C compiler. However, to suppress C++ name mangling you must add the extern C prefix to function declarations.
The source files must include Ntddk.h and Wdf.h.
These standard header files contain the declarations for the DDI that KMDF drivers use.
The project must bind to the KMDF libraries.
Tip See "Building Drivers" in the WDK for an overview of the tools and procedures used to build Windows drivers-online at http://go.microsoft.com/fwlink/?LinkId=79348.