Re: c++ in windows kernel mode
On Jul 31, 11:19 am, yaa...@gmail.com wrote:
{ As far as possible, please try to confine this discussion to general
system-independent issues. We recognize that at this level some details
cannot be discussed without concrete system-dependent examples. -mod }
here's an interesting article pointing out the fatal pitfalls
of c++ in kernel mode:
http://www.microsoft.com/whdc/driver/kernel/KMcode.mspx
Please criticize or suggest workarounds, if any.
Also,are there options/switches that help these problems mentioned?
have there been improvements in generated code since this article was
written?
I'v experienced 1st-hand what it was like to (try to) write a Kernel
Mode driver in C++, under Windows. It was an NDIS (Network Device
Interface Specification) driver meant to support a new kind of network
protocol stack.
As one can imagine, the environment in which the driver is expected to
run is differen between the two modes, and being somewhat stubborn, I
was determined to see how far one could get away with using C++ in
kernel model.
By far, the biggest slap in the face is memory management. It simply
is not possible to use new/delete willy-nilly as one would in user
mode. One has to remain cognizant of what type of memory should be
used at which point. Of course, anyone embarking upon a driver project
already knows this, so the question is, "How much pain should the
programmer expect from not being able to remain ignorant of memory
management context?" The anser is: A LOT. I fiddled,
faddled...nothing work. My entire user-mode C++ library was
essentially useless. However, if you carefully design the constructor/
destructor pairs of kernel-mode classes to use the special kernel-mode
memory management function, you might get some relief.
Then there are issues with floating point. As pointed out in the
article, one cannot simply write:
float two = 1.0 + 1.0; // Makes kernel very angry.
Though I had no need for them in my driver, I would expect virtual
functions to work.
I would expect templates to pose no problems.
Exception handling was another major headache. As one can imagine,
simply providing a "library" to support exception handling is *not*
sufficient. One has to think about what happens when stack is
completely unwound.
Global static objects were another issue. Have to be careful here and
make sure whatever compiler you are using, does what you expect. You
should also make sure that you do not do any heavy-lifting in
contsructor of a global object. This was true in user-mode in some
cases, but can be fatal in kernel-mode.
In spite of all of this, my kernel-mode files still end in .cpp,
not .c. Why? I like declaring my variables just before the point
where I intend to use them. :)
-Le Chaud Lapin-
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]