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

NTDEV
21

Jesse Conn wrote:

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?

There is a kernel implementation of operator new and delete in <kcom.h>
in the WDK, including array and placement new. It allows you to specify
the pool specifically. I always borrow those.

> I’ve also yet to see a microsoft reference driver example in their
> github that uses c++ classes.

Really? The AVStream, BDA and audio samples have been in C++ for more
than 15 years. Not sure how you could have missed them.

> 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?
> }

You can’t separate members into different pages. The entire object will
live in whatever pool you specify when you allocate it.

In general, I have found the most useful way to exploit classes is to
have most of my functionality be methods off of a context structure –
driver context, device context, file context, request context, etc.
That way, WDM or KMDF does the actual allocation, and I only have to do
a placement new to have the constructor run after the context exists.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.</kcom.h>

22

This is exactly the problem with C++. It is not that you cant do good things with it, but rather that it is possible to do incomprehensible things. When one spends the amount of time I do reviewing code written by others, the sheer number of things that have to be checked because the language allows them (even if none but the most brain dead programmer would do that) makes programming in C++ less efficient than in C in my experience. Remember all the bad things you can do in C, you can also do in C++ (misuse of macros, bit fields, control flow issues etc.), but C++ introduces a whole new set of sins (operator overloading, property accessors with side effects, and worse). Contrast this with C# (my second most used language behind C and ahead of TSQL) where interfaces replace the abomination that is multiple inherence and non-trivial macros don?t exist. Too bad that the non-deterministic nature of garbage collection precludes its use in areas that require forward progress guarantees ? but don?t worry our universities are far to busy looking into the merits of quantum computing to have any time to teach such mundane things like the properties of computer languages and how it might be possible to improve them given that we are no longer constrained by the need for compilers to run in 64k of RAM on 16 MHz CPUs

but hey, that?s just me and my one and only post on this subject

Sent from Mailhttps: for Windows 10

From: xxxxx@osr.commailto:xxxxx
Sent: October 12, 2016 12:45 PM
To: Windows System Software Devs Interest Listmailto:xxxxx
Subject: RE:[ntdev] Pros n Cons of using Classes (CPP) at Kernel Level



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

—
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:></mailto:xxxxx></mailto:xxxxx></https:>

23

>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?).

Cross-platform drivers? I’ve never heard about anything like that. Up to this point, I firmly believed that every OS has its own kernel API and driver model that are typically unique and very different from their counterparts under any other OS.Probably, I just missed some “new developments”
If you don’t mind,could you please enlighten me a bit on this “exciting” subject.

Concerning Linux kernel and C++, I suggest checking the link below.

http://lwn.net/Articles/249460/

When it comes to hating C++, I guess our host may take a course from Linus…

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.

Oh dear…

We’ve been here so many times that any argument/counter-argument in this respect seems to be
totally unnecessary - everything that may possibly be said here seems to have been said already at some point on NTDEV I guess the next topic that this thread may jump to is microkernel.
All this is so predictable…

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.

Windows vs Linux is yet another topic that such a thread may jump to - this is, again, so predictable.

I guess the only good thing that such a thread may evolve to is becoming sort of “funny”.I tried to steer it in this direction but, unfortunately, got shot down by “The Hanging Judge” even before having had a chance to take off…

Anton Bassov

24

Anton,

There was an effort 20 years ago to make a cross platform driver for
all versions of UNIX at the time. It was a disaster, since even on that
platform things varied so much (worst case was one platform that did not
support multiple threads in one driver), that it was given up on.

On the idea of cross platform drivers for Linux and Windows, I’ve
worked with clients who tried it. It can work ok for a kernel library
which has little interaction with the OS or hardware (a good example was a
state machine for a communications protocol), but for general drivers
anything but the simplest driver for simple slow speed hardware typically is
a bad idea. I’ve seen clients who started with either Linux or Windows
drivers and tried to make them cross platform, they quickly complain about
how terrible the second OS is, when in fact it is the attempt to limit the
capabilities of the driver to a subset of the target platforms.

I’ve taken a number of Linux drivers for custom devices as
reference, and I quickly find that the only things useable, are the hardware
interactions for a given request, and the requests themselves (with the
large caveat that the differences between the OS’es can make taking the
request model from Linux a bad idea). Both operating systems are good
OS’es, but they came from significantly different architectures, and if you
do not respect the architecture, you are not going to get a good driver.

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 10:51 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Pros n Cons of using Classes (CPP) at Kernel Level

>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?).

Cross-platform drivers? I’ve never heard about anything like that. Up to
this point, I firmly believed that every OS has its own kernel API and
driver model that are typically unique and very different from their
counterparts under any other OS.Probably, I just missed some “new
developments”
If you don’t mind,could you please enlighten me a bit on this “exciting”
subject.

Concerning Linux kernel and C++, I suggest checking the link below.

http://lwn.net/Articles/249460/

When it comes to hating C++, I guess our host may take a course from
Linus…

> 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.

Oh dear…

We’ve been here so many times that any argument/counter-argument in this
respect seems to be totally unnecessary - everything that may possibly be
said here seems to have been said already at some point on NTDEV I guess the
next topic that this thread may jump to is microkernel.
All this is so predictable…

> 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.

Windows vs Linux is yet another topic that such a thread may jump to - this
is, again, so predictable.

I guess the only good thing that such a thread may evolve to is becoming
sort of “funny”.I tried to steer it in this direction but, unfortunately,
got shot down by “The Hanging Judge” even before having had a chance to take
off…

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:>

25

True story:

10 years ago, I was part of a team that did a very high-performance cross-platform driver stack for a number of ATA/SCSI/SAS disk HBAs. Though this was a set of drivers for HBAs, we didn’t expose the HBA/Disk abstraction to the OS, which made the task significantly easier. Our device abstraction was unknown to any OS, so there was no pre-existing data contract we had to support.

We abstracted the OS into a layer hidden behind an interface. Stuff like memory allocation, sync primitives, that sort of thing. We abstracted the hardware control logic hidden behind a different interface. Both of those layers could use the common core glue logic through another interface, and the common core did as much of the IO processing as we could hoist into it. We made it impossible to *accidentally* cross those boundaries. We actively discouraged each other from intentionally crossing them.

The request model looked very much like WDF. The Linux shim wasn’t too hard to do.

The result:
Windows/Linux/DOS (in that order) support for 8-10 (don’t remember exactly) HBAs. Still in use today, though I don’t know which platforms are still active. It was capable of keeping disk read channels saturated indefinitely.

Some of my best driver work, ever. The basic interface across UM/KM boundary was pretty good, as well. Sadly, some parts of the UM interface I put on top of all that makes me cringe to remember, even a decade later.

Phil

Not speaking for LogRhythm
Phil Barila | Senior Software Engineer
720.881.5364 (w)

A LEADER in Gartner’s SIEM Magic Quadrant (2012-2016)
Highest Score in Gartner’s 2015 SIEM Critical Capabilities Report
A CHAMPION in Info-Tech Research Group’s 2015 SIEM Vendor Landscape Report
SC Labs RECOMMENDED in 2016 SIEM and UTM Group Test | 5-Star Rating (2009-2016)

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:bounce-617673-
xxxxx@lists.osr.com] On Behalf Of Don Burn
Sent: Thursday, October 13, 2016 6:55 AM
To: Windows System Software Devs Interest List
> Subject: RE: [ntdev] Pros n Cons of using Classes (CPP) at Kernel Level
>
> Anton,
>
> There was an effort 20 years ago to make a cross platform driver
> for all versions of UNIX at the time. It was a disaster, since even on
> that platform things varied so much (worst case was one platform that did
> not support multiple threads in one driver), that it was given up on.
>
> On the idea of cross platform drivers for Linux and Windows, I’ve
> worked with clients who tried it. It can work ok for a kernel library
> which has little interaction with the OS or hardware (a good example was a
> state machine for a communications protocol), but for general drivers
> anything but the simplest driver for simple slow speed hardware typically
> is a bad idea. I’ve seen clients who started with either Linux or Windows
> drivers and tried to make them cross platform, they quickly complain about
> how terrible the second OS is, when in fact it is the attempt to limit the
> capabilities of the driver to a subset of the target platforms.
>
> I’ve taken a number of Linux drivers for custom devices as
> reference, and I quickly find that the only things useable, are the
> hardware interactions for a given request, and the requests themselves
> (with the large caveat that the differences between the OS’es can make
> taking the
> request model from Linux a bad idea). Both operating systems are good
> OS’es, but they came from significantly different architectures, and if
> you do not respect the architecture, you are not going to get a good
> driver.
>
>
> 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 10:51 PM
> To: Windows System Software Devs Interest List
> Subject: RE:[ntdev] Pros n Cons of using Classes (CPP) at Kernel Level
>
> >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?).
>
> Cross-platform drivers? I’ve never heard about anything like that. Up to
> this point, I firmly believed that every OS has its own kernel API and
> driver model that are typically unique and very different from their
> counterparts under any other OS.Probably, I just missed some “new
> developments”
> If you don’t mind,could you please enlighten me a bit on this “exciting”
> subject.
>
>
> Concerning Linux kernel and C++, I suggest checking the link below.
>
> http://lwn.net/Articles/249460/
>
>
> When it comes to hating C++, I guess our host may take a course from
> Linus…
>
>
>
> > 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.
>
> Oh dear…
>
> We’ve been here so many times that any argument/counter-argument in this
> respect seems to be totally unnecessary - everything that may possibly be
> said here seems to have been said already at some point on NTDEV I guess
> the next topic that this thread may jump to is microkernel.
> All this is so predictable…
>
>
> > 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.
>
>
> Windows vs Linux is yet another topic that such a thread may jump to -
> this is, again, so predictable.
>
>
>
> I guess the only good thing that such a thread may evolve to is becoming
> sort of “funny”.I tried to steer it in this direction but, unfortunately,
> got shot down by “The Hanging Judge” even before having had a chance to
> take off…
>
>
> 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:
>
>
> —
> 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:></http:></http:></http:>

26

Don,

Well, what one THEORETICALLY may do here is to try doing it in more or less miniport-like fashion. For example, you can write an OS-specific driver library that encapsulates all interactions between hardware-specific driver and the OS, and make it expose,on a lower edge, an interface that your hardware-specific driver may call to and another one that it has to implement, effectively making a driver part that actually deals with the hardware OS-agnostic. For the sake of clarity you may want even to put these two parts in separate kernel modules, effectively ending up with driver-library relationship that is reminiscent of the one between, say, NDIS miniport driver and NDIS library.

The most obvious potential issues here are

  1. It is much more difficult for you to take the full advantage of the functionality that your target hardware offers, because you have to find a common denominator between the OS models that are very different from one another

2.The amount of work that such a project involves may well exceed the one required for writing separate drivers for each OS.

However, in some rare cases the above mentioned model may, indeed, have an advantage. For example,consider the scenario when you have to write drivers for multiple hardware devices.

In this case a clear separation between the OS-specific and OS-agnostic parts may save you quite a bit of time, especially taking into consideration that the more code you write the higher probability of introducing bugs you have.

Anton Bassov

27

AND

OMG. Do you two actually AGREE on something?

(These "writing drivers in C++ threads are really the best, aren’t they? And to think somebody OTHER THAN ME even brought-up writing code in C#!)

Peter
OSR
@OSRDrivers

28

>OMG. Do you two actually AGREE on something?

Apparently, yes…

It happens sometimes. For example, if you check the link that I have provided you will see that you and Linus actually agree on something as well. For example, what about the following excerpt

Sounds familiar,don’t you think. Concerning the particular way the actual idea had been expressed, the above quotation seems(at least to me) to be stylistically similar to the one that some NTDEV posters express their thoughts as well, especially if you enhance it by means of CAPS_LOCK key.

In other words, we are not all that different from one another…

And to think somebody OTHER THAN ME even brought-up writing code in C#!

Well, assuming that we are speaking about a driver for TTY or some other character device that produces data at a rate of 8-16 bytes per minute,why not…

Anton Bassov

29

This would be the second project I’ve started with C++ and reverted back to
C, as I’ve abandoned all silliness of using C++ for the very limited,
ultimately useless, feature subset I found that worked for me. At the end
of the day, I was just writing C.

As soon as I started running up against all of the framework methods that
take callbacks with no context, I knew I had just overly complicated this
for no gain.

I had tried to use c++ due to what appeared to be more recent documentation
on what the Visual Studio compiler supported.

Anyone have a reference to the full specifications of what standard and
options the VS C compiler implements or adheres to?

Thanks again for bringing me back to a place of peace. I may attempt to use
C++ again in the future, but only for a library that has no dependencies on
API calls that were not written with C++ in mind.

On Friday, October 14, 2016, wrote:

> >OMG. Do you two actually AGREE on something?
>
> Apparently, yes…
>
> It happens sometimes. For example, if you check the link that I have
> provided you will see that you and Linus actually agree on something as
> well. For example, what about the following excerpt
>
>


>
>
> Sounds familiar,don’t you think. Concerning the particular way the actual
> idea had been expressed, the above quotation seems(at least to me) to be
> stylistically similar to the one that some NTDEV posters express their
> thoughts as well, especially if you enhance it by means of CAPS_LOCK key.
>
>
> In other words, we are not all that different from one another…
>
>
> > And to think somebody OTHER THAN ME even brought-up writing code in C#!
>
> Well, assuming that we are speaking about a driver for TTY or some other
> character device that produces data at a rate of 8-16 bytes per minute,why
> not…
>
>
> Anton Bassov
>
>
>
>
> —
> 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:>

30

Mr. Penguin Pants speaks the truth… about something.

There’s an English language saying that applies here:

“Even a blind squirrel occasionally finds a nut.”

31

> Mr. Penguin Pants speaks the truth… about something.

Actually, I am more impressed by the style, particularly by “substandard programmers”, “total and utter crap” and “keeping C++ programmers out”. I don’t know why, but for some reason the above quotation brings up certain associations (at least in my mind) with the following one

Don’t you find these two stylistically similar???

Anton Bassov

32

For people commenting on the language, I strongly recommend you read “The
Design and Evolution of C++” by Stroustrup. It explains all the
compromises he went through to create the language. The only problem with
the book is it is old enough to be before the standard committee took a
compromised language and mangled it further. It is obvious as you read
the book that decision to be “C” compatible is the biggest weakness of the
language design, even though it probably made the language so popular.

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: Sunday, October 16, 2016 6:14 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Pros n Cons of using Classes (CPP) at Kernel Level

> Mr. Penguin Pants speaks the truth… about something.

Actually, I am more impressed by the style, particularly by “substandard
programmers”, “total and utter crap” and “keeping C++ programmers out”. I
don’t know why, but for some reason the above quotation brings up certain
associations (at least in my mind) with the following one



Don’t you find these two stylistically similar???

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:>

33

> It is obvious as you read the book that decision to be “C” compatible is the biggest

weakness of the language design,

It reminds me of an old book by some “C++ freak” (I think it is named along the lines of “C++ for Real Programmers”) where the author claims that the biggest problem is that people learn C first and C++ next, rather than the other way around. As a result, they don’t take advantage of
“wonderful” features( like templates,operator overload, class hierarchies based upon multiple inheritance, etc), and, instead, bring old C-style habits (like use of pointer arithmetic and “notoriously unsafe C-style type cast”) into this "beautiful " language.

Furthermore, he claims that one can think of C++ not just as of a language per se but as of a tool of language design as well, because it allows one to write code that seems to rely upon some syntax other than “conventional” C++ one (which is,indeed, true). What I find amazing is his firm belief that such a “functionality” is a tremendous advantage of a computer language, rather than its serious shortcoming that makes its use problematic (at least in a production environment).

Anyway, concerning the “tool of language design”…well, if you need the one Lisp seems to be even more suitable in this respect, don’t you think…

Anton Bassov

34

Anton,

Stroustrup defends why he choose to be “C” compatible, but then
turns around and points out all the ugly compromises that the language had
to do to be compatible. It is actually an excellent book on the tradeoffs
in language design, but as you read it you really wonder if he made the
right decisions.

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: Sunday, October 16, 2016 8:17 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Pros n Cons of using Classes (CPP) at Kernel Level

> It is obvious as you read the book that decision to be “C” compatible
> is the biggest weakness of the language design,

It reminds me of an old book by some “C++ freak” (I think it is named along
the lines of “C++ for Real Programmers”) where the author claims that the
biggest problem is that people learn C first and C++ next, rather than the
other way around. As a result, they don’t take advantage of “wonderful”
features( like templates,operator overload, class hierarchies based upon
multiple inheritance, etc), and, instead, bring old C-style habits (like use
of pointer arithmetic and “notoriously unsafe C-style type cast”) into this
"beautiful " language.

Furthermore, he claims that one can think of C++ not just as of a language
per se but as of a tool of language design as well, because it allows one to
write code that seems to rely upon some syntax other than “conventional” C++
one (which is,indeed, true). What I find amazing is his firm belief that
such a “functionality” is a tremendous advantage of a computer language,
rather than its serious shortcoming that makes its use problematic (at least
in a production environment).

Anyway, concerning the “tool of language design”…well, if you need the
one Lisp seems to be even more suitable in this respect, don’t you
think…

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:>

35

OF COURSE he didn’t make the right decisions. Because it is plainly evident to a casual observer test the language sucks in so many fundamental ways. This becomes very clear to anybody who spends 10 minutes writing in C#… sooooo very much cleaner, more modern, pretty much like C, and just as OO.

Having said that, there are some nice features in modern C++ … and it’s hard to argue that the stuff that’s provided by the std:: standrd template library isn’t terrific. Ever use the std::thread stuff? It’s so cool and easy to use I could barely believed it.

Peter
OSR
@OSRDrivers

36

On Oct 16, 2016, at 8:04 PM, xxxxx@osr.com wrote:

Having said that, there are some nice features in modern C++ … and it’s hard to argue that the stuff that’s provided by the std:: standrd template library isn’t terrific. Ever use the std::thread stuff? It’s so cool and easy to use I could barely believed it.

There is an enormous amount of stuff in the standard library now. Not only threads, but muteness, condition variables, standard hi-resolution timing, atomic variables, and more. It’s now quite possible to write genuinely useful, sophisticated applications in fully standard C++, without delving into operating system specific APIs.

Languages are not really that important. It is the standard libraries that make programming interesting and fun. It’s the reason I love Python, and these days what I had been doing in Python, I’m now doing in C++.
—
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

37

> OF COURSE he didn’t make the right decisions. Because it is plainly evident to a casual

observer test the language sucks in so many fundamental ways.

BTW, you may want to visit the following link

http://golibgen.io/view.php?id=251805

A title like “A critique of C++” seems to be speaking for itself, don’t you think…

This becomes very clear to anybody who spends 10 minutes writing in C#



And what about Java? How come that you don’t praise Java, especially if we take into account that
C# happens to be just a MSFT implementation of Java with some additional functional features like lambda expressions and delegates? Certainly you can say that you are particularly impressed by above mentioned functional features that make C# superior to Java. If you do, you will just give me an extra task of finding a thread where you express your opinion on purely functional languages and say “F# is a complete nightmare. It is worse than Haskell”…

Anton Bassov

38

So very true. Take the CLR away from C#. It would make me sad.

Because I have no knowledge of Java. Never used it. Never even seen it used on anything I’ve been involved with.

Peter
OSR
@OSRDrivers

39

I will respectfully disagree with this point. It may certainly make a language fun to use to have extensive default library support. And for many projects the productivity that can be achieved can be directly tied to the ability to intuitively (for some group of programmers) use (correctly) those features, but all of the things that contribute to buggy code (including impossibly complex or unreadable code) have little to do with that. The basic lexical conventions of the language itself, as well as its governing parameters dictate how easy of difficult it will be to create garbage. Good programmers who understand the paradigm of any language will write good code in that language ? its fitness for a purpose notwithstanding. Bad programmers will write poor code in any language whether they understand its paradigm or not. Good programmers who don?t understand the paradigm of a language may or may not write good code in a given language; and in my this is the category that really counts when considering the merits of using one language over another for a particular problem assuming that they both have adequate fitness for the purpose. C and C++ are both fit for the purpose of Windows KM development ? unlike C#, TSQL, lisp or pearl for example. Those other languages can be more fit for other purposes, but as this form is all about Windows KM I digress.

Sent from Mailhttps: for Windows 10

From: xxxxx@osr.commailto:xxxxx
Sent: October 17, 2016 2:07 PM
To: Windows System Software Devs Interest Listmailto:xxxxx
Subject: RE:[ntdev] Pros n Cons of using Classes (CPP) at Kernel Level



So very true. Take the CLR away from C#. It would make me sad.



Because I have no knowledge of Java. Never used it. Never even seen it used on anything I’ve been involved with.

Peter
OSR
@OSRDrivers

—
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:></mailto:xxxxx></mailto:xxxxx></https:>

40

I agreed with everything you wrote RIGHT up to this point.

TL;DR –> If there were more new, cutting-edge, OS work being done, it’d move the state of the art on to using better languages… where it’s not possible to do stupid stuff like use after free or overrun buffers. But that work’s not being done, so we’re stuck in the 20th century using a hideously outdated language like C/C++ for KM work. Oh well, whatever, never mind.

Long version:

I’ve argued this before. I would say that C and C++ are particularly BADLY fit for KM development in the 21st century. Inherent support for buffer overruns, memory leaks, use after free, bad pointer references… all make for a language that is PARTICULARLY poorly suited to KM use in the modern era. Why on EARTH is it possible to index past the end of an allocated array without being told? This is just one example of a language construct that is NOT reasonable in the 21st century.

I used to write drivers in assembler language. I was very good at it. But it was time-consuming and *unnecessarily* difficult once compilers became clever enough to efficiently translate their higher-level constructs into machine language. Because there was lots of OS work going on, it became possible for different projects to “try out” different languages and move the majority of work to higher level languages.

We’re at the point now where it’s no longer necessary to write KM code in ancient, bug prone, languages… where the most rudimentary errors can linger undetected and cause problems. But there’s not enough new OS development work happening to facilitate the movement of OS work to new languages. You’ve got a huge body of existing work, enormous vested interests with giant installed user bases, and no impetus to change. So… we’re stuck with C. Or C++.

C/C++ is not better, it’s ancient. But this is a sort of ancient field.

Peter
OSR
@OSRDrivers