Placement new operator in a driver

Tim_Roberts · April 25, 2006, 8:18pm

Mark Roddy wrote:

Because I am simply not convinced that this issue is an overwheming
obstacle, and other than this issue there is no rational argument for not
using C++.

By the way, several Microsoft kernel components are developed using C++, for
example KMDF.

…and, of course, all of AVStream and BDA, a not insignificant pile of
code.

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

Doron_Holan · April 25, 2006, 10:03pm

Because no matter what we have told people in the past, they still use
C++. So, as a minor stopgap c++ is acceptable. C# is much better next
gen language, but there are a lot more issues to resolve then C++ has
(different issues). Not bad issues, just different

d

– I can spell, I just can’t type.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Pavel A.
Sent: Tuesday, April 25, 2006 5:20 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Placement new operator in a driver

“Mark Roddy” wrote in message news:xxxxx@ntdev…
> Any progress convincing the compiler folks to fix this problem?

Well why not just admit that C++ is not a good language for kernel mode?

C has been designed as lower lever, closer to machine semantics
language.
C++ has been designed for usermode. The “better C” approach did not work
for many reasons mentioned in this thread, especially by Don Burn.
The Embedded C++ project failed.
Do you see much C++ in Linux kernel? nope.
It’s time for conclusions… C++ just doesn’t have it.
Maybe C# will be the next “better C”.

Regards,
–PA

—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

Maxim_S_Shatskih · April 26, 2006, 6:28am

> > You cannot sleep under a spinlock, forget this.

Who are you speaking to? Who is sleeping under a spinlock?

The Sleeping Beauty I think

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

Maxim_S_Shatskih · April 26, 2006, 7:22am

> So how did you reach this conclusion? Was it because you tried C++ and

failed? Or because you heard that someone tried C++ and failed too? May I

I worked in C++ in 93-99. User-mode Windows, MFC, ATL, COM and database work. I
passed the exam on C++ (using the classic Stroustrup-Ellis book) when being
hired to my first work in the age of 20.

My opinion is still so - it is too-high-level a language for system-level work.
In system-level work, bugs are very, very hard to find by debugging, and the
amount of code is smaller. It is easier to find the bug by code review often.

Dirty coding can easily make the project timeframe to be dependent on
bugfixing, and not on code typing and design phases.

In such situation, it is very important to the initial code to be a bug-free as
possible, to be not fragile (“fragile” means - tiny code patch causes bugs in
lots of places, which were seeming to be unrelated) and to be as comprehendable
as possible by the human being. Details hiding is evil. All details should be
exposed, while lots of C++ features like “operator T” are about details hiding.

C++ is fine in a projects like “COM object around some database storage”, or UI
projects, where you can just take the large building blocks and glue them
together, and any bugs are nearly obvious - 7 minutes in the debugger - and
this will work. Not so in system-level.

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

Gary_Little-2 · April 26, 2006, 10:46am

Since it’s been brought up, I remember a discussion around a table at the
second DEVCON about the explorations done in-house for writing managed
code device drivers using C#. The general commentary was that was not that
difficult a task.

Oh here we go … we’re at it again … we’re cussing C, we’re cussing C++
and getting screwed by C sharp.

Gary G. Little

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
Sent: Tuesday, April 25, 2006 9:00 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Placement new operator in a driver

Because no matter what we have told people in the past, they still use
C++. So, as a minor stopgap c++ is acceptable. C# is much better next
gen language, but there are a lot more issues to resolve then C++ has
(different issues). Not bad issues, just different

d

– I can spell, I just can’t type.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Pavel A.
Sent: Tuesday, April 25, 2006 5:20 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Placement new operator in a driver

“Mark Roddy” wrote in message news:xxxxx@ntdev…
> Any progress convincing the compiler folks to fix this problem?

Well why not just admit that C++ is not a good language for kernel mode?

C has been designed as lower lever, closer to machine semantics
language.
C++ has been designed for usermode. The “better C” approach did not work
for many reasons mentioned in this thread, especially by Don Burn.
The Embedded C++ project failed.
Do you see much C++ in Linux kernel? nope.
It’s time for conclusions… C++ just doesn’t have it.
Maybe C# will be the next “better C”.

Regards,
–PA

—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

OSR_Community_User · April 26, 2006, 12:04pm

> explorations done in-house for writing managed

code device drivers using C#.
That’s what I had in mind when I talked about language
features’ extension, attributes in the first place.

#pragma alloc_text actually is an attribute, but neither
C nor C++ know about that.

Reflection would be also nice in the kernel (as it is in UM).

The general commentary was that was not that
difficult a task.
Wow! KM port of mscorelib is simple???

Asynchronous GC that may freeze the GUI if you are not
helping it to decide when to kill what, imagine this in KM.

IMHO developing C# - styled dialect for KM would be quite
an undertaking.
Anyway, sounds interesting.
At least a (theoretical?) chance to reflect the new/updated
non-sequential reality.

----- Original Message -----
From:
To: “Windows System Software Devs Interest List”
Sent: Wednesday, April 26, 2006 10:46 AM
Subject: RE: [ntdev] Placement new operator in a driver

> Since it’s been brought up, I remember a discussion around a table at the
> second DEVCON about the explorations done in-house for writing managed
> code device drivers using C#. The general commentary was that was not that
> difficult a task.
>
> Oh here we go … we’re at it again … we’re cussing C, we’re cussing C++
> and getting screwed by C sharp.
>
> Gary G. Little
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
> Sent: Tuesday, April 25, 2006 9:00 PM
> To: Windows System Software Devs Interest List
> Subject: RE: [ntdev] Placement new operator in a driver
>
> Because no matter what we have told people in the past, they still use
> C++. So, as a minor stopgap c++ is acceptable. C# is much better next
> gen language, but there are a lot more issues to resolve then C++ has
> (different issues). Not bad issues, just different
>
> d
>
> – I can spell, I just can’t type.
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Pavel A.
> Sent: Tuesday, April 25, 2006 5:20 PM
> To: Windows System Software Devs Interest List
> Subject: Re:[ntdev] Placement new operator in a driver
>
> “Mark Roddy” wrote in message news:xxxxx@ntdev…
>> Any progress convincing the compiler folks to fix this problem?
>
> Well why not just admit that C++ is not a good language for kernel mode?
>
> C has been designed as lower lever, closer to machine semantics
> language.
> C++ has been designed for usermode. The “better C” approach did not work
> for many reasons mentioned in this thread, especially by Don Burn.
> The Embedded C++ project failed.
> Do you see much C++ in Linux kernel? nope.
> It’s time for conclusions… C++ just doesn’t have it.
> Maybe C# will be the next “better C”.
>
> Regards,
> --PA
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer

Doron_Holan · April 26, 2006, 12:25pm

C# is not tied to the CLR. You would get a KLR instead :). Reflection
would be damn hard as well, again, not a requirement for C# compliant
code.

d

– I can spell, I just can’t type.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of sh_alex
Sent: Wednesday, April 26, 2006 9:04 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Placement new operator in a driver

explorations done in-house for writing managed
code device drivers using C#.
That’s what I had in mind when I talked about language
features’ extension, attributes in the first place.

#pragma alloc_text actually is an attribute, but neither
C nor C++ know about that.

Reflection would be also nice in the kernel (as it is in UM).

The general commentary was that was not that
difficult a task.
Wow! KM port of mscorelib is simple???

Asynchronous GC that may freeze the GUI if you are not
helping it to decide when to kill what, imagine this in KM.

IMHO developing C# - styled dialect for KM would be quite
an undertaking.
Anyway, sounds interesting.
At least a (theoretical?) chance to reflect the new/updated
non-sequential reality.

----- Original Message -----
From:
To: “Windows System Software Devs Interest List”
Sent: Wednesday, April 26, 2006 10:46 AM
Subject: RE: [ntdev] Placement new operator in a driver

> Since it’s been brought up, I remember a discussion around a table at
the
> second DEVCON about the explorations done in-house for writing managed
> code device drivers using C#. The general commentary was that was not
that
> difficult a task.
>
> Oh here we go … we’re at it again … we’re cussing C, we’re cussing
C++
> and getting screwed by C sharp.
>
> Gary G. Little
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
> Sent: Tuesday, April 25, 2006 9:00 PM
> To: Windows System Software Devs Interest List
> Subject: RE: [ntdev] Placement new operator in a driver
>
> Because no matter what we have told people in the past, they still use
> C++. So, as a minor stopgap c++ is acceptable. C# is much better
next
> gen language, but there are a lot more issues to resolve then C++ has
> (different issues). Not bad issues, just different
>
> d
>
> – I can spell, I just can’t type.
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Pavel A.
> Sent: Tuesday, April 25, 2006 5:20 PM
> To: Windows System Software Devs Interest List
> Subject: Re:[ntdev] Placement new operator in a driver
>
> “Mark Roddy” wrote in message
news:xxxxx@ntdev…
>> Any progress convincing the compiler folks to fix this problem?
>
> Well why not just admit that C++ is not a good language for kernel
mode?
>
> C has been designed as lower lever, closer to machine semantics
> language.
> C++ has been designed for usermode. The “better C” approach did not
work
> for many reasons mentioned in this thread, especially by Don Burn.
> The Embedded C++ project failed.
> Do you see much C++ in Linux kernel? nope.
> It’s time for conclusions… C++ just doesn’t have it.
> Maybe C# will be the next “better C”.
>
> Regards,
> --PA
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer

—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

cristalink-2 · April 26, 2006, 7:47pm

My experience is quite opposite. I cannot imagine how could we develop
drivers for our virtual devices on plain C.

Plain C would increase time-to-market in *several* times.
The codebase in C would be hardly manageable due to its “fragility” in
terms of bugs.
With C++, we work on the “write-and-forget” basis. We usually get back to
old code only to add new functionality.
Most of the bugs are usually typos, hardware or third party related.
I personally use the debugger mainly to analyze crash dumps at the
development stage - 1 minute per typo-related crash. Honestly, I used the
kernel debugger to step through code only a few times for many years of
kernel mode programming. I can only recall the last time a few months ago
when things didn’t work because of a bug in Microsoft’s code.
None of the alleged C++ “problems” cause any real concern to us. We have
drivers nearly 300K in binary size, with 30-50% of this paged, with virtual
destructors, multiple inheritance and heavily templated. All this works fine
on x32, x64 and IA-64. We don’t have crashes at customer sites.

Given the above, how can anyone possibly convince me in the opposite? I
don’t mind anyone using C if it works for them. But the claims like “C++ is
not for kernel mode” sound arrogant and ignorant. I can well believe it did
not work for you, but that does not mean nobody else can use C++ properly.

Cheers

–
http://www.cristalink.com

“Maxim S. Shatskih” wrote in message
news:xxxxx@ntdev…
>> So how did you reach this conclusion? Was it because you tried C++ and
>> failed? Or because you heard that someone tried C++ and failed too? May I
>
> I worked in C++ in 93-99. User-mode Windows, MFC, ATL, COM and database
> work. I
> passed the exam on C++ (using the classic Stroustrup-Ellis book) when
> being
> hired to my first work in the age of 20.
>
> My opinion is still so - it is too-high-level a language for system-level
> work.
> In system-level work, bugs are very, very hard to find by debugging, and
> the
> amount of code is smaller. It is easier to find the bug by code review
> often.
>
> Dirty coding can easily make the project timeframe to be dependent on
> bugfixing, and not on code typing and design phases.
>
> In such situation, it is very important to the initial code to be a
> bug-free as
> possible, to be not fragile (“fragile” means - tiny code patch causes bugs
> in
> lots of places, which were seeming to be unrelated) and to be as
> comprehendable
> as possible by the human being. Details hiding is evil. All details should
> be
> exposed, while lots of C++ features like “operator T” are about details
> hiding.
>
> C++ is fine in a projects like “COM object around some database storage”,
> or UI
> projects, where you can just take the large building blocks and glue them
> together, and any bugs are nearly obvious - 7 minutes in the debugger -
> and
> this will work. Not so in system-level.
>
> Maxim Shatskih, Windows DDK MVP
> StorageCraft Corporation
> xxxxx@storagecraft.com
> http://www.storagecraft.com
>
>

OSR_Community_User · April 26, 2006, 10:33pm

“cristalink” wrote in message news:xxxxx@ntdev…
> >C++ just doesn’t have it.
>
> So how did you reach this conclusion? Was it because you tried C++ and failed? Or because you heard that someone tried C++ and
> failed too?

I’ve seen for many years that C++, despite of all it’s advantages,
has not been acccepted in kernel world. This just has not happened.
I personally don’t have anything against C++, use it as “better C” and
have seen the Compuware framework and Symbian.
But here are the dry facts. In last years, every time when we start a new project,
the management turns C++ down.
Some of the reasons have been already named in this thread:
lack of transparency and too much rope to shoot yourself in the leg.

> May I guess that the failures were because of the programmers who just “didn’t have it”?

Yes you may guess so - the human factor and team organisation surely influence
choice of the language (are there any research works on this?) -
but saying this loudly? yukes. it is not politically correct

–PA

OSR_Community_User · April 26, 2006, 10:46pm

“Mark Roddy” wrote in message news:xxxxx@ntdev…
>> “Mark Roddy” wrote in message
>> news:xxxxx@ntdev…
>> > Any progress convincing the compiler folks to fix this problem?
>>
>> Well why not just admit that C++ is not a good language for
>> kernel mode?
>>
>
> Because I am simply not convinced that this issue is an overwheming
> obstacle, and other than this issue there is no rational argument for not
> using C++.

Ok, here is one rational argument. C++ is a flammable substrate
for religious wars in the team.

> By the way, several Microsoft kernel components are developed using C++, for
> example KMDF.

Actually, Mark, this only confirms my statement.
You designed and coded it in C++ but could not expose C++ in public interface. Why?

–PA

Doron_Holan · April 26, 2006, 11:10pm

Because C is the best least common denominator for development. If we
(KMDF) created a C++ interface, that would exclude all the C only
developers out there. Given a choice between the two (yes, a choice
because we don’t necessarily have resources to do both and fully test
them), C gets better coverage.

d

– I can spell, I just can’t type.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Pavel A.
Sent: Wednesday, April 26, 2006 8:43 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Placement new operator in a driver

“Mark Roddy” wrote in message news:xxxxx@ntdev…
>> “Mark Roddy” wrote in message
>> news:xxxxx@ntdev…
>> > Any progress convincing the compiler folks to fix this problem?
>>
>> Well why not just admit that C++ is not a good language for
>> kernel mode?
>>
>
> Because I am simply not convinced that this issue is an overwheming
> obstacle, and other than this issue there is no rational argument for
not
> using C++.

Ok, here is one rational argument. C++ is a flammable substrate
for religious wars in the team.

> By the way, several Microsoft kernel components are developed using
C++, for
> example KMDF.

Actually, Mark, this only confirms my statement.
You designed and coded it in C++ but could not expose C++ in public
interface. Why?

–PA

—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

cristalink-2 · April 26, 2006, 11:11pm

There’s nothing politically incorrect here. SW development relies on people,
so the skills are the major factor. You can’t make say a VB programmer write
on C++. The road from C to C++ is quite long, too. Let alone from C++ to
good C++.

when we start a new project, the management turns C++ down

That’s a perfectly correct decision if they feel they will be better off
with C.

–

“Pavel A.” wrote in message news:xxxxx@ntdev…
> “cristalink” wrote in message news:xxxxx@ntdev…
>> >C++ just doesn’t have it.
>>
>> So how did you reach this conclusion? Was it because you tried C++ and
>> failed? Or because you heard that someone tried C++ and failed too?
>
> I’ve seen for many years that C++, despite of all it’s advantages,
> has not been acccepted in kernel world. This just has not happened.
> I personally don’t have anything against C++, use it as “better C” and
> have seen the Compuware framework and Symbian.
> But here are the dry facts. In last years, every time when we start a new
> project,
> the management turns C++ down.
> Some of the reasons have been already named in this thread:
> lack of transparency and too much rope to shoot yourself in the leg.
>
>> May I guess that the failures were because of the programmers who just
>> “didn’t have it”?
>
> Yes you may guess so - the human factor and team organisation surely
> influence
> choice of the language (are there any research works on this?) -
> but saying this loudly? yukes. it is not politically correct
>
>
> --PA
>
>
>

OSR_Community_User · April 26, 2006, 11:12pm

Is KMDF developed in C++ as Mark has pointed out?
I always suppose that KMDF has just borrowed some ideas and design
patterns from the OO programming world!!!
Doron, Can you clarify this question for our newbies?

Best Regards,
hanzhu

Mark Roddy Ð´µÀ:

By the way, several Microsoft kernel components are developed using C++, for
example KMDF.

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

> C has been designed as lower lever, closer to machine
> semantics language.
> C++ has been designed for usermode. The “better C” approach
> did not work
> for many reasons mentioned in this thread, especially by Don Burn.
> The Embedded C++ project failed.
> Do you see much C++ in Linux kernel? nope.
> It’s time for conclusions… C++ just doesn’t have it.
> Maybe C# will be the next “better C”.
>
> Regards,
> --PA
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online
> at http://www.osronline.com/page.cfm?name=ListServer
>

Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

Doron_Holan · April 26, 2006, 11:31pm

Borrow? You surely jest ;). Design patterns are patterns for a reason, they are useful. Yes, the underlying implementation of KMDF is written in C++, but under some very strict rules. No references, no templates, no overloaded operators. Basically, we use C++ for vtables and vtables only.

d

– I can spell, I just can’t type.

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of hanzhu
Sent: Wednesday, April 26, 2006 9:14 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Placement new operator in a driver

Is KMDF developed in C++ as Mark has pointed out?
I always suppose that KMDF has just borrowed some ideas and design
patterns from the OO programming world!!!
Doron, Can you clarify this question for our newbies?

Best Regards,
hanzhu

Mark Roddy $B>
> By the way, several Microsoft kernel components are developed using C++, for
> example KMDF.
>
>
> =====================
> Mark Roddy DDK MVP
> Windows 2003/XP/2000 Consulting
> Hollis Technology Solutions 603-321-1032
> www.hollistech.com
>
>
>> C has been designed as lower lever, closer to machine
>> semantics language.
>> C++ has been designed for usermode. The “better C” approach
>> did not work
>> for many reasons mentioned in this thread, especially by Don Burn.
>> The Embedded C++ project failed.
>> Do you see much C++ in Linux kernel? nope.
>> It’s time for conclusions… C++ just doesn’t have it.
>> Maybe C# will be the next “better C”.
>>
>> Regards,
>> --PA
>>
>>
>>
>> —
>> Questions? First check the Kernel Driver FAQ at
>> http://www.osronline.com/article.cfm?id=256
>>
>> To unsubscribe, visit the List Server section of OSR Online
>> at http://www.osronline.com/page.cfm?name=ListServer
>>
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
>

—
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

OSR_Community_User · April 27, 2006, 5:51am

Got it!
Doron, can you sum up these rules we should follow if we want to develop
our kernel mode program safely using c++? I have read most of the posts
in this thread, however, I’m afraid that I missed something!
My personnel attitude from my poor experience and your gurus discussion
about this topic is C is much straight and clear for developing driver.
You also could write your program much quick in C if you have to do it
from scratch. But kernel program based on C++ is more maintainable and a
little robust(This factor depends much on developer’s skill. But strict
type check etc. will help you achieve this.) Oh, there is another major
advantage for C++ since it makes CODE REUSE easily!

Thanks a lot!

Best Regards,
hanzhu

Doron Holan Ð´µÀ:

Borrow? You surely jest ;). Design patterns are patterns for a reason, they are useful. Yes, the underlying implementation of KMDF is written in C++, but under some very strict rules. No references, no templates, no overloaded operators. Basically, we use C++ for vtables and vtables only.

d

– I can spell, I just can’t type.

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of hanzhu
Sent: Wednesday, April 26, 2006 9:14 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Placement new operator in a driver

Is KMDF developed in C++ as Mark has pointed out?
I always suppose that KMDF has just borrowed some ideas and design
patterns from the OO programming world!!!
Doron, Can you clarify this question for our newbies?

Best Regards,
hanzhu

Mark Roddy $B>> By the way, several Microsoft kernel components are developed using C++, for
>> example KMDF.
>>
>>
>> =====================
>> Mark Roddy DDK MVP
>> Windows 2003/XP/2000 Consulting
>> Hollis Technology Solutions 603-321-1032
>> www.hollistech.com
>>
>>
>>> C has been designed as lower lever, closer to machine
>>> semantics language.
>>> C++ has been designed for usermode. The “better C” approach
>>> did not work
>>> for many reasons mentioned in this thread, especially by Don Burn.
>>> The Embedded C++ project failed.
>>> Do you see much C++ in Linux kernel? nope.
>>> It’s time for conclusions… C++ just doesn’t have it.
>>> Maybe C# will be the next “better C”.
>>>
>>> Regards,
>>> --PA
>>>
>>>
>>>
>>> —
>>> Questions? First check the Kernel Driver FAQ at
>>> http://www.osronline.com/article.cfm?id=256
>>>
>>> To unsubscribe, visit the List Server section of OSR Online
>>> at http://www.osronline.com/page.cfm?name=ListServer
>>>
>>
>>
>> —
>> Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
>>
>> To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
>>
>
> —
> Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
>
> —
> Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
>

OSR_Community_User · April 27, 2006, 9:04am

C++ wasn’t designed for any particular mode.
I would agree that using C++ in the kernel is not, generally, a very
good idea, but that’s really not a comment of the design or capabilities
of C++. The kernel wasn’t designed, with some good reasons, to support
it. The implementation of any particular compiler also figures in here.
While it would seem that some documentation would help in this area, I
just don’t know enough to comment on this topic.
Embedded C++ was a free project. A lack of market, by definition,
the success of Linux notwithstanding, probably had more than a little to
do with this.
Most of these arguments were applied to C when it came out, by very
qualified people, like Fred Brooks. To be fair, he was, presumably,
more than a little biased by Big Blue, as he did state (in print) that
PL/I was the only reasonable choice, but you get the idea.
I don’t think that it is fair to lump C++ in with every other
alegedly general purpose language in existence, than has arrived after
C. For example, the abject disaster, even, eventually, in marketing
terms, known as Fourth Generation Languages. C++ has lived up, at least
in some areas, its billing. The marketing people and language pundits,
who are basically the same, have made the whole topic fairly ridiculous,
but is some very real ways, C++ is quite nice in ways that C does not
offer: templates, for example.
I very seriously hope that C# is not the answer. I have never
understood the position about how memory management is such an
unneccesary pain in the ass. It’s, in my opinion, what it is all about.
That is, it’s all about the representation of data. If you can do this
effectively and efficiently, the rest of programming is really pretty
trivial.
In short, all this has nothing to do with defects or successes in
C++; it has to do with kernel and compiler support. This is simply no
reason why a kernel could not support C++; the compiler issue needs no
comment. For both however, the question of whether doing so makes
sense, in the profitable sense, is a very valid difficult one.

MM

>> xxxxx@writeme.com 2006-04-25 20:19 >>>
“Mark Roddy” wrote in message
news:xxxxx@ntdev…
> Any progress convincing the compiler folks to fix this problem?

Well why not just admit that C++ is not a good language for kernel
mode?

C has been designed as lower lever, closer to machine semantics
language.
C++ has been designed for usermode. The “better C” approach did not
work
for many reasons mentioned in this thread, especially by Don Burn.
The Embedded C++ project failed.
Do you see much C++ in Linux kernel? nope.
It’s time for conclusions… C++ just doesn’t have it.
Maybe C# will be the next “better C”.

Regards,
–PA

—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

OSR_Community_User · April 27, 2006, 9:06am

Good point. I think kernel streams drivers, as well as some audio, also
are C++, but this may be incorrect.

>> xxxxx@hollistech.com 2006-04-25 19:46 >>>

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Pavel A.
Sent: Tuesday, April 25, 2006 8:20 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Placement new operator in a driver

“Mark Roddy” wrote in message
> news:xxxxx@ntdev…
> > Any progress convincing the compiler folks to fix this problem?
>
> Well why not just admit that C++ is not a good language for
> kernel mode?
>

Because I am simply not convinced that this issue is an overwheming
obstacle, and other than this issue there is no rational argument for
not
using C++.

By the way, several Microsoft kernel components are developed using
C++, for
example KMDF.

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

> C has been designed as lower lever, closer to machine
> semantics language.
> C++ has been designed for usermode. The “better C” approach
> did not work
> for many reasons mentioned in this thread, especially by Don Burn.
> The Embedded C++ project failed.
> Do you see much C++ in Linux kernel? nope.
> It’s time for conclusions… C++ just doesn’t have it.
> Maybe C# will be the next “better C”.
>
> Regards,
> --PA
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online
> at http://www.osronline.com/page.cfm?name=ListServer
>

—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

OSR_Community_User · April 27, 2006, 9:15am

Just to continue beating this dead horse to a putrid pulp, out of a
sense of fairness I reexamined for the bazillionth time the map file
from a rather large and complicated c++ kernel driver and once again,
all the little generated functions were right where they ought to be,
not mysteriously emitted into PAGE or INIT. Then again, as somebody else
pointed out, wantonly paging large sections of kernel drivers is not
something I feel compelled to do, not that it is particularly applicable
to this component anyway.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Martin O’Brien
Sent: Thursday, April 27, 2006 9:03 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Placement new operator in a driver

C++ wasn’t designed for any particular mode.
I would agree that using C++ in the kernel is not, generally, a very
good idea, but that’s really not a comment of the design or capabilities
of C++. The kernel wasn’t designed, with some good reasons, to support
it. The implementation of any particular compiler also figures in here.
While it would seem that some documentation would help in this area, I
just don’t know enough to comment on this topic.
Embedded C++ was a free project. A lack of market, by definition,
the success of Linux notwithstanding, probably had more than a little to
do with this.
Most of these arguments were applied to C when it came out, by very
qualified people, like Fred Brooks. To be fair, he was, presumably,
more than a little biased by Big Blue, as he did state (in print) that
PL/I was the only reasonable choice, but you get the idea.
I don’t think that it is fair to lump C++ in with every other
alegedly general purpose language in existence, than has arrived after
C. For example, the abject disaster, even, eventually, in marketing
terms, known as Fourth Generation Languages. C++ has lived up, at least
in some areas, its billing. The marketing people and language pundits,
who are basically the same, have made the whole topic fairly ridiculous,
but is some very real ways, C++ is quite nice in ways that C does not
offer: templates, for example.
I very seriously hope that C# is not the answer. I have never
understood the position about how memory management is such an
unneccesary pain in the ass. It’s, in my opinion, what it is all about.
That is, it’s all about the representation of data. If you can do this
effectively and efficiently, the rest of programming is really pretty
trivial.
In short, all this has nothing to do with defects or successes in
C++; it has to do with kernel and compiler support. This is simply no
reason why a kernel could not support C++; the compiler issue needs no
comment. For both however, the question of whether doing so makes
sense, in the profitable sense, is a very valid difficult one.

MM

>> xxxxx@writeme.com 2006-04-25 20:19 >>>
“Mark Roddy” wrote in message
news:xxxxx@ntdev…
> Any progress convincing the compiler folks to fix this problem?

Well why not just admit that C++ is not a good language for kernel
mode?

C has been designed as lower lever, closer to machine semantics
language.
C++ has been designed for usermode. The “better C” approach did not
work
for many reasons mentioned in this thread, especially by Don Burn.
The Embedded C++ project failed.
Do you see much C++ in Linux kernel? nope.
It’s time for conclusions… C++ just doesn’t have it.
Maybe C# will be the next “better C”.

Regards,
–PA

—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

OSR_Community_User · April 27, 2006, 9:21am

It would be nice if a project was time dependant on “code typing,”
but is this realistic. Actually, it would suck, because it would be
really, really boring. Perhaps I’m alone in this, but projects always
depend massively on debugging, with only redesign due to client wishes
usually exceeding it.
The operator T issue is, to me, a religious one. I say religious,
because I see both sides as equally valid.
I wouldn’t argue that bugs in MFC programs are trivial to find.
That being said, I certainly wouldn’t argue that one would be better off
without MFC. That being said, I would argue until the day I died that
one would be better off without, say, those absolutely criminal
libraries that Borland perpetrates where everything begins with a “T.”
The long and short - it kind of depends on the library. This isn’t
about C++ so much as it is about library design. C++ does, in my
opinion, make a well designed library much, much easier to comprehend
and use; it does make a poorly designed one suck a whole bunch more.
This used to be fairly obvious. Years of marketing have most definitely
perpetrated the idea that C++ is trivial and, in fact, cures cancer.
The truth is that it is much more difficult. That does not mean, nor
does it mean, that the results are not worth it, in any particular
project.

MM

>> xxxxx@storagecraft.com 2006-04-26 07:23 >>>
So how did you reach this conclusion? Was it because you tried C++
and
failed? Or because you heard that someone tried C++ and failed too?
May I

I worked in C++ in 93-99. User-mode Windows, MFC, ATL, COM and database
work. I
passed the exam on C++ (using the classic Stroustrup-Ellis book) when
being
hired to my first work in the age of 20.

My opinion is still so - it is too-high-level a language for
system-level work.
In system-level work, bugs are very, very hard to find by debugging,
and the
amount of code is smaller. It is easier to find the bug by code review
often.

Dirty coding can easily make the project timeframe to be dependent on
bugfixing, and not on code typing and design phases.

In such situation, it is very important to the initial code to be a
bug-free as
possible, to be not fragile (“fragile” means - tiny code patch causes
bugs in
lots of places, which were seeming to be unrelated) and to be as
comprehendable
as possible by the human being. Details hiding is evil. All details
should be
exposed, while lots of C++ features like “operator T” are about details
hiding.

C++ is fine in a projects like “COM object around some database
storage”, or UI
projects, where you can just take the large building blocks and glue
them
together, and any bugs are nearly obvious - 7 minutes in the debugger

and
this will work. Not so in system-level.

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

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

OSR_Community_User · April 27, 2006, 9:30am

DORON:

Why no references? Is that just a semantics/convenience/convention (i.
e. - because it doesn’t explicitly look like a pointer) issue, or is it
a compiler/kernel thing?

Just curious.

MM

>> xxxxx@microsoft.com 2006-04-26 23:27 >>>
Borrow? You surely jest ;). Design patterns are patterns for a
reason, they are useful. Yes, the underlying implementation of KMDF is
written in C++, but under some very strict rules. No references, no
templates, no overloaded operators. Basically, we use C++ for vtables
and vtables only.

d

– I can spell, I just can’t type.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of hanzhu
Sent: Wednesday, April 26, 2006 9:14 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Placement new operator in a driver

Is KMDF developed in C++ as Mark has pointed out?
I always suppose that KMDF has just borrowed some ideas and design
patterns from the OO programming world!!!
Doron, Can you clarify this question for our newbies?

Best Regards,
hanzhu

Mark Roddy :

By the way, several Microsoft kernel components are developed using
C++, for
example KMDF.

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

> C has been designed as lower lever, closer to machine
> semantics language.
> C++ has been designed for usermode. The “better C” approach
> did not work
> for many reasons mentioned in this thread, especially by Don Burn.
> The Embedded C++ project failed.
> Do you see much C++ in Linux kernel? nope.
> It’s time for conclusions… C++ just doesn’t have it.
> Maybe C# will be the next “better C”.
>
> Regards,
> --PA
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online
> at http://www.osronline.com/page.cfm?name=ListServer
>

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer