C++, kernel mode, NDIS

Question about C++ and NDIS

Hi,

I have some experiences with developing
TDI,Protocol and Intermediate drivers.

In all my drivers I have used C language.
For me it is known some guidelines relating to writing
kernel-mode drivers which I red in DDK doc.
For example: Use ANSI C, dont use any standard C runtime library
function that maintains state,....etc.

My question is:
What is wrong with C++ in kernel-mode ?
I red some older articles in MSDN where are examples,
where are defined new operator, delete operator with help of
kernel-mode memory allocation etc.

I heart something about:
"Kernel can not process code compiled with C++ compiler normal way"
but If it is true I dont understand why.


What is wrong with C++ in Kernel mode ?
Especially what is wrong with C++ in NDIS drivers ?


Thanks !
Peter

Don
Fri Feb 06 07:39:30 CST 2004

Actually you can use C++ in the kernel, and there have been many wars on
newsgroups on whether you should. For a simple environment for C++ handling
see the "C++ kernel runtime environment" from http://www.hollistech.com/.

WARNING MY HUMBLE OPINION STARTING

The problem with C++ in the kernel is not if you should, but how to
constrain the world if you do. C++ is a powerful language that can generate
a lot of code behind your back (I used to run a code generator group for a
major compiler firm, so been there and done that). This represents a
problem for the driver developer since it is easy for the compiler to do
things you didn't intend, so of the biggies are:

1. Surprise copy constructors, where allocations an copies occur
without it being obvious
2. Large stack usage, remember the kernel has a very limited stack
3. Code generation at unexpected times, this is a variant of the
copy constructor, but can really nail you when you use pageable code
sections in the kernel.
4. Interesting potential interactions between C++ exception handling
and structured exception handling.

One other major complaint I have is that I now use ExFreePoolWithTag
whenever possible to add the check that I am freeing what I think, since C++
doesn't allow parameters on destructors I cannot do this.

I try never to use C++ in the kernel, except as a better C. Other
folks including parts of Microsoft do use it (though in Microsofts case I
understand they check the generated code quite thoroughly).

MY HUMBLE OPINION OFF

It is your choice, there are some interesting decisions to make.


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

"Peter" <pskvarka@softinengines.com> wrote in message
news:%232wPf%23H7DHA.2576@TK2MSFTNGP11.phx.gbl...
> Question about C++ and NDIS
>
> Hi,
>
> I have some experiences with developing
> TDI,Protocol and Intermediate drivers.
>
> In all my drivers I have used C language.
> For me it is known some guidelines relating to writing
> kernel-mode drivers which I red in DDK doc.
> For example: Use ANSI C, dont use any standard C runtime library
> function that maintains state,....etc.
>
> My question is:
> What is wrong with C++ in kernel-mode ?
> I red some older articles in MSDN where are examples,
> where are defined new operator, delete operator with help of
> kernel-mode memory allocation etc.
>
> I heart something about:
> "Kernel can not process code compiled with C++ compiler normal way"
> but If it is true I dont understand why.
>
>
> What is wrong with C++ in Kernel mode ?
> Especially what is wrong with C++ in NDIS drivers ?
>
>
> Thanks !
> Peter
>
>
>

Don
Fri Feb 06 14:47:16 CST 2004

Actually, this does not work, since the compiler will call delete without
for some things. So you always new with the tag and the tag says you must
free with the tag, then the compiler frees without the tag for a blue
screen! I believe Microsoft is looking in to the question of object
orientation in the kernel, but I'm not sure you will ever see C++ blessed,
it is too easy for the novice to think C++, so I will use RTTI and STL, and
other things that should never live in the kernel.


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


"Vitaly" <anonymous@discussions.microsoft.com> wrote in message
news:04301907-E391-4CDE-B951-3844231DD8F1@microsoft.com...
> Re: delete() with parameters, as any C++ method it allows overloading;
consider:
>
> void * __cdecl operator new(size_t Size, POOL_TYPE Type, ULONG Tag)
> {
> return ExAllocatePoolWithTag(Type, Size, Tag);
> }
>
> void __cdecl operator delete(void* p, ULONG Tag)
> {
> if (p) ExFreePoolWithTag(p, Tag);
> }
>
> IMHO: with enough effort and care C++ can be tuned up to be an efficient
tool for kernel development. The C++ side effects (ones you mentioned and
many others) could be taken care of by a kernel C++ subset/library, endorsed
and thoroughly tested by an entity setting standards in Windows driver
development... Until this happens, C++ in the kernel will remain a realm of
few enthusiasts. IHMO,
>
> - Vitaly
>
>
> ----- Don Burn wrote: -----
>
> Actually you can use C++ in the kernel, and there have been many wars
on
> newsgroups on whether you should. For a simple environment for C++
handling
> see the "C++ kernel runtime environment" from
http://www.hollistech.com/.
>
> WARNING MY HUMBLE OPINION STARTING
>
> The problem with C++ in the kernel is not if you should, but how to
> constrain the world if you do. C++ is a powerful language that can
generate
> a lot of code behind your back (I used to run a code generator group
for a
> major compiler firm, so been there and done that). This represents a
> problem for the driver developer since it is easy for the compiler to
do
> things you didn't intend, so of the biggies are:
>
> 1. Surprise copy constructors, where allocations an copies
occur
> without it being obvious
> 2. Large stack usage, remember the kernel has a very limited
stack
> 3. Code generation at unexpected times, this is a variant of
the
> copy constructor, but can really nail you when you use pageable code
> sections in the kernel.
> 4. Interesting potential interactions between C++ exception
handling
> and structured exception handling.
>
> One other major complaint I have is that I now use
ExFreePoolWithTag
> whenever possible to add the check that I am freeing what I think,
since C++
> doesn't allow parameters on destructors I cannot do this.
>
> I try never to use C++ in the kernel, except as a better C.
Other
> folks including parts of Microsoft do use it (though in Microsofts
case I
> understand they check the generated code quite thoroughly).
>
> MY HUMBLE OPINION OFF
>
> It is your choice, there are some interesting decisions to
make.
>
>
> --
> Don Burn (MVP, Windows DDK)
> Windows 2k/XP/2k3 Filesystem and Driver Consulting
> Remove StopSpam from the email to reply
>
> "Peter" <pskvarka@softinengines.com> wrote in message
> news:%232wPf%23H7DHA.2576@TK2MSFTNGP11.phx.gbl...
> > Question about C++ and NDIS
> >> Hi,
> >> I have some experiences with developing
> > TDI,Protocol and Intermediate drivers.
> >> In all my drivers I have used C language.
> > For me it is known some guidelines relating to writing
> > kernel-mode drivers which I red in DDK doc.
> > For example: Use ANSI C, dont use any standard C runtime library
> > function that maintains state,....etc.
> >> My question is:
> > What is wrong with C++ in kernel-mode ?
> > I red some older articles in MSDN where are examples,
> > where are defined new operator, delete operator with help of
> > kernel-mode memory allocation etc.
> >> I heart something about:
> > "Kernel can not process code compiled with C++ compiler normal way"
> > but If it is true I dont understand why.
> >>> What is wrong with C++ in Kernel mode ?
> > Especially what is wrong with C++ in NDIS drivers ?
> >>> Thanks !
> > Peter
> >>>

David
Fri Feb 06 15:16:19 CST 2004

Oh, we need C++ in the kernel. RTTI sounds good. Maybe we can use half
of the 64-bit CPU's address space for the kernel if they add all this
stuff. Also we need at least 32MB stacks in the kernel too - not a
measly 12KB.

"Don Burn" <burn@stopspam.acm.org> wrote in message
news:1027ve610tnuuc9@corp.supernews.com...
> Actually, this does not work, since the compiler will call delete
without
> for some things. So you always new with the tag and the tag says you
must
> free with the tag, then the compiler frees without the tag for a blue
> screen! I believe Microsoft is looking in to the question of object
> orientation in the kernel, but I'm not sure you will ever see C++
blessed,
> it is too easy for the novice to think C++, so I will use RTTI and
STL, and
> other things that should never live in the kernel.
>
>
> --
> Don Burn (MVP, Windows DDK)
> Windows 2k/XP/2k3 Filesystem and Driver Consulting
> Remove StopSpam from the email to reply
>
>
> "Vitaly" <anonymous@discussions.microsoft.com> wrote in message
> news:04301907-E391-4CDE-B951-3844231DD8F1@microsoft.com...
> > Re: delete() with parameters, as any C++ method it allows
overloading;
> consider:
> >
> > void * __cdecl operator new(size_t Size, POOL_TYPE Type, ULONG Tag)
> > {
> > return ExAllocatePoolWithTag(Type, Size, Tag);
> > }
> >
> > void __cdecl operator delete(void* p, ULONG Tag)
> > {
> > if (p) ExFreePoolWithTag(p, Tag);
> > }
> >
> > IMHO: with enough effort and care C++ can be tuned up to be an
efficient
> tool for kernel development. The C++ side effects (ones you mentioned
and
> many others) could be taken care of by a kernel C++ subset/library,
endorsed
> and thoroughly tested by an entity setting standards in Windows driver
> development... Until this happens, C++ in the kernel will remain a
realm of
> few enthusiasts. IHMO,
> >
> > - Vitaly
> >
> >
> > ----- Don Burn wrote: -----
> >
> > Actually you can use C++ in the kernel, and there have been
many wars
> on
> > newsgroups on whether you should. For a simple environment for
C++
> handling
> > see the "C++ kernel runtime environment" from
> http://www.hollistech.com/.
> >
> > WARNING MY HUMBLE OPINION STARTING
> >
> > The problem with C++ in the kernel is not if you should, but
how to
> > constrain the world if you do. C++ is a powerful language that
can
> generate
> > a lot of code behind your back (I used to run a code generator
group
> for a
> > major compiler firm, so been there and done that). This
represents a
> > problem for the driver developer since it is easy for the
compiler to
> do
> > things you didn't intend, so of the biggies are:
> >
> > 1. Surprise copy constructors, where allocations an
copies
> occur
> > without it being obvious
> > 2. Large stack usage, remember the kernel has a very
limited
> stack
> > 3. Code generation at unexpected times, this is a
variant of
> the
> > copy constructor, but can really nail you when you use pageable
code
> > sections in the kernel.
> > 4. Interesting potential interactions between C++
exception
> handling
> > and structured exception handling.
> >
> > One other major complaint I have is that I now use
> ExFreePoolWithTag
> > whenever possible to add the check that I am freeing what I
think,
> since C++
> > doesn't allow parameters on destructors I cannot do this.
> >
> > I try never to use C++ in the kernel, except as a better
C.
> Other
> > folks including parts of Microsoft do use it (though in
Microsofts
> case I
> > understand they check the generated code quite thoroughly).
> >
> > MY HUMBLE OPINION OFF
> >
> > It is your choice, there are some interesting decisions
to
> make.
> >
> >
> > --
> > Don Burn (MVP, Windows DDK)
> > Windows 2k/XP/2k3 Filesystem and Driver Consulting
> > Remove StopSpam from the email to reply
> >
> > "Peter" <pskvarka@softinengines.com> wrote in message
> > news:%232wPf%23H7DHA.2576@TK2MSFTNGP11.phx.gbl...
> > > Question about C++ and NDIS
> > >> Hi,
> > >> I have some experiences with developing
> > > TDI,Protocol and Intermediate drivers.
> > >> In all my drivers I have used C language.
> > > For me it is known some guidelines relating to writing
> > > kernel-mode drivers which I red in DDK doc.
> > > For example: Use ANSI C, dont use any standard C runtime
library
> > > function that maintains state,....etc.
> > >> My question is:
> > > What is wrong with C++ in kernel-mode ?
> > > I red some older articles in MSDN where are examples,
> > > where are defined new operator, delete operator with help of
> > > kernel-mode memory allocation etc.
> > >> I heart something about:
> > > "Kernel can not process code compiled with C++ compiler
normal way"
> > > but If it is true I dont understand why.
> > >>> What is wrong with C++ in Kernel mode ?
> > > Especially what is wrong with C++ in NDIS drivers ?
> > >>> Thanks !
> > > Peter
> > >>>
>
>

Walter
Fri Feb 06 15:42:10 CST 2004

"David J. Craig" wrote:
> Oh, we need C++ in the kernel. RTTI sounds good. Maybe we can use half
> of the 64-bit CPU's address space for the kernel if they add all this
> stuff. Also we need at least 32MB stacks in the kernel too - not a
> measly 12KB.

A little hyperbole to make a point is all well and good, but I object to
unsupported (and unsupportable) exaggeration. Most of my drivers are C++
and have *never* run out of stack. One reason I know is that the debug
build of my drivers includes stack probes, and the only time I ever get
failures is when I code incontinent recursion by mistake. As far as the
canard about thrown exceptions consuming lots of stack -- it's true: I
measured it one time (reported here long ago) and found that a
throw/catch used a bit more stack than did an IRP_MJ_PNP. Now, stack
space in the storage stack is truly scarce, so reliance on exceptions as
a way to handle errors would be a bad idea there. But, for the average
function driver for a USB device? There's just no problem there, and
it's silly to argue about it.

Will careless use of copy constructors bring the system down? I'm sure
it could, but the only place where I ever use lots of dynamic objects is
when I'm doing string manipulation during AddDevice. That happens once
in a driver's normal lifetime and isn't going to hurt.

Is C++ code inherently bigger than C code? I don't think so. The
compiler emits functions in individual COMDAT blocks that the linker
discards if they're unused. With every driver in the world replicating
the same 2000 lines of PnP and power management code, I think that
arguments about code bloat are a bit disingenuous.

Are template classes evil? They sure can be obscure, I'll grant you. If
we can't get the code to compile into the right pageable or non-pageable
sections, I really have to wonder why the world's biggest software
company can't add one stupid little #pragma or __declspec attribute to
make it work right. It's just one big happy company, isn't it?

And, while we're at it, what's *wrong* with RTTI? Isn't that what the
Object Manager is all about?

--
Walter Oney, Consulting and Training
Basic and Advanced Driver Programming Seminars
Check out our schedule at http://www.oneysoft.com

Don
Fri Feb 06 16:23:17 CST 2004

Walter:

Note in my original post I said "The problem with C++ in the kernel is
not if you should, but how to constrain the world if you do." Obviously
from your description below you have constrained your world and things work
for you. The problem is that it is easy for someone less knowledgeable to
make a few changes hit the problems I mentioned.

My one personal experience with a "true C++ driver" was a piece of code
given to me that did not work, but "our expert has coded it you just need to
debug it", unfortunately the 64KB of stack used by the expert and the horrid
intermingling of SEH and C++ exceptions (they do not clean up after each
other!) made the statement "you just need to debug it" translate into "throw
the crap out and rewrite it".

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

"Walter Oney" <waltoney@oneysoft.com> wrote in message
news:40240A32.94FF665D@oneysoft.com...
> "David J. Craig" wrote:
> > Oh, we need C++ in the kernel. RTTI sounds good. Maybe we can use half
> > of the 64-bit CPU's address space for the kernel if they add all this
> > stuff. Also we need at least 32MB stacks in the kernel too - not a
> > measly 12KB.
>
> A little hyperbole to make a point is all well and good, but I object to
> unsupported (and unsupportable) exaggeration. Most of my drivers are C++
> and have *never* run out of stack. One reason I know is that the debug
> build of my drivers includes stack probes, and the only time I ever get
> failures is when I code incontinent recursion by mistake. As far as the
> canard about thrown exceptions consuming lots of stack -- it's true: I
> measured it one time (reported here long ago) and found that a
> throw/catch used a bit more stack than did an IRP_MJ_PNP. Now, stack
> space in the storage stack is truly scarce, so reliance on exceptions as
> a way to handle errors would be a bad idea there. But, for the average
> function driver for a USB device? There's just no problem there, and
> it's silly to argue about it.
>
> Will careless use of copy constructors bring the system down? I'm sure
> it could, but the only place where I ever use lots of dynamic objects is
> when I'm doing string manipulation during AddDevice. That happens once
> in a driver's normal lifetime and isn't going to hurt.
>
> Is C++ code inherently bigger than C code? I don't think so. The
> compiler emits functions in individual COMDAT blocks that the linker
> discards if they're unused. With every driver in the world replicating
> the same 2000 lines of PnP and power management code, I think that
> arguments about code bloat are a bit disingenuous.
>
> Are template classes evil? They sure can be obscure, I'll grant you. If
> we can't get the code to compile into the right pageable or non-pageable
> sections, I really have to wonder why the world's biggest software
> company can't add one stupid little #pragma or __declspec attribute to
> make it work right. It's just one big happy company, isn't it?
>
> And, while we're at it, what's *wrong* with RTTI? Isn't that what the
> Object Manager is all about?
>
> --
> Walter Oney, Consulting and Training
> Basic and Advanced Driver Programming Seminars
> Check out our schedule at http://www.oneysoft.com

David
Fri Feb 06 17:47:14 CST 2004

Is C++ code bigger than C code? Is Cobol code bigger than assembly?
Both answers are simple - it depends. An experienced assembly
programmer can out perform any compiler if time is not a limited
resource. A beginning programmer can bloat assembly beyond belief. You
and Steve Heller, among others, can write small, tight, and fat C++
code. I can too, but it requires more experience and skill to write
good small code and avoid the 'extra' features such as C++ exception
handling mixed with class after class created on the stack. An
application might want to have exceptions destroy classes that don't
need to exist when an error occurs, but it sure won't work in the kernel
as easily. I think the object manager is only objects at some levels,
but it still is a bunch of structures with a fairly normal function API
and little enforced encaptualization of functions with the data.

Have you seen all the questions being asked lately? Some indicate a
total lack of knowledge about how the Windows kernel, device stacks, and
functions are related and how they should be used. Many appear to have
not even taken a device driver 101 course or read your book with some
understanding. Most apparently grabbed some sample code and are trying
to force it into their box.

"Walter Oney" <waltoney@oneysoft.com> wrote in message
news:40240A32.94FF665D@oneysoft.com...
> "David J. Craig" wrote:
> > Oh, we need C++ in the kernel. RTTI sounds good. Maybe we can use
half
> > of the 64-bit CPU's address space for the kernel if they add all
this
> > stuff. Also we need at least 32MB stacks in the kernel too - not a
> > measly 12KB.
>
> A little hyperbole to make a point is all well and good, but I object
to
> unsupported (and unsupportable) exaggeration. Most of my drivers are
C++
> and have *never* run out of stack. One reason I know is that the debug
> build of my drivers includes stack probes, and the only time I ever
get
> failures is when I code incontinent recursion by mistake. As far as
the
> canard about thrown exceptions consuming lots of stack -- it's true: I
> measured it one time (reported here long ago) and found that a
> throw/catch used a bit more stack than did an IRP_MJ_PNP. Now, stack
> space in the storage stack is truly scarce, so reliance on exceptions
as
> a way to handle errors would be a bad idea there. But, for the average
> function driver for a USB device? There's just no problem there, and
> it's silly to argue about it.
>
> Will careless use of copy constructors bring the system down? I'm sure
> it could, but the only place where I ever use lots of dynamic objects
is
> when I'm doing string manipulation during AddDevice. That happens once
> in a driver's normal lifetime and isn't going to hurt.
>
> Is C++ code inherently bigger than C code? I don't think so. The
> compiler emits functions in individual COMDAT blocks that the linker
> discards if they're unused. With every driver in the world replicating
> the same 2000 lines of PnP and power management code, I think that
> arguments about code bloat are a bit disingenuous.
>
> Are template classes evil? They sure can be obscure, I'll grant you.
If
> we can't get the code to compile into the right pageable or
non-pageable
> sections, I really have to wonder why the world's biggest software
> company can't add one stupid little #pragma or __declspec attribute to
> make it work right. It's just one big happy company, isn't it?
>
> And, while we're at it, what's *wrong* with RTTI? Isn't that what the
> Object Manager is all about?
>
> --
> Walter Oney, Consulting and Training
> Basic and Advanced Driver Programming Seminars
> Check out our schedule at http://www.oneysoft.com

G
Fri Feb 06 17:51:51 CST 2004

Helpfull as ever, i see.
Should you be writing drivers?

C++ is juat a tool, you use it for good or evel. C++ dosn't eat stack space
on it's own, and a smart C programmer could eat the stack space as well.

DriversStudio from Compuware offers a complete C++ framework, VS.NET
integration, you can compile from inside the IDE, etc...2 verry good kernel
debugers, SoftICE for local debuging and VisualSoftICE for remote debuging,
that in combination with VMware it's a must have for driver development,
IMHO

"David J. Craig" <SeniorDriversWriter@shogunyoshimuni.com.net> wrote in
message news:umHs4ZP7DHA.2300@TK2MSFTNGP10.phx.gbl...
> Oh, we need C++ in the kernel. RTTI sounds good. Maybe we can use half
> of the 64-bit CPU's address space for the kernel if they add all this
> stuff. Also we need at least 32MB stacks in the kernel too - not a
> measly 12KB.
>
> "Don Burn" <burn@stopspam.acm.org> wrote in message
> news:1027ve610tnuuc9@corp.supernews.com...
> > Actually, this does not work, since the compiler will call delete
> without
> > for some things. So you always new with the tag and the tag says you
> must
> > free with the tag, then the compiler frees without the tag for a blue
> > screen! I believe Microsoft is looking in to the question of object
> > orientation in the kernel, but I'm not sure you will ever see C++
> blessed,
> > it is too easy for the novice to think C++, so I will use RTTI and
> STL, and
> > other things that should never live in the kernel.
> >
> >
> > --
> > Don Burn (MVP, Windows DDK)
> > Windows 2k/XP/2k3 Filesystem and Driver Consulting
> > Remove StopSpam from the email to reply
> >
> >
> > "Vitaly" <anonymous@discussions.microsoft.com> wrote in message
> > news:04301907-E391-4CDE-B951-3844231DD8F1@microsoft.com...
> > > Re: delete() with parameters, as any C++ method it allows
> overloading;
> > consider:
> > >
> > > void * __cdecl operator new(size_t Size, POOL_TYPE Type, ULONG Tag)
> > > {
> > > return ExAllocatePoolWithTag(Type, Size, Tag);
> > > }
> > >
> > > void __cdecl operator delete(void* p, ULONG Tag)
> > > {
> > > if (p) ExFreePoolWithTag(p, Tag);
> > > }
> > >
> > > IMHO: with enough effort and care C++ can be tuned up to be an
> efficient
> > tool for kernel development. The C++ side effects (ones you mentioned
> and
> > many others) could be taken care of by a kernel C++ subset/library,
> endorsed
> > and thoroughly tested by an entity setting standards in Windows driver
> > development... Until this happens, C++ in the kernel will remain a
> realm of
> > few enthusiasts. IHMO,
> > >
> > > - Vitaly
> > >
> > >
> > > ----- Don Burn wrote: -----
> > >
> > > Actually you can use C++ in the kernel, and there have been
> many wars
> > on
> > > newsgroups on whether you should. For a simple environment for
> C++
> > handling
> > > see the "C++ kernel runtime environment" from
> > http://www.hollistech.com/.
> > >
> > > WARNING MY HUMBLE OPINION STARTING
> > >
> > > The problem with C++ in the kernel is not if you should, but
> how to
> > > constrain the world if you do. C++ is a powerful language that
> can
> > generate
> > > a lot of code behind your back (I used to run a code generator
> group
> > for a
> > > major compiler firm, so been there and done that). This
> represents a
> > > problem for the driver developer since it is easy for the
> compiler to
> > do
> > > things you didn't intend, so of the biggies are:
> > >
> > > 1. Surprise copy constructors, where allocations an
> copies
> > occur
> > > without it being obvious
> > > 2. Large stack usage, remember the kernel has a very
> limited
> > stack
> > > 3. Code generation at unexpected times, this is a
> variant of
> > the
> > > copy constructor, but can really nail you when you use pageable
> code
> > > sections in the kernel.
> > > 4. Interesting potential interactions between C++
> exception
> > handling
> > > and structured exception handling.
> > >
> > > One other major complaint I have is that I now use
> > ExFreePoolWithTag
> > > whenever possible to add the check that I am freeing what I
> think,
> > since C++
> > > doesn't allow parameters on destructors I cannot do this.
> > >
> > > I try never to use C++ in the kernel, except as a better
> C.
> > Other
> > > folks including parts of Microsoft do use it (though in
> Microsofts
> > case I
> > > understand they check the generated code quite thoroughly).
> > >
> > > MY HUMBLE OPINION OFF
> > >
> > > It is your choice, there are some interesting decisions
> to
> > make.
> > >
> > >
> > > --
> > > Don Burn (MVP, Windows DDK)
> > > Windows 2k/XP/2k3 Filesystem and Driver Consulting
> > > Remove StopSpam from the email to reply
> > >
> > > "Peter" <pskvarka@softinengines.com> wrote in message
> > > news:%232wPf%23H7DHA.2576@TK2MSFTNGP11.phx.gbl...
> > > > Question about C++ and NDIS
> > > >> Hi,
> > > >> I have some experiences with developing
> > > > TDI,Protocol and Intermediate drivers.
> > > >> In all my drivers I have used C language.
> > > > For me it is known some guidelines relating to writing
> > > > kernel-mode drivers which I red in DDK doc.
> > > > For example: Use ANSI C, dont use any standard C runtime
> library
> > > > function that maintains state,....etc.
> > > >> My question is:
> > > > What is wrong with C++ in kernel-mode ?
> > > > I red some older articles in MSDN where are examples,
> > > > where are defined new operator, delete operator with help of
> > > > kernel-mode memory allocation etc.
> > > >> I heart something about:
> > > > "Kernel can not process code compiled with C++ compiler
> normal way"
> > > > but If it is true I dont understand why.
> > > >>> What is wrong with C++ in Kernel mode ?
> > > > Especially what is wrong with C++ in NDIS drivers ?
> > > >>> Thanks !
> > > > Peter
> > > >>>
> >
> >
>
>

David
Fri Feb 06 19:22:05 CST 2004

I see you still don't have a clue. A couple of people on this list have
seen some of my code and it that works and is clean. It was written in
C++ using DriverWorks. I don't mind a 'smart C programmer' eating up
stack space. They will know the limitations of the environment and how
to overcome any problems. It is the newbie who has taken a few college
courses in programming basic and now thinks they can write drivers using
a sample and not even reading the DDK documentation. SoftIce had its
time and used to love it when I had to do the same drivers in 9x and NT,
especially since Windbg was extremely unstable. SoftIce's ability to
use a 3COM Ethernet card was also useful, especially since Windbg could
only do serial. I have found that with the transfer of ownership of the
various pieces of Compuware Numega's Driver Studio, it is priced far too
high. Another problem is Microsoft's soon to be framework. It may
solve many of the problems I used DriverWorks for in the past.

If you can't write drivers using C and the Microsoft APIs, you have no
business writing them with a framework. Early versions of DriverWorks
caused interesting problems if a pending status was returned to certain
commands since the code was only checking for the error bit to be set.
I had to report that bug and the fix to Numega. I actually started
using VtoolsD when it was Steve's code around 1995, I think. At one
time, Numega had a combo that could handle a driver that worked on both
9x and NT. This was before WDM and 2000. I have heard good things
about VMware, but never used it. I found that actually having two
machines to be easier and much safer for my primary system. Testing
code on your primary system is very dangerous, especially when the code
is a driver. Restoring a test system using Partition Magic from one HD
to another is fast and simple when the test image is only a few
megabytes.

Recently I had to write code for MS-DOS. One was an application that
used the BIOS and the other was a driver written in assembly. I am glad
I still had SoftIce for DOS, but I also have Periscope which is good
too, but not source code based. Restoring that partition was less than
a couple of seconds using Ghost.

I have been doing this so long, it is easy. I also enjoy being a
curmudgeon. P.S. I sometimes try to be helpful, but not much lately.
The overload of newbie questions has pushed me to be more of a lurker
than a participant, but I do like to stir the pot once in a while. Even
Walter slowed down participating for a while due to slowness in this
business. Consulting can be a bear as I know of many who are having
problems.


"G." <na@na.na> wrote in message
news:OTP21wQ7DHA.1428@TK2MSFTNGP12.phx.gbl...
> Helpfull as ever, i see.
> Should you be writing drivers?
>
> C++ is juat a tool, you use it for good or evel. C++ dosn't eat stack
space
> on it's own, and a smart C programmer could eat the stack space as
well.
>
> DriversStudio from Compuware offers a complete C++ framework, VS.NET
> integration, you can compile from inside the IDE, etc...2 verry good
kernel
> debugers, SoftICE for local debuging and VisualSoftICE for remote
debuging,
> that in combination with VMware it's a must have for driver
development,
> IMHO
>
> "David J. Craig" <SeniorDriversWriter@shogunyoshimuni.com.net> wrote
in
> message news:umHs4ZP7DHA.2300@TK2MSFTNGP10.phx.gbl...
> > Oh, we need C++ in the kernel. RTTI sounds good. Maybe we can use
half
> > of the 64-bit CPU's address space for the kernel if they add all
this
> > stuff. Also we need at least 32MB stacks in the kernel too - not a
> > measly 12KB.
> >
> > "Don Burn" <burn@stopspam.acm.org> wrote in message
> > news:1027ve610tnuuc9@corp.supernews.com...
> > > Actually, this does not work, since the compiler will call delete
> > without
> > > for some things. So you always new with the tag and the tag says
you
> > must
> > > free with the tag, then the compiler frees without the tag for a
blue
> > > screen! I believe Microsoft is looking in to the question of
object
> > > orientation in the kernel, but I'm not sure you will ever see C++
> > blessed,
> > > it is too easy for the novice to think C++, so I will use RTTI and
> > STL, and
> > > other things that should never live in the kernel.
> > >
> > >
> > > --
> > > Don Burn (MVP, Windows DDK)
> > > Windows 2k/XP/2k3 Filesystem and Driver Consulting
> > > Remove StopSpam from the email to reply
> > >
> > >
> > > "Vitaly" <anonymous@discussions.microsoft.com> wrote in message
> > > news:04301907-E391-4CDE-B951-3844231DD8F1@microsoft.com...
> > > > Re: delete() with parameters, as any C++ method it allows
> > overloading;
> > > consider:
> > > >
> > > > void * __cdecl operator new(size_t Size, POOL_TYPE Type, ULONG
Tag)
> > > > {
> > > > return ExAllocatePoolWithTag(Type, Size, Tag);
> > > > }
> > > >
> > > > void __cdecl operator delete(void* p, ULONG Tag)
> > > > {
> > > > if (p) ExFreePoolWithTag(p, Tag);
> > > > }
> > > >
> > > > IMHO: with enough effort and care C++ can be tuned up to be an
> > efficient
> > > tool for kernel development. The C++ side effects (ones you
mentioned
> > and
> > > many others) could be taken care of by a kernel C++
subset/library,
> > endorsed
> > > and thoroughly tested by an entity setting standards in Windows
driver
> > > development... Until this happens, C++ in the kernel will remain a
> > realm of
> > > few enthusiasts. IHMO,
> > > >
> > > > - Vitaly
> > > >
> > > >
> > > > ----- Don Burn wrote: -----
> > > >
> > > > Actually you can use C++ in the kernel, and there have been
> > many wars
> > > on
> > > > newsgroups on whether you should. For a simple environment
for
> > C++
> > > handling
> > > > see the "C++ kernel runtime environment" from
> > > http://www.hollistech.com/.
> > > >
> > > > WARNING MY HUMBLE OPINION STARTING
> > > >
> > > > The problem with C++ in the kernel is not if you should,
but
> > how to
> > > > constrain the world if you do. C++ is a powerful language
that
> > can
> > > generate
> > > > a lot of code behind your back (I used to run a code
generator
> > group
> > > for a
> > > > major compiler firm, so been there and done that). This
> > represents a
> > > > problem for the driver developer since it is easy for the
> > compiler to
> > > do
> > > > things you didn't intend, so of the biggies are:
> > > >
> > > > 1. Surprise copy constructors, where allocations an
> > copies
> > > occur
> > > > without it being obvious
> > > > 2. Large stack usage, remember the kernel has a
very
> > limited
> > > stack
> > > > 3. Code generation at unexpected times, this is a
> > variant of
> > > the
> > > > copy constructor, but can really nail you when you use
pageable
> > code
> > > > sections in the kernel.
> > > > 4. Interesting potential interactions between C++
> > exception
> > > handling
> > > > and structured exception handling.
> > > >
> > > > One other major complaint I have is that I now use
> > > ExFreePoolWithTag
> > > > whenever possible to add the check that I am freeing what I
> > think,
> > > since C++
> > > > doesn't allow parameters on destructors I cannot do this.
> > > >
> > > > I try never to use C++ in the kernel, except as a
better
> > C.
> > > Other
> > > > folks including parts of Microsoft do use it (though in
> > Microsofts
> > > case I
> > > > understand they check the generated code quite thoroughly).
> > > >
> > > > MY HUMBLE OPINION OFF
> > > >
> > > > It is your choice, there are some interesting
decisions
> > to
> > > make.
> > > >
> > > >
> > > > --
> > > > Don Burn (MVP, Windows DDK)
> > > > Windows 2k/XP/2k3 Filesystem and Driver Consulting
> > > > Remove StopSpam from the email to reply
> > > >
> > > > "Peter" <pskvarka@softinengines.com> wrote in message
> > > > news:%232wPf%23H7DHA.2576@TK2MSFTNGP11.phx.gbl...
> > > > > Question about C++ and NDIS
> > > > >> Hi,
> > > > >> I have some experiences with developing
> > > > > TDI,Protocol and Intermediate drivers.
> > > > >> In all my drivers I have used C language.
> > > > > For me it is known some guidelines relating to writing
> > > > > kernel-mode drivers which I red in DDK doc.
> > > > > For example: Use ANSI C, dont use any standard C runtime
> > library
> > > > > function that maintains state,....etc.
> > > > >> My question is:
> > > > > What is wrong with C++ in kernel-mode ?
> > > > > I red some older articles in MSDN where are examples,
> > > > > where are defined new operator, delete operator with help
of
> > > > > kernel-mode memory allocation etc.
> > > > >> I heart something about:
> > > > > "Kernel can not process code compiled with C++ compiler
> > normal way"
> > > > > but If it is true I dont understand why.
> > > > >>> What is wrong with C++ in Kernel mode ?
> > > > > Especially what is wrong with C++ in NDIS drivers ?
> > > > >>> Thanks !
> > > > > Peter
> > > > >>>
> > >
> > >
> >
> >
>
>

Alexander
Fri Feb 06 22:14:16 CST 2004

The matching operator delete is only called if a constructor throws an
exception (which in general should be avoided in kernel mode).

You can make class-specific operator delete, which would call
ExFreePoolWithTag. Or you can use the same tag for all the allocations in
your driver.

"Vitaly" <anonymous@discussions.microsoft.com> wrote in message
news:04301907-E391-4CDE-B951-3844231DD8F1@microsoft.com...
> Re: delete() with parameters, as any C++ method it allows overloading;
consider:
>
> void * __cdecl operator new(size_t Size, POOL_TYPE Type, ULONG Tag)
> {
> return ExAllocatePoolWithTag(Type, Size, Tag);
> }
>
> void __cdecl operator delete(void* p, ULONG Tag)
> {
> if (p) ExFreePoolWithTag(p, Tag);
> }
>
> IMHO: with enough effort and care C++ can be tuned up to be an efficient
tool for kernel development. The C++ side effects (ones you mentioned and
many others) could be taken care of by a kernel C++ subset/library, endorsed
and thoroughly tested by an entity setting standards in Windows driver
development... Until this happens, C++ in the kernel will remain a realm of
few enthusiasts. IHMO,
>
> - Vitaly
>
>
> ----- Don Burn wrote: -----
>
> Actually you can use C++ in the kernel, and there have been many wars
on
> newsgroups on whether you should. For a simple environment for C++
handling
> see the "C++ kernel runtime environment" from
http://www.hollistech.com/.
>
> WARNING MY HUMBLE OPINION STARTING
>
> The problem with C++ in the kernel is not if you should, but how to
> constrain the world if you do. C++ is a powerful language that can
generate
> a lot of code behind your back (I used to run a code generator group
for a
> major compiler firm, so been there and done that). This represents a
> problem for the driver developer since it is easy for the compiler to
do
> things you didn't intend, so of the biggies are:
>
> 1. Surprise copy constructors, where allocations an copies
occur
> without it being obvious
> 2. Large stack usage, remember the kernel has a very limited
stack
> 3. Code generation at unexpected times, this is a variant of
the
> copy constructor, but can really nail you when you use pageable code
> sections in the kernel.
> 4. Interesting potential interactions between C++ exception
handling
> and structured exception handling.
>
> One other major complaint I have is that I now use
ExFreePoolWithTag
> whenever possible to add the check that I am freeing what I think,
since C++
> doesn't allow parameters on destructors I cannot do this.
>
> I try never to use C++ in the kernel, except as a better C.
Other
> folks including parts of Microsoft do use it (though in Microsofts
case I
> understand they check the generated code quite thoroughly).
>
> MY HUMBLE OPINION OFF
>
> It is your choice, there are some interesting decisions to
make.
>
>
> --
> Don Burn (MVP, Windows DDK)
> Windows 2k/XP/2k3 Filesystem and Driver Consulting
> Remove StopSpam from the email to reply
>
> "Peter" <pskvarka@softinengines.com> wrote in message
> news:%232wPf%23H7DHA.2576@TK2MSFTNGP11.phx.gbl...
> > Question about C++ and NDIS
> >> Hi,
> >> I have some experiences with developing
> > TDI,Protocol and Intermediate drivers.
> >> In all my drivers I have used C language.
> > For me it is known some guidelines relating to writing
> > kernel-mode drivers which I red in DDK doc.
> > For example: Use ANSI C, dont use any standard C runtime library
> > function that maintains state,....etc.
> >> My question is:
> > What is wrong with C++ in kernel-mode ?
> > I red some older articles in MSDN where are examples,
> > where are defined new operator, delete operator with help of
> > kernel-mode memory allocation etc.
> >> I heart something about:
> > "Kernel can not process code compiled with C++ compiler normal way"
> > but If it is true I dont understand why.
> >>> What is wrong with C++ in Kernel mode ?
> > Especially what is wrong with C++ in NDIS drivers ?
> >>> Thanks !
> > Peter
> >>>

Maxim
Sat Feb 07 21:16:35 CST 2004

> What is wrong with C++ in Kernel mode ?

This is a Holy War question, and I do not want to start this Holy War.

But some items need mentioning:
- nobody will call constructors and destructors for static objects, there is on
"startup code", the driver starts just from DriverEntry
- C++ exception handling is very stack hungry, and the stack size is very much
limited.

--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim@storagecraft.com
http://www.storagecraft.com

Maxim
Sat Feb 07 21:19:57 CST 2004

> And, while we're at it, what's *wrong* with RTTI?

You can read Stroustrup himself (Stroustrup/Ellis book of around 1990) on this
subject :-) funny, but it is really so. :-)

Conceptual wrongness of any kind of RTTI is because it provocates
non-polymorphic coding styles, which are evil. Use polymorphysm instead.

As about _compiler-defined RTTI_ (compared to macro-based like MFC's
DECLARE_DYNAMIC) - is because the format of metaclass is fixed, and you cannot
lay out your metaclass the way you want.

--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim@storagecraft.com
http://www.storagecraft.com

Alexander
Sat Feb 07 21:31:35 CST 2004

Using dynamic_cast to cast a base class pointer to a derived class pointer
is in most cases wrong. There are valid cases, though.

Some recent article in CUJ (?) suggested that more proper use of RTTI
(dynamic_cast) is for things like QueryInterface. By having a pointer for
some base class, we request a pointer to another base class, to see, if the
object supplies some behavior (or interface).

"Maxim S. Shatskih" <maxim@storagecraft.com> wrote in message
news:%23kwvqIf7DHA.2644@TK2MSFTNGP11.phx.gbl...
> > And, while we're at it, what's *wrong* with RTTI?
>
> You can read Stroustrup himself (Stroustrup/Ellis book of around 1990) on
this
> subject :-) funny, but it is really so. :-)
>
> Conceptual wrongness of any kind of RTTI is because it provocates
> non-polymorphic coding styles, which are evil. Use polymorphysm instead.
>
> As about _compiler-defined RTTI_ (compared to macro-based like MFC's
> DECLARE_DYNAMIC) - is because the format of metaclass is fixed, and you
cannot
> lay out your metaclass the way you want.
>
> --
> Maxim Shatskih, Windows DDK MVP
> StorageCraft Corporation
> maxim@storagecraft.com
> http://www.storagecraft.com
>
>

Maxim
Sat Feb 07 21:58:55 CST 2004

> Using dynamic_cast to cast a base class pointer to a derived class pointer
> is in most cases wrong. There are valid cases, though.

Using <dynamic_cast> is wrong anyway, since there is the good old C-style cast
without the visual noise. :-)

> Some recent article in CUJ (?) suggested that more proper use of RTTI
> (dynamic_cast) is for things like QueryInterface. By having a pointer for
> some base class, we request a pointer to another base class, to see, if the
> object supplies some behavior (or interface).

Trivially implementable by macros and templates, and implementation will be a)
with source available b) more flexible.

--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim@storagecraft.com
http://www.storagecraft.com

Walter
Sun Feb 08 06:36:19 CST 2004

"Maxim S. Shatskih" wrote:
> - C++ exception handling is very stack hungry, and the stack size is very much
> limited.

Max, this has been debunked long since. A qualitative assessment ("very
stack hungry") is not an appropriate way to present a technical argument
about a quantitative issue. Get numbers (or find the web posting I made
a year or more ago where I *did* get numbers) and argue on the basis of
actual facts instead of Bush-like fuzzy math.

--
Walter Oney, Consulting and Training
Basic and Advanced Driver Programming Seminars
Check out our schedule at http://www.oneysoft.com

Alexander
Sun Feb 08 09:58:05 CST 2004

C-style cast is not typesafe. In most cases one should use static_cast
instead.

"Maxim S. Shatskih" <maxim@storagecraft.com> wrote in message
news:eFCXbef7DHA.1716@TK2MSFTNGP10.phx.gbl...
>
> Using <dynamic_cast> is wrong anyway, since there is the good old C-style
cast
> without the visual noise. :-)
>

Maxim
Sun Feb 08 10:06:31 CST 2004

In the absense of multiple inheritance (which is a vast majority of code),
all these casts do the same. In this situation, C-style is the best - lesser
visual noise.

--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim@storagecraft.com
http://www.storagecraft.com

"Alexander Grigoriev" <alegr@earthlink.net> wrote in message
news:euirYxl7DHA.712@tk2msftngp13.phx.gbl...
> C-style cast is not typesafe. In most cases one should use static_cast
> instead.
>
> "Maxim S. Shatskih" <maxim@storagecraft.com> wrote in message
> news:eFCXbef7DHA.1716@TK2MSFTNGP10.phx.gbl...
> >
> > Using <dynamic_cast> is wrong anyway, since there is the good old C-style
> cast
> > without the visual noise. :-)
> >
>
>

Dave
Sun Feb 08 12:09:39 CST 2004

Since this thread is still alive I'll toss in my two cents worth.

I've been writing drivers for Windows since before Win 3.11, if you've never
slaved over10,000 lines of assembler trying to squeeze a few more machine
cycles out of a video driver to get your 'PCLabs BenchMark' number up you
haven't written drivers... (can you say 'crack a ROP')

Back then ALL drivers were written in assembly language. I remember this
sort of disscussion happening when the idea of using standard C in a driver
was first floating around, all the same arguments were used then, and gee
now we are all happily cranking out drivers in C... hmmmm

I think Walter has made several good points one of the best being that the
issuse of code size is a joke considering most of us lug along his
generic.sys. As for using too much stack, come on guys, C++ is no more or
worse than some bumbeling junior programmer using a 2K buffer on the stack.
SEH verses Try/Catch is easy, just use SEH. And no I don't want to get into
the right and wrong things about the language spec itself, that REALLY is a
holy war.

IMHO it's not the language it's the programmer. I've seen some pretty bad
programs in C++ and some of the most elegant programming I've seen has been
in assembler...

I guess we'll all just have to wait for 'LongHorn' so we can do this in
C#... :-)

Dave

"Peter" <pskvarka@softinengines.com> wrote in message
news:%232wPf%23H7DHA.2576@TK2MSFTNGP11.phx.gbl...
> Question about C++ and NDIS
>
> Hi,
>
> I have some experiences with developing
> TDI,Protocol and Intermediate drivers.
>
> In all my drivers I have used C language.
> For me it is known some guidelines relating to writing
> kernel-mode drivers which I red in DDK doc.
> For example: Use ANSI C, dont use any standard C runtime library
> function that maintains state,....etc.
>
> My question is:
> What is wrong with C++ in kernel-mode ?
> I red some older articles in MSDN where are examples,
> where are defined new operator, delete operator with help of
> kernel-mode memory allocation etc.
>
> I heart something about:
> "Kernel can not process code compiled with C++ compiler normal way"
> but If it is true I dont understand why.
>
>
> What is wrong with C++ in Kernel mode ?
> Especially what is wrong with C++ in NDIS drivers ?
>
>
> Thanks !
> Peter
>
>
>

Maxim
Sun Feb 08 12:42:04 CST 2004

> I guess we'll all just have to wait for 'LongHorn' so we can do this in
> C#... :-)

Longhorn will allow .NET code in drivers? Really so?

--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim@storagecraft.com
http://www.storagecraft.com

Alexander
Sun Feb 08 14:56:29 CST 2004

With static_cast the compiler won't allow casts between unrelated types.
With C-cast, it will, and it will lead to errors..

"Maxim S. Shatskih" <maxim@storagecraft.com> wrote in message
news:OktfB1l7DHA.1596@TK2MSFTNGP10.phx.gbl...
> In the absense of multiple inheritance (which is a vast majority of
code),
> all these casts do the same. In this situation, C-style is the best -
lesser
> visual noise.
>
> --
> Maxim Shatskih, Windows DDK MVP
> StorageCraft Corporation
> maxim@storagecraft.com
> http://www.storagecraft.com
>
> "Alexander Grigoriev" <alegr@earthlink.net> wrote in message
> news:euirYxl7DHA.712@tk2msftngp13.phx.gbl...
> > C-style cast is not typesafe. In most cases one should use static_cast
> > instead.
> >
> > "Maxim S. Shatskih" <maxim@storagecraft.com> wrote in message
> > news:eFCXbef7DHA.1716@TK2MSFTNGP10.phx.gbl...
> > >
> > > Using <dynamic_cast> is wrong anyway, since there is the good old
C-style
> > cast
> > >