Pros n Cons of using Classes (CPP) at Kernel Level

Hi All,

I have used “class” many times to solve many design problems at user mode and
it worked very well for me in all cases.

So I am curious whether I can use “Class” design at Kernel level programming.

More specifically i want to use “CPP” at kernel mode.

Thanks

You can use a limited subset of C++ in the kernel. You will have to
determine, if that subset meets your needs, and if using C++ features are
worth it. Note most driver code is still C, even a lot of developers who
use the .CPP extension are coding in C but using the additional checks that
CPP applies by default. Each developer has to decide if using C++ features
provides enough advantages for their project, or whether sticking with C
makes more sense.

Don Burn
Windows Driver Consulting
Website: http://www.windrvr.com

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@gmail.com
Sent: Wednesday, October 12, 2016 8:22 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Pros n Cons of using Classes (CPP) at Kernel Level

Hi All,

I have used “class” many times to solve many design problems at user mode
and it worked very well for me in all cases.

So I am curious whether I can use “Class” design at Kernel level
programming.

More specifically i want to use “CPP” at kernel mode.

Thanks


NTDEV is sponsored by OSR

Visit the list online at:
http:

MONTHLY seminars on crash dump analysis, WDF, Windows internals and software
drivers!
Details at http:

To unsubscribe, visit the List Server section of OSR Online at
http:</http:></http:></http:>

Microsoft has made extensive use of C++ in kernel code, for example KMDF.
If it helps to solve your design problems, use it. Yes there are well
documented restrictions.

Mark Roddy

On Wed, Oct 12, 2016 at 8:39 AM, Don Burn wrote:

> You can use a limited subset of C++ in the kernel. You will have to
> determine, if that subset meets your needs, and if using C++ features are
> worth it. Note most driver code is still C, even a lot of developers who
> use the .CPP extension are coding in C but using the additional checks that
> CPP applies by default. Each developer has to decide if using C++
> features
> provides enough advantages for their project, or whether sticking with C
> makes more sense.
>
>
> Don Burn
> Windows Driver Consulting
> Website: http://www.windrvr.com
>
>
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of
> xxxxx@gmail.com
> Sent: Wednesday, October 12, 2016 8:22 AM
> To: Windows System Software Devs Interest List
> Subject: [ntdev] Pros n Cons of using Classes (CPP) at Kernel Level
>
> Hi All,
>
> I have used “class” many times to solve many design problems at user mode
> and it worked very well for me in all cases.
>
> So I am curious whether I can use “Class” design at Kernel level
> programming.
>
> More specifically i want to use “CPP” at kernel mode.
>
> Thanks
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list online at:
> http:
>
> MONTHLY seminars on crash dump analysis, WDF, Windows internals and
> software
> drivers!
> Details at http:
>
> To unsubscribe, visit the List Server section of OSR Online at
> http:
>
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list online at: http:> showlists.cfm?list=ntdev>
>
> MONTHLY seminars on crash dump analysis, WDF, Windows internals and
> software drivers!
> Details at http:
>
> To unsubscribe, visit the List Server section of OSR Online at <
> http://www.osronline.com/page.cfm?name=ListServer&gt;
></http:></http:></http:></http:></http:>

Hi All,

I was reading the book Writing Windows Device Drivers by Yashwant Kanetkar. In the sample examples the author provides there is a CString class which acts as a primitive wrapper over Unicode_String with overloaded ‘=’ operator and conversion constructor.

I was thinking that this implementation could be extended to encapsulate the memory management that the user has to do with Unicode_String and couple it with RAII so that user doesnt have to explicitly allocate or free memory. The class will take care of all these details (like std::string does).

I feel (and i may be wrong :D) that such implementation/library would greatly assist kernel development. The thing is i havent seen any such implementation in windows DDK samples.
Are there any performance impacts of using C++ in such a way?

Thanks

Per Mark’s previous comment, if anyone knows of some good “up to date” references of what you can/can’t do with C++ in kernel mode, please post here. Everything I’ve found thus far is years old (probably still valid though). Here’s the best I’ve found thus far:

https://blogs.msdn.microsoft.com/adioltean/2005/04/24/advanced-c-features-and-kernel-mode-programming-dont-mix/

http://www.osronline.com/article.cfm?article=490

http://www.osronline.com/article.cfm?article=57

https://view.officeapps.live.com/op/view.aspx?src=http://download.microsoft.com/download/5/b/5/5b5bec17-ea71-4653-9539-204a672f11cf/KMcode.doc



You can use a limited subset of C++ in the kernel. You will have to determine, if that subset meets your needs, and if using C++ features are worth it. Note most driver code is still C, even a lot of developers who use the .CPP extension are coding in C but using the additional checks that CPP applies by default. Each developer has to decide if using C++ features provides enough advantages for their project, or whether sticking with C makes more sense.

I just refuse to believe my own eyes - not so long ago you were speaking the following way
( the quotation is taken from the classic thread where Mr.Kyler made his “historic speech”).



Idiots who keep pushing C++ for all driver developers (yes I know some pro’s who use it well more power to them) including newbies who don’t know the trouble they can get it are as STUPID who are the solution to everything is HOOKING"

What happened, Don? What caused so dramatic change of opinion?

Anton Bassov

All of the code placement concerns (vtbl, code folding, templates) were addressed in the win8 wdk and vs2013 with the /kernel flag for the compiler and linker and new declspec usage. You don’t have native EH and RTTI.

Get Outlook for Androidhttps:

________________________________
From: xxxxx@lists.osr.com on behalf of xxxxx@sigovs.com
Sent: Wednesday, October 12, 2016 8:35:05 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Pros n Cons of using Classes (CPP) at Kernel Level

Per Mark’s previous comment, if anyone knows of some good “up to date” references of what you can/can’t do with C++ in kernel mode, please post here. Everything I’ve found thus far is years old (probably still valid though). Here’s the best I’ve found thus far:

https://blogs.msdn.microsoft.com/adioltean/2005/04/24/advanced-c-features-and-kernel-mode-programming-dont-mix/

http://www.osronline.com/article.cfm?article=490

http://www.osronline.com/article.cfm?article=57

https://view.officeapps.live.com/op/view.aspx?src=http://download.microsoft.com/download/5/b/5/5b5bec17-ea71-4653-9539-204a672f11cf/KMcode.doc


NTDEV is sponsored by OSR

Visit the list online at: http:

MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
Details at http:

To unsubscribe, visit the List Server section of OSR Online at http:</http:></http:></http:></https:>

Any examples of pageable classes? Or an example of a well supported class
with new overloaded to use the appropriate alloc methods? I’ve yet to see
anything that didn’t look like a hack. I compile as c++ and leverage auto,
anonymous namespaces, and the stricter typechecking, and that’s about it,
and compile with the /kernel flag. You can still accomplish oop in C.

On Wednesday, October 12, 2016, Doron Holan
wrote:

> All of the code placement concerns (vtbl, code folding, templates) were
> addressed in the win8 wdk and vs2013 with the /kernel flag for the compiler
> and linker and new declspec usage. You don’t have native EH and RTTI.
>
> Get Outlook for Android
> ------------------------------
> From: xxxxx@lists.osr.com > osr.com> on behalf of xxxxx@sigovs.com
> Sent: Wednesday, October 12, 2016 8:35:05 AM
> To: Windows System Software Devs Interest List
> Subject: RE:[ntdev] Pros n Cons of using Classes (CPP) at Kernel Level
>
> Per Mark’s previous comment, if anyone knows of some good “up to date”
> references of what you can/can’t do with C++ in kernel mode, please post
> here. Everything I’ve found thus far is years old (probably still valid
> though). Here’s the best I’ve found thus far:
>
> https://blogs.msdn.microsoft.com/adioltean/2005/04/24/
> advanced-c-features-and-kernel-mode-programming-dont-mix/
>
> http://www.osronline.com/article.cfm?article=490
>
> http://www.osronline.com/article.cfm?article=57
>
> https://view.officeapps.live.com/op/view.aspx?src=http://
> download.microsoft.com/download/5/b/5/5b5bec17-ea71-
> 4653-9539-204a672f11cf/KMcode.doc
>
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list online at: http:> showlists.cfm?list=ntdev>
>
> MONTHLY seminars on crash dump analysis, WDF, Windows internals and
> software drivers!
> Details at http:
>
> To unsubscribe, visit the List Server section of OSR Online at <
> http://www.osronline.com/page.cfm?name=ListServer&gt;
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list online at: http:
>
>
> MONTHLY seminars on crash dump analysis, WDF, Windows internals and
> software drivers!
> Details at http:
>
> To unsubscribe, visit the List Server section of OSR Online at <
> http://www.osronline.com/page.cfm?name=ListServer&gt;
></http:></http:></http:></http:>

My objections were when it was not officially supported by Microsoft, and
the compiler did not have support for C++ in the kernel. Before that
happened I had more than one bad experience of having to prove to clients
that C++ in the kernel was fragile (one case the code failed with a simple
reordering of functions in a file). I also found the claims of additional
checking to be questionable, if one enabled /W4 which was not the norm at
that time, and used PC-Lint to check the code.

I still don’t use it, because I have not seen a significant value
proposition in using the language. Years ago, I was in efforts on what
should be used in C++ in the kernel (both a Unix Systems Lab discussion as
well as a C++ standards committee discussion), and the results at the time
were keep it pretty limited. I know these old efforts impact my thinking,
but the real reason is I code for the future person who is going to maintain
the driver I deliver to a client. Given that almost all the recognized
samples are C not C++, I know that any competent driver developer will be
comfortable with my plain C, but I can’t be assured that with C++.

Don Burn
Windows Driver Consulting
Website: http://www.windrvr.com

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@hotmail.com
Sent: Wednesday, October 12, 2016 11:41 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Pros n Cons of using Classes (CPP) at Kernel Level



You can use a limited subset of C++ in the kernel. You will have to
determine, if that subset meets your needs, and if using C++ features are
worth it. Note most driver code is still C, even a lot of developers who use
the .CPP extension are coding in C but using the additional checks that CPP
applies by default. Each developer has to decide if using C++ features
provides enough advantages for their project, or whether sticking with C
makes more sense.



I just refuse to believe my own eyes - not so long ago you were speaking the
following way ( the quotation is taken from the classic thread where
Mr.Kyler made his “historic speech”).



Idiots who keep pushing C++ for all driver developers (yes I know some pro’s
who use it well more power to them) including newbies who don’t know the
trouble they can get it are as STUPID who are the solution to everything is
HOOKING"



What happened, Don? What caused so dramatic change of opinion?

Anton Bassov


NTDEV is sponsored by OSR

Visit the list online at:
http:

MONTHLY seminars on crash dump analysis, WDF, Windows internals and software
drivers!
Details at http:

To unsubscribe, visit the List Server section of OSR Online at
http:</http:></http:></http:>

xxxxx@gmail.com wrote:

I have used “class” many times to solve many design problems at user mode and
it worked very well for me in all cases.

So I am curious whether I can use “Class” design at Kernel level programming.

More specifically i want to use “CPP” at kernel mode.

Absolutely. Classes, inheritance, constructors and destructors have all
worked fine in the kernel clear back to the 20th Century. Templates
also worked if you were careful, but starting with the Windows 8 WDK
those are now reliable, too.

Just about the only C++ feature you can’t use in the kernel is
exceptions. And, unfortunately, that eliminates all of STL.


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

Anton, attempting to bait people on this thread really isn’t adding anything useful to the discussion.

Posters: Don’t feed the troll.

C vs C++, OOP vs Procedural Programming, whatever. It’s up to you. You can do good engineering using either language and either style. You can do terrible engineering in either one as well.

I *will* say it’s far easier to do hideous, unmaintainable, unsupportable, engineering in C++ than it is in C… This seems to be true just because of the languages’ inherent linguistics. Consider the effort involved in trying to figure out a super-shitty C program, versus the effort in figuring out a super-shitty C++ program. Terrible C++ can be darn close to undecipherable. Sadly, those who write super-shitty code probably don’t choose their languages based on how easy it is for others to understand, years later, the super-shitty code they’ve written (or they wouldn’t have written super-shitty code in the first place). But I digress.

Peter
OSR
@OSRDrivers

> Just about the only C++ feature you can’t use in the kernel is exceptions. And,

unfortunately, that eliminates all of STL.


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

Does RTTI work!?!

– Bob Ammerman
RAm Systems

Robert Ammerman wrote:

> Just about the only C++ feature you can’t use in the kernel is exceptions. And,
> unfortunately, that eliminates all of STL.
Does RTTI work!?!

No. That’s a feature that I rarely use, so I don’t particularly miss
it. I DO miss the STL.


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

If you are going to try to develop a C++ class library for the kernel, look
at what is out there already (such as the KMDF sources) and really
understand kernel programming. Also, try to get buy in from the kernel
development community so we don’t get to the bad old days of C++ (before the
standard’s specified libraries) where there were a large number of class
libraries. The problems of incompatible class libraries drove a number of
projects under.

Your example of UNICODE_STRING is probably not a great one. With proper
planning most drivers have little or no memory management code for
UNICODE_STRING’s and if they do many cases will not fit in RAII.

Don Burn
Windows Driver Consulting
Website: http://www.windrvr.com

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com
Sent: Wednesday, October 12, 2016 11:14 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Pros n Cons of using Classes (CPP) at Kernel Level

Hi All,

I was reading the book Writing Windows Device Drivers by Yashwant Kanetkar.
In the sample examples the author provides there is a CString class which
acts as a primitive wrapper over Unicode_String with overloaded ‘=’ operator
and conversion constructor.

I was thinking that this implementation could be extended to encapsulate
the memory management that the user has to do with Unicode_String and couple
it with RAII so that user doesnt have to explicitly allocate or free memory.
The class will take care of all these details (like std::string does).

I feel (and i may be wrong :D) that such implementation/library would
greatly assist kernel development. The thing is i havent seen any such
implementation in windows DDK samples.
Are there any performance impacts of using C++ in such a way?

Thanks


NTDEV is sponsored by OSR

Visit the list online at:
http:

MONTHLY seminars on crash dump analysis, WDF, Windows internals and software
drivers!
Details at http:

To unsubscribe, visit the List Server section of OSR Online at
http:</http:></http:></http:>

>Anton, attempting to bait people on this thread really isn’t adding anything useful to the discussion.

Sorry,Peter, just could not resist…

Concerning the usefulness…well,let’s see how it goes, but I don’t think that any C+±related thread on NTDEV may have any potential to evolve into anything particularly useful, in the first place. OTOH, it always has a good chance to evolve into something “exciting”, with lots of flaming and 'funny" statements. Therefore, I just tried to take a first step in this direction

BTW, the most interesting thing is that the above quotation is actually related to your practice of
renaming .c files into .cpp ones in order to ensure type safety that,unfortunately, is not a part of C language. Check this thread again. Enjoy the read…

Anton Bassov

This.

Well, at least, these days, “std::”

Peter
OSR
@OSRDrivers

On 10/12/16, 9:45 AM, “xxxxx@lists.osr.com on behalf of Robert Ammerman” wrote:

Does RTTI work!?!
-----------------------------------------------------

Things link dynamic_cast do not work, which is one of the uses of RTTI, as if the type is wrong you can’t just throw an exception.

You can EASILY add you own class metadata, like with virtual member functions for things like asString.

I think the hardest thing for people who use C++ in user mode, is NONE of the typical C++ class libraries are usable in kernel mode, you will have to roll you own or find C++ code that’s explicitly designed for kernel use.

I’ve written a ton of C++ kernel driver code over the years, and mostly I no longer do so. The primary reason is many kernel developers are not comfortable using C++. I got tired of having to convince team members and managers over and over, that C++ had lots of valuable capabilities. My experience also is the value of C++ is diminished if you only use a little, and it works best if almost everything in a driver is C++. Since there are no standard C++ kernel compatible libraries, you tend to have to do upfront framework development, before you start using the framework for your driver. Writing a framework + a single specific driver is not more production that just writing the single specific driver. On the other hand, if you had multiple complex driver products, taking the time to create the framework would likely give big gains in efficiently for the sum of the projects.

Another factor making kernel C++ hard is Linux. Often a driver will be needed on multiple platforms, and C++ might have advantages on Windows, but getting the Linux kernel team to accept your C++ containing driver into the mainline tree is difficult (impossible?).

I personally think C++ can improve the quality of kernel code. The way the compiler can optimize and inline inherited code is just vastly better than what you can do simulating OOP in C with function pointers. You can, using C++ syntax, teach the compiler a lot more about the semantic meaning of things, and the compiler than then automatically generate the correct to enforce that semantic meaning. For example, using scoping and constructors/destructors to create automatic reference counting. Once you taught the compile that some blob of bits is more than just an scalar value, but is a reference to something else, the compiler can do operations to make sure those references are always correct. That same reference counting class also can have a debug version which keeps a list of all references, which is incredibly useful during debugging. Another example, the kernel spinlock concept is easily turned into a class that acquires a spinlock on scope entry and releases it on scope exit.

A lot of people are critical of C++ because you can do things like override the assignment operator, but doing so is critical in teaching the compiler that an assignment is not just a memory copy, but is a change in the reference count to some other object, and if you just destroyed the last reference to an object, that object needs to be cleaned up or deleted. In C, you the programmer has to remember, and write code, every time you overwrite that reference. I personally much prefer to write the code once, and let the compiler insert that code every time it’s needed, which I can’t do in C.

On the downside, I feel C++ is a language created by a committee, and has a ton of really ugly constructs. I’m not really a fan of C++ specifically, but am a fan of getting languages to automatically keep us from doing silly things. Even though C++ has many ways to shoot your foot off, it also has ways to make your foot self-protecting. I’d love to see some new language (or implementation of a current language) that took the best of what we know about language design and used that to help solve the problems kernel developers have. For example, why as a kernel developer can’t I just declare an attribute on a pointer that means it points to pageable memory, and get the compiler to verify I never access that referenced memory in an inappropriate context. I’m not especially optimistic this will happen anytime soon, with issues like the above platform inertia problem a contributing factor.

I think the best hope at this point would be universities teach good computer science, including the area of computer languages, so in 30 years, new kernel developers would just be repulsed if they had to use a language that allowed them to accidentally corrupt memory. Today, the number of developers who are so entrenched as this being normal and acceptable is huge. It’s a bit like as a kid, the concept of wearing a helmet while riding a bicycle was non-existent, and today, it’s well know that your risk of serious injury is high is you don’t wear a helmet, and vast numbers of people do. It’s not that the risk of crashing a bike have changed, it’s that we learned better ways to prevent the nasty consequences.

I’m a former computer language implementer of exotic pure object oriented languages, and it’s really painful to see problems not being solved, that we know how to solve. I suspect the crisis in security issues may force things to evolve. For a while, Windows was getting blamed for being much less secure, but then we had really major security vulneraries in some open source and Linux projects, which I think was a wakeup call that Windows was not the problem, the C language was.

Don’t get me started about computer languages…

Jan

All good stuff here, mind if I take us on an academic exercise? The author
wanted to know if class design was possible in the kernel. Keeping things
very basic here, is this an acceptable usage of class design in the kernel?
What other operator new / delete (I know I missed new and delete)
prototypes should be implemented, and are these correct? Should or can we
leverage the crt/new.h? I’ve also yet to see a microsoft reference driver
example in their github that uses c++ classes. I might only want to use
classes to improve doxygen documentation :wink:

#include <ntddk.h>

void * __cdecl operator new(size_t size) {
return ExAllocatePoolWithTag(NonPagedPool, size, ‘sslC’);
}

void__cdecl operator delete(void * object) {
ExFreePoolWithTag(object, ‘sslC’);
}

// placement new
void * __cdecl operator new(size_t size, void * place) {
return place;
}

// placement delete
void__cdecl operator delete(void *, void *) {
return;
}

#ifdef _KERNEL_MODE
#define NONPAGESECTION __declspec(code_seg(“$kerneltext$”))
#else
#define NONPAGESECTION
#endif

class NONPAGESECTION TestClass {
public:
explicit TestClass() { };
~TestClass() {};

NTSTATUS Setup(
In PDRIVER_OBJECT pDriverObject,
In PUNICODE_STRING pUniRegistryPath)
{
UNREFERENCED_PARAMETER(pDriverObject);
UNREFERENCED_PARAMETER(pUniRegistryPath);
return STATUS_SUCCESS;
}

VOID Teardown() { };

private:
// member objects here, paged or nonpaged, can we page anything?
}

NTSTATUS DriverEntry(
In PDRIVER_OBJECT pDriverObject,
In PUNICODE_STRING pUniRegistryPath)
{
auto testClass = new TestClass();
if (!testClass) {
return STATUS_INSUFFICIENT_RESOURCES;
}

auto ntStatus = testClass->Setup();
if (NT_SUCCESS(ntStatus)) {
testClass->Teardown();
delete testClass;
}

return ntStatus;
}

On Wed, Oct 12, 2016 at 4:30 PM, Jan Bottorff
wrote:

> On 10/12/16, 9:45 AM, “xxxxx@lists.osr.com on behalf of
> Robert Ammerman” > xxxxx@ramsystems.biz> wrote:
>
> Does RTTI work!?!
> -----------------------------------------------------
>
> Things link dynamic_cast do not work, which is one of the uses of RTTI, as
> if the type is wrong you can’t just throw an exception.
>
> You can EASILY add you own class metadata, like with virtual member
> functions for things like asString.
>
> I think the hardest thing for people who use C++ in user mode, is NONE of
> the typical C++ class libraries are usable in kernel mode, you will have to
> roll you own or find C++ code that’s explicitly designed for kernel use.
>
> I’ve written a ton of C++ kernel driver code over the years, and mostly I
> no longer do so. The primary reason is many kernel developers are not
> comfortable using C++. I got tired of having to convince team members and
> managers over and over, that C++ had lots of valuable capabilities. My
> experience also is the value of C++ is diminished if you only use a little,
> and it works best if almost everything in a driver is C++. Since there are
> no standard C++ kernel compatible libraries, you tend to have to do upfront
> framework development, before you start using the framework for your
> driver. Writing a framework + a single specific driver is not more
> production that just writing the single specific driver. On the other hand,
> if you had multiple complex driver products, taking the time to create the
> framework would likely give big gains in efficiently for the sum of the
> projects.
>
> Another factor making kernel C++ hard is Linux. Often a driver will be
> needed on multiple platforms, and C++ might have advantages on Windows, but
> getting the Linux kernel team to accept your C++ containing driver into the
> mainline tree is difficult (impossible?).
>
> I personally think C++ can improve the quality of kernel code. The way the
> compiler can optimize and inline inherited code is just vastly better than
> what you can do simulating OOP in C with function pointers. You can, using
> C++ syntax, teach the compiler a lot more about the semantic meaning of
> things, and the compiler than then automatically generate the correct to
> enforce that semantic meaning. For example, using scoping and
> constructors/destructors to create automatic reference counting. Once you
> taught the compile that some blob of bits is more than just an scalar
> value, but is a reference to something else, the compiler can do operations
> to make sure those references are always correct. That same reference
> counting class also can have a debug version which keeps a list of all
> references, which is incredibly useful during debugging. Another example,
> the kernel spinlock concept is easily turned into a class that acquires a
> spinlock on scope entry and releases it on scope exit.
>
> A lot of people are critical of C++ because you can do things like
> override the assignment operator, but doing so is critical in teaching the
> compiler that an assignment is not just a memory copy, but is a change in
> the reference count to some other object, and if you just destroyed the
> last reference to an object, that object needs to be cleaned up or deleted.
> In C, you the programmer has to remember, and write code, every time you
> overwrite that reference. I personally much prefer to write the code once,
> and let the compiler insert that code every time it’s needed, which I can’t
> do in C.
>
> On the downside, I feel C++ is a language created by a committee, and has
> a ton of really ugly constructs. I’m not really a fan of C++ specifically,
> but am a fan of getting languages to automatically keep us from doing silly
> things. Even though C++ has many ways to shoot your foot off, it also has
> ways to make your foot self-protecting. I’d love to see some new language
> (or implementation of a current language) that took the best of what we
> know about language design and used that to help solve the problems kernel
> developers have. For example, why as a kernel developer can’t I just
> declare an attribute on a pointer that means it points to pageable memory,
> and get the compiler to verify I never access that referenced memory in an
> inappropriate context. I’m not especially optimistic this will happen
> anytime soon, with issues like the above platform inertia problem a
> contributing factor.
>
> I think the best hope at this point would be universities teach good
> computer science, including the area of computer languages, so in 30 years,
> new kernel developers would just be repulsed if they had to use a language
> that allowed them to accidentally corrupt memory. Today, the number of
> developers who are so entrenched as this being normal and acceptable is
> huge. It’s a bit like as a kid, the concept of wearing a helmet while
> riding a bicycle was non-existent, and today, it’s well know that your risk
> of serious injury is high is you don’t wear a helmet, and vast numbers of
> people do. It’s not that the risk of crashing a bike have changed, it’s
> that we learned better ways to prevent the nasty consequences.
>
> I’m a former computer language implementer of exotic pure object oriented
> languages, and it’s really painful to see problems not being solved, that
> we know how to solve. I suspect the crisis in security issues may force
> things to evolve. For a while, Windows was getting blamed for being much
> less secure, but then we had really major security vulneraries in some open
> source and Linux projects, which I think was a wakeup call that Windows was
> not the problem, the C language was.
>
> Don’t get me started about computer languages…
>
> Jan
>
>
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list online at: http:> showlists.cfm?list=ntdev>
>
> MONTHLY seminars on crash dump analysis, WDF, Windows internals and
> software drivers!
> Details at http:
>
> To unsubscribe, visit the List Server section of OSR Online at <
> http://www.osronline.com/page.cfm?name=ListServer&gt;
></http:></http:></ntddk.h>

> -----Original Message-----

From: xxxxx@lists.osr.com [mailto:bounce-617607-
xxxxx@lists.osr.com] On Behalf Of Jan Bottorff
Sent: Wednesday, October 12, 2016 2:31 PM
To: Windows System Software Devs Interest List
> Subject: Re: [ntdev] Pros n Cons of using Classes (CPP) at Kernel Level
>
> On 10/12/16, 9:45 AM, “xxxxx@lists.osr.com on behalf of
> Robert Ammerman” > xxxxx@ramsystems.biz> wrote:
>
> Does RTTI work!?!
> -----------------------------------------------------
>
> Things link dynamic_cast do not work, which is one of the uses of RTTI, as
> if the type is wrong you can’t just throw an exception.

dynamic_cast<> will only throw if you give it a pointer to something that isn’t a valid object. If your input is a valid object pointer, but not the type you asked it for, it returns NULL. Reference types are a different beast. You should only be doing a dynamic_cast you expect to succeed, because you do get a bad_cast exception if it isn’t a reference to the desired type of object.

@Phil:

dynamic_cast<> for a pointer doesn’t throw. Only a dynamic_cast for a reference will throw.