Compiling Device Drivers in C++

Hi,

I would like to know how to compile a device driver
written in C++. I have seen a product called DriverWorks but i want to
figure out if there is another way to do so.

regards,
CompuMe

Don
Thu Feb 02 10:16:05 CST 2006

The DDK compiler supports C and C++, but the kernel environment does not
support much C++. Take a look at http://www.hollistech.com/ for some C++
support. Also, read the article at
http://www.microsoft.com/whdc/driver/kernel/KMcode.mspx to understand the
pros and cons of using C++ in the kernel.

Avoid DriverWorks at all cost. You don't need to start with a ton of bugs.


--
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Remove StopSpam from the email to reply



"CompuMe" <compume01@gmail.com> wrote in message
news:1138896735.635212.177450@z14g2000cwz.googlegroups.com...
> Hi,
>
> I would like to know how to compile a device driver
> written in C++. I have seen a product called DriverWorks but i want to
> figure out if there is another way to do so.
>
> regards,
> CompuMe
>

mirage2k2
Fri Feb 03 05:19:16 CST 2006

Don is right, you want HtsCpp from hollistech, its a small c++ runtime
containing implementation of new/delete, etc. and also a mechanism for
ensuring that constructors/destructors for global classes get called. There
is no C++ exception handling in the kernel so you have to write your C++ so
that it does not throw any. Or if it does throw then #define a throw macro
that generates a bugcheck (BSOD).

Using HtsCpp you need to rename your DriverEntry() to CPP_DRIVER_ENTRY()


"Don Burn" wrote:

> The DDK compiler supports C and C++, but the kernel environment does not
> support much C++. Take a look at http://www.hollistech.com/ for some C++
> support. Also, read the article at
> http://www.microsoft.com/whdc/driver/kernel/KMcode.mspx to understand the
> pros and cons of using C++ in the kernel.
>
> Avoid DriverWorks at all cost. You don't need to start with a ton of bugs.
>
>
> --
> Don Burn (MVP, Windows DDK)
> Windows 2k/XP/2k3 Filesystem and Driver Consulting
> Remove StopSpam from the email to reply
>
>
>
> "CompuMe" <compume01@gmail.com> wrote in message
> news:1138896735.635212.177450@z14g2000cwz.googlegroups.com...
> > Hi,
> >
> > I would like to know how to compile a device driver
> > written in C++. I have seen a product called DriverWorks but i want to
> > figure out if there is another way to do so.
> >
> > regards,
> > CompuMe
> >
>
>
>

Mark
Fri Feb 03 06:32:14 CST 2006

On Fri, 3 Feb 2006 03:19:16 -0800, mirage2k2
<mirage2k2@discussions.microsoft.com> wrote:

>Don is right, you want HtsCpp from hollistech, its a small c++ runtime
>containing implementation of new/delete, etc. and also a mechanism for
>ensuring that constructors/destructors for global classes get called. There
>is no C++ exception handling in the kernel so you have to write your C++ so
>that it does not throw any. Or if it does throw then #define a throw macro
>that generates a bugcheck (BSOD).
>
>Using HtsCpp you need to rename your DriverEntry() to CPP_DRIVER_ENTRY()
>

Just so the OP knows all the alternatives - as an alternative to my
htscpp runtime library you can define new/delete operators in your
classes and avoid global objects and then you don't actually need a
c++ runtime.

>
>"Don Burn" wrote:
>
>> The DDK compiler supports C and C++, but the kernel environment does not
>> support much C++. Take a look at http://www.hollistech.com/ for some C++
>> support. Also, read the article at
>> http://www.microsoft.com/whdc/driver/kernel/KMcode.mspx to understand the
>> pros and cons of using C++ in the kernel.
>>
>> Avoid DriverWorks at all cost. You don't need to start with a ton of bugs.
>>
>>
>> --
>> Don Burn (MVP, Windows DDK)
>> Windows 2k/XP/2k3 Filesystem and Driver Consulting
>> Remove StopSpam from the email to reply
>>
>>
>>
>> "CompuMe" <compume01@gmail.com> wrote in message
>> news:1138896735.635212.177450@z14g2000cwz.googlegroups.com...
>> > Hi,
>> >
>> > I would like to know how to compile a device driver
>> > written in C++. I have seen a product called DriverWorks but i want to
>> > figure out if there is another way to do so.
>> >
>> > regards,
>> > CompuMe
>> >
>>
>>
>>


=====================
Mark Roddy DDK MVP
Windows Vista/2003/XP/2000 Consulting
Device and Filesystem Drivers
Hollis Technology Solutions 603-321-1032
www.hollistech.com

Vetzak
Fri Feb 03 07:34:24 CST 2006

It's funny everybody blindly agrees that C++ means programming OOP.
This is a misconception. One can program OOP using C++ but doesn't have
to. For example, all my driver sources are C++ (.cpp files), but I
never do OOP.

Don
Fri Feb 03 07:42:38 CST 2006

Well, if you are using C++ as a "Better C" fine and good, but with the
latest Microsoft compilers cranking up the warning level to 4 for a C file
will catch just about all the bugs compiling it as C++ will.

The question comes to why choose C++, and its great strength is in simple
classes, to handle abstractions.


--
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Remove StopSpam from the email to reply



"Vetzak" <ptrshrn@gmail.com> wrote in message
news:1138973664.361283.145310@f14g2000cwb.googlegroups.com...
> It's funny everybody blindly agrees that C++ means programming OOP.
> This is a misconception. One can program OOP using C++ but doesn't have
> to. For example, all my driver sources are C++ (.cpp files), but I
> never do OOP.
>

Ilya
Fri Feb 03 09:29:43 CST 2006

Don Burn wrote:
> Avoid DriverWorks at all cost. You don't need to start with a ton of bugs.

Don, I'd be curious to hear what serious problems you've encountered
with DriverWorks. I'm not related to Compuware (but I sure hope they're
in-touch enough to listen here!) so your feedback will only affect my
own future choices :)

So far, I've developed one driver with it and it mostly kept its
promise:
1. It provided OOP wrappers around WDM primitives such as
DRIVER_OBJECT, DEVICE_OBJECT, IRP and DMA_ADAPTER which were
transparent (i.e. not inventing much on top of the WDM model).
2. It provided some added-value such as cancel-safe queues but was
up-to-date enough to suggest you to use newer WDM-provided facilities
(CSQ).
3. Being a newbie WDM developer, it gave me a head-start -- an
AppWizard-generated project with a template code to fit my logic into.

The only fears I have about recommending it is the fact Compuware isn't
very developer-friendly and that DriverWorks will become obsolete once
WDF gets into speed.

Don
Fri Feb 03 09:39:44 CST 2006

Ilya,

I have only done code reviews for people with drivers written in
DriverWorks. One thing I do to start a code review is run the sources
through the various static analysis tools such as compiling with /W4,
running PreFast and PC-Lint, and where appropriate SDV. I do this since it
gives me a base measure of code quality to start my review with.

I have now encountered multiple times, when the customers code had few
if any bugs from this analysis. Where the problems occured was DriverWorks,
that had hundreds of errors reported. These were the how can anyone do this
type of error, including passing an unitialized pointer into a kernel
service routine for a buffer address, taking a lock and not freeing it, etc.

I will be the first to admit I have a bias against tool kits, since you
typically have to understand the underly code, and having seen the cases of
a bug where toolkit vendor says it is Microsofts, and Microsoft says show me
the bug in a WDM driver.


--
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Remove StopSpam from the email to reply



"Ilya Konstantinov" <ilya.konstantinov@gmail.com> wrote in message
news:1138980583.739644.264500@f14g2000cwb.googlegroups.com...
> Don Burn wrote:
>> Avoid DriverWorks at all cost. You don't need to start with a ton of
>> bugs.
>
> Don, I'd be curious to hear what serious problems you've encountered
> with DriverWorks. I'm not related to Compuware (but I sure hope they're
> in-touch enough to listen here!) so your feedback will only affect my
> own future choices :)
>
> So far, I've developed one driver with it and it mostly kept its
> promise:
> 1. It provided OOP wrappers around WDM primitives such as
> DRIVER_OBJECT, DEVICE_OBJECT, IRP and DMA_ADAPTER which were
> transparent (i.e. not inventing much on top of the WDM model).
> 2. It provided some added-value such as cancel-safe queues but was
> up-to-date enough to suggest you to use newer WDM-provided facilities
> (CSQ).
> 3. Being a newbie WDM developer, it gave me a head-start -- an
> AppWizard-generated project with a template code to fit my logic into.
>
> The only fears I have about recommending it is the fact Compuware isn't
> very developer-friendly and that DriverWorks will become obsolete once
> WDF gets into speed.
>

David
Fri Feb 03 11:18:20 CST 2006

Six or seven years ago we were writing a USB driver for a dual flash memory
reader that was not mass storage compliant. We returned pending from the
dispatch routine on a create, pnp, or power request (I forget which one) and
the DriverWorks code assumed it was a success. It then allowed other IRPs
to come in before the stack was set up. We had to fix that source file. We
did put it with the project so when the fix showed up we could confirm it
and just delete our version of that file and use theirs.

"Don Burn" <burn@stopspam.acm.org> wrote in message
news:O4%23cbgNKGHA.604@TK2MSFTNGP14.phx.gbl...
> Ilya,
>
> I have only done code reviews for people with drivers written in
> DriverWorks. One thing I do to start a code review is run the sources
> through the various static analysis tools such as compiling with /W4,
> running PreFast and PC-Lint, and where appropriate SDV. I do this since
> it gives me a base measure of code quality to start my review with.
>
> I have now encountered multiple times, when the customers code had few
> if any bugs from this analysis. Where the problems occured was
> DriverWorks, that had hundreds of errors reported. These were the how can
> anyone do this type of error, including passing an unitialized pointer
> into a kernel service routine for a buffer address, taking a lock and not
> freeing it, etc.
>
> I will be the first to admit I have a bias against tool kits, since
> you typically have to understand the underly code, and having seen the
> cases of a bug where toolkit vendor says it is Microsofts, and Microsoft
> says show me the bug in a WDM driver.
>
>
> --
> Don Burn (MVP, Windows DDK)
> Windows 2k/XP/2k3 Filesystem and Driver Consulting
> Remove StopSpam from the email to reply
>
>
>
> "Ilya Konstantinov" <ilya.konstantinov@gmail.com> wrote in message
> news:1138980583.739644.264500@f14g2000cwb.googlegroups.com...
>> Don Burn wrote:
>>> Avoid DriverWorks at all cost. You don't need to start with a ton of
>>> bugs.
>>
>> Don, I'd be curious to hear what serious problems you've encountered
>> with DriverWorks. I'm not related to Compuware (but I sure hope they're
>> in-touch enough to listen here!) so your feedback will only affect my
>> own future choices :)
>>
>> So far, I've developed one driver with it and it mostly kept its
>> promise:
>> 1. It provided OOP wrappers around WDM primitives such as
>> DRIVER_OBJECT, DEVICE_OBJECT, IRP and DMA_ADAPTER which were
>> transparent (i.e. not inventing much on top of the WDM model).
>> 2. It provided some added-value such as cancel-safe queues but was
>> up-to-date enough to suggest you to use newer WDM-provided facilities
>> (CSQ).
>> 3. Being a newbie WDM developer, it gave me a head-start -- an
>> AppWizard-generated project with a template code to fit my logic into.
>>
>> The only fears I have about recommending it is the fact Compuware isn't
>> very developer-friendly and that DriverWorks will become obsolete once
>> WDF gets into speed.
>>
>
>

Mark
Sat Feb 04 08:38:01 CST 2006

On 3 Feb 2006 05:34:24 -0800, "Vetzak" <ptrshrn@gmail.com> wrote:

>It's funny everybody blindly agrees that C++ means programming OOP.
>This is a misconception. One can program OOP using C++ but doesn't have
>to. For example, all my driver sources are C++ (.cpp files), but I
>never do OOP.

'Everybody' doesn't do that at all. We have had the C/C++ debate here
(for some value of here) repeatedly over the last 10 years or so and
all of the benefits/pitfalls and allergies have been identified and
documented, including the 'better 'c'' argument, which I made like 8
years ago. We try to avoid repeating the issues as it ends up being a
religious flame war and we currently have a negotiated although
informal truce.


=====================
Mark Roddy DDK MVP
Windows Vista/2003/XP/2000 Consulting
Device and Filesystem Drivers
Hollis Technology Solutions 603-321-1032
www.hollistech.com

pavel_a
Sun Feb 05 08:46:27 CST 2006

"Mark Roddy" wrote:
....
> We try to avoid repeating the issues as it ends up being a
> religious flame war and we currently have a negotiated although
> informal truce.

We're yet to see the editorial office of NT Insider assaulted by hordes of
indignant c++'ers... <g/>

--PA