OSR, how about summing it up in an article in the “insider”? IMHO, Jan’s and Doron’s posts plus the rest that was said deserve it.
[/quote]
Great idea!
You write it up, Alex, we’ll edit and publish it.
Peter
OSR
Edouard A. wrote:
Ok so what happened this morning is that I added that placement new operator
and evertyhing went well. Thanks for your help. The problem was caused by a
typo in inheritance, my apologies for all this… Much ado about nothing…
You know, it’s worth pointing out that the standard #include (in
the DDK in inc\crt) has an implementation of placement new/delete that
works in drivers, and #include <kcom.h> (in inc\ddk\wxp) has an
implementation of the standard operator new and delete that accepts pool
type and pool tag and calls ExAllocatePoolWithTag and ExFreeTag.
The placement operators are incredibly complicated:
inline void *__cdecl operator new(size_t, void *_P)
{return (_P); }
inline void__cdecl operator delete(void *, void *)
{return; }
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.</kcom.h>
I wouldn’t trust anyting from the crt with regards to memory management,
it was not written with KM in mind at all. That said, those 2 are
portable to KM 
d
– I can spell, I just can’t type.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
Sent: Monday, April 24, 2006 2:27 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Re:Placement new operator in a driver
Edouard A. wrote:
Ok so what happened this morning is that I added that placement new
operator
and evertyhing went well. Thanks for your help. The problem was caused
by a
typo in inheritance, my apologies for all this… Much ado about
nothing…
You know, it’s worth pointing out that the standard #include (in
the DDK in inc\crt) has an implementation of placement new/delete that
works in drivers, and #include <kcom.h> (in inc\ddk\wxp) has an
implementation of the standard operator new and delete that accepts pool
type and pool tag and calls ExAllocatePoolWithTag and ExFreeTag.
The placement operators are incredibly complicated:
inline void *__cdecl operator new(size_t, void *_P)
{return (_P); }
inline void__cdecl operator delete(void *, void *)
{return; }
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
—
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</kcom.h>
> You write it up, Alex, we’ll edit and publish it.
Thank you for the honor, Peter, but I think authors
are authors, and I’m not one of them.
----- Original Message -----
From:
To: “Windows System Software Devs Interest List”
Sent: Monday, April 24, 2006 5:11 PM
Subject: RE:[ntdev] Placement new operator in a driver
>
>
> OSR, how about summing it up in an article in the “insider”? IMHO, Jan’s
> and Doron’s posts plus the rest that was said deserve it.
>
>
[/quote]
>
> Great idea!
>
> You write it up, Alex, we’ll edit and publish it.
>
> Peter
> OSR
>
> —
> 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
>
Ah… I didn’t know about that, I’ll use that in my next project, thanks!
For the deletion I used the five point palm explicit destructor call
technique instead :
void FreeEntry(IN OUT T **pp)
{
ASSERT(this != NULL);
ASSERT(pp != NULL);
ASSERT(KeGetCurrentIrql() <= DISPATCH_LEVEL);
// note that we don’t desallocate in place
// because a list must never have an invalid object
T *pEntryToDelete = *pp;
ASSERT(pEntryToDelete != NULL);
*pp = NULL;
// explicit destructor call
pEntryToDelete->~T();
ExFreeToNPagedLookasideList(&m_lalstEntryBuffers, pEntryToDelete);
ASSERT((*pp) == NULL);
}
As for the knowing how many functions are in init, I think I could try a
simple heuristic like :
- count how many [55 8b ec * c3] or [55 8b ec * c2 ??] are in INIT and
PAGE sections of the drivers
or - add a known string to each function and count
unsigned char pcMyMarkerTab[4] = { 1, 2, 3, 4 };
pcMyMarkerTab[0] = pcMyMarkerTab[0]; // to avoid the warning
Just a shot in the dark.
–
Edouard
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
Sent: Monday, April 24, 2006 23:27
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Re:Placement new operator in a driver
Edouard A. wrote:
Ok so what happened this morning is that I added that placement new
operator and evertyhing went well. Thanks for your help. The problem
was caused by a typo in inheritance, my apologies for all this… Much ado
about nothing…
You know, it’s worth pointing out that the standard #include (in the
DDK in inc\crt) has an implementation of placement new/delete that works in
drivers, and #include <kcom.h> (in inc\ddk\wxp) has an implementation of the
standard operator new and delete that accepts pool type and pool tag and
calls ExAllocatePoolWithTag and ExFreeTag.
The placement operators are incredibly complicated:
inline void *__cdecl operator new(size_t, void *_P)
{return (_P); }
inline void__cdecl operator delete(void *, void *)
{return; }
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
—
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
----------------------------------------------------------------------------
-----------
Wanadoo vous informe que cet e-mail a ete controle par l’anti-virus mail.
Aucun virus connu a ce jour par nos services n’a ete detecte.</kcom.h>
> What’s wrong with semi-automating the process?
Because such a stupid semi-automation of locked(lock){} does not support the
common usage patterns.
As was shown (by Jan), lang shortcuts may simplify life;
They are always worse then the manually crafted macros like DECLARE_DYNAMIC.
Can I get a compiler error by waiting in a handler that may be
called at dispatch? No, the language does not know anything.
You can get PREFast error 
Looks like the idea of inventing a language which will limit this and that to
make programming safe is dead. But the idea of static code analyzis at
compile time is fine.
And, for static code analyzis, the simpler the language, the better. PREFast is
nearly C only, it is very, very stupid in C++.
So, maybe the future is - relaxing the language limitations in favour of the
static code analyzis tools.
C was invented because algol and fortran did not know
something:-)
Yes. Raw pointers, for instance.
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
> ----------
From: xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com] on behalf of Maxim S. Shatskih[SMTP:xxxxx@storagecraft.com]
Reply To: Windows System Software Devs Interest List
Sent: Tuesday, April 25, 2006 10:53 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Re:Placement new operator in a driverAnd, for static code analyzis, the simpler the language, the better. PREFast is
nearly C only, it is very, very stupid in C++.
PC-lint handles C++ rather well. What’s the point of using PREFast? Has MS always to reinvent wheels and make them worse? Is there one thing which PREFast does better than PC-lint?
Few days back I found 3790.1830 DDK supports PC-lint directly. Just the matter of several environment variables and lint configuration. It is very useful for 64-porting; PC-lint is able to find all incorrect format specifications (%x instead of %p etc.) in traces, for example. I’d believe I fixed everything by hand before but it still found 5 occurences I missed.
Best regards,
Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]
Yeah… PC-Lint support has been in the DDK for years:
http://www.osronline.com/article.cfm?id=143
In my experience, it does an EXCELLENT job of finding weird code bugs. OTOH, it becomes very unhappy when trying to analyze a file that used WPP Tracing. I figure that’s about right, cuz I become unhappy under that condition too.
Peter
OSR
Well I use PreFast for Drivers (PFD) and PC-Lint. First they find different
things in many cases. Second unless you spend a lot of time building your
own lint config file to define all the DDK functions you are not going to
catch as much. Even if you do the lint config, the PreFast that comes with
the Vista WDK understands SAL which is more powerful than what Lint can do
for parameter checking.
The DDK has supported PC-Lint (not well, but supported) for a long time, OSR
had an article years ago on this. The thing is PC-LInt and PFD have
different targets.
–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Remove StopSpam from the email to reply
“Michal Vodicka” wrote in message
news:xxxxx@ntdev…
> ----------
> From:
> xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com]
> on behalf of Maxim S. Shatskih[SMTP:xxxxx@storagecraft.com]
> Reply To: Windows System Software Devs Interest List
> Sent: Tuesday, April 25, 2006 10:53 AM
> To: Windows System Software Devs Interest List
> Subject: Re: [ntdev] Re:Placement new operator in a driver
>
> And, for static code analyzis, the simpler the language, the better.
> PREFast is
> nearly C only, it is very, very stupid in C++.
>
PC-lint handles C++ rather well. What’s the point of using PREFast? Has MS
always to reinvent wheels and make them worse? Is there one thing which
PREFast does better than PC-lint?
Few days back I found 3790.1830 DDK supports PC-lint directly. Just the
matter of several environment variables and lint configuration. It is very
useful for 64-porting; PC-lint is able to find all incorrect format
specifications (%x instead of %p etc.) in traces, for example. I’d believe I
fixed everything by hand before but it still found 5 occurences I missed.
Best regards,
Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]
> ----------
From: xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com] on behalf of xxxxx@osr.com[SMTP:xxxxx@osr.com]
Reply To: Windows System Software Devs Interest List
Sent: Tuesday, April 25, 2006 9:17 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Placement new operator in a driverYeah… PC-Lint support has been in the DDK for years:
Would you believe I read this article then and appreciated you finally found PC-lint useful? For some reason I didn’t start to use DDK support and continued to use my own instead. Then I forgot about it and now discovered it again DDK support is a bit clumsy but great for porting as it automatically supplies the same parameters to both compiler and lint.
In my experience, it does an EXCELLENT job of finding weird code bugs.
Mine, too.
OTOH, it becomes very unhappy when trying to analyze a file that used WPP Tracing. I figure that’s about right, cuz I become unhappy under that condition too.
no surprise. However, I believe it could be handled by clever preprocessor definitions. Fortunately, it has no problem with my traces
Best regards,
Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]
OK, you convinced me to try it again. More checking is better. However, I can’t find it in the WDK 5308. It is in the 5048 and 5112 which I still have installed. Am I missing something?
Best regards,
Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]
From: xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com] on behalf of Don Burn[SMTP:xxxxx@acm.org]
Reply To: Windows System Software Devs Interest List
Sent: Tuesday, April 25, 2006 9:18 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Re:Placement new operator in a driverWell I use PreFast for Drivers (PFD) and PC-Lint. First they find different
things in many cases. Second unless you spend a lot of time building your
own lint config file to define all the DDK functions you are not going to
catch as much. Even if you do the lint config, the PreFast that comes with
the Vista WDK understands SAL which is more powerful than what Lint can do
for parameter checking.The DDK has supported PC-Lint (not well, but supported) for a long time, OSR
had an article years ago on this. The thing is PC-LInt and PFD have
different targets.–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Remove StopSpam from the email to reply“Michal Vodicka” wrote in message
> news:xxxxx@ntdev…
> > ----------
> > From:
> > xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com]
> > on behalf of Maxim S. Shatskih[SMTP:xxxxx@storagecraft.com]
> > Reply To: Windows System Software Devs Interest List
> > Sent: Tuesday, April 25, 2006 10:53 AM
> > To: Windows System Software Devs Interest List
> > Subject: Re: [ntdev] Re:Placement new operator in a driver
> >
> > And, for static code analyzis, the simpler the language, the better.
> > PREFast is
> > nearly C only, it is very, very stupid in C++.
> >
> PC-lint handles C++ rather well. What’s the point of using PREFast? Has MS
> always to reinvent wheels and make them worse? Is there one thing which
> PREFast does better than PC-lint?
>
> Few days back I found 3790.1830 DDK supports PC-lint directly. Just the
> matter of several environment variables and lint configuration. It is very
> useful for 64-porting; PC-lint is able to find all incorrect format
> specifications (%x instead of %p etc.) in traces, for example. I’d believe I
> fixed everything by hand before but it still found 5 occurences I missed.
>
> Best regards,
>
> Michal Vodicka
> UPEK, Inc.
> [xxxxx@upek.com, http://www.upek.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
>
Yes it is in all of them. There are a few bugs in the annotations, but
considering how many functions had to be annotated, this is to be expected.
I do wish Microsoft would provide better documentation on the annotations, I
suspect I could tighten up the ones for my functions.
Don Burn
“Michal Vodicka” wrote in message
news:xxxxx@ntdev…
OK, you convinced me to try it again. More checking is better. However, I
can’t find it in the WDK 5308. It is in the 5048 and 5112 which I still have
installed. Am I missing something?
Best regards,
Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]
I might still be sleeping, but what’s wrong with
(1a) lock(container)
{
foreach(c in container)
{
if( IsOurObject(c) )
{
container.Detach(c);
return c;
}
}
return null;
or
(1b)
AcquireSpinLock asl( container );
for( container::iterator it=container.begin(); it != container.end(); it++)
{
Object* pObject = *it;
if( IsOurObject(pObject) )
{
container.erase(it);
return pObject;
}
}
return NULL;
or
(2a) for(;
{
lock( container )
{
if(check_condition) break;
}
Sleep();
}
or
(2b) for(;
{
AcquireSpinLock asl( container );
if(check_condition) break;
asl.Release(); // asl is smart enough not to release when goes out of
scope
Sleep();
}
or
(2c) for(;
{
{
AcquireSpinLock asl( container );
if(check_condition) break;
}
Sleep();
}
–
“Maxim S. Shatskih” wrote in message
news:xxxxx@ntdev…
>> lock(that) {… }
>
> What about the “unlock-wait-lock-retest_condition” pattern? rather
> frequent,
> and not supported by this syntax.
>
> What about:
>
> Lock(container);
> for each c in Container
> {
> if( IsOurObject(c) )
> {
> container.Detach(c);
> Unlock(container);
> return c;
> }
> }
> Unlock(container);
> return null;
>
> - again a very common find-and-detach pattern, and again not supported by
> the
> syntax (except using callbacks/delegates).
>
> Alexandrescu is good, but he will never list all patterns we are meeting
> in our
> real work.
>
> Also looks like all these “pattern inventors” are not good friends with
> threads
> adding threads to their patterns introduces the new patterns not in
> their
> books, like the 2 above one.
>
> Maxim Shatskih, Windows DDK MVP
> StorageCraft Corporation
> xxxxx@storagecraft.com
> http://www.storagecraft.com
>
>
In addition to understand SAL, PFD has a kernel specific annotation
model (expressed in a model file, not SAL yet) so it can understand
things IRQL and locks (like if you acquire but not release a spinlock in
a function). Like Don said, lint and PFD occupy different spaces in
code analysis.
d
– I can spell, I just can’t type.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Don Burn
Sent: Tuesday, April 25, 2006 12:57 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Re:Placement new operator in a driver
Yes it is in all of them. There are a few bugs in the annotations, but
considering how many functions had to be annotated, this is to be
expected.
I do wish Microsoft would provide better documentation on the
annotations, I
suspect I could tighten up the ones for my functions.
Don Burn
“Michal Vodicka” wrote in message
news:xxxxx@ntdev…
OK, you convinced me to try it again. More checking is better. However,
I
can’t find it in the WDK 5308. It is in the 5048 and 5112 which I still
have
installed. Am I missing something?
Best regards,
Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.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
You cannot sleep under a spinlock, forget this.
The first sample is fine, if we are speaking about “return”. If not - if
“goto” is used instead of “return”, and the function continues - then sorry,
lock(Lock) {} stuff does not work.
And sorry, I will not establish the BOOLEAN variable with the only purpose
of getting rid of “goto”.
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
----- Original Message -----
From: “cristalink”
Newsgroups: ntdev
To: “Windows System Software Devs Interest List”
Sent: Wednesday, April 26, 2006 12:57 AM
Subject: Re:[ntdev] Re:Placement new operator in a driver
> I might still be sleeping, but what’s wrong with
>
> (1a) lock(container)
> {
> foreach(c in container)
> {
> if( IsOurObject(c) )
> {
> container.Detach(c);
> return c;
> }
> }
> return null;
>
> or
>
> (1b)
> AcquireSpinLock asl( container );
> for( container::iterator it=container.begin(); it != container.end(); it++)
> {
> Object* pObject = *it;
> if( IsOurObject(pObject) )
> {
> container.erase(it);
> return pObject;
> }
> }
> return NULL;
>
> or
>
> (2a) for(;
> {
> lock( container )
> {
> if(check_condition) break;
> }
> Sleep();
> }
>
> or
>
> (2b) for(;
> {
> AcquireSpinLock asl( container );
> if(check_condition) break;
> asl.Release(); // asl is smart enough not to release when goes out of
> scope
> Sleep();
> }
>
> or
>
> (2c) for(;
> {
> {
> AcquireSpinLock asl( container );
> if(check_condition) break;
> }
> Sleep();
> }
>
> –
>
>
> “Maxim S. Shatskih” wrote in message
> news:xxxxx@ntdev…
> >> lock(that) {… }
> >
> > What about the “unlock-wait-lock-retest_condition” pattern? rather
> > frequent,
> > and not supported by this syntax.
> >
> > What about:
> >
> > Lock(container);
> > for each c in Container
> > {
> > if( IsOurObject(c) )
> > {
> > container.Detach(c);
> > Unlock(container);
> > return c;
> > }
> > }
> > Unlock(container);
> > return null;
> >
> > - again a very common find-and-detach pattern, and again not supported by
> > the
> > syntax (except using callbacks/delegates).
> >
> > Alexandrescu is good, but he will never list all patterns we are meeting
> > in our
> > real work.
> >
> > Also looks like all these “pattern inventors” are not good friends with
> > threads
> > adding threads to their patterns introduces the new patterns not in
> > their
> > books, like the 2 above one.
> >
> > 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
“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
> You cannot sleep under a spinlock, forget this.
Who are you speaking to? Who is sleeping under a spinlock?
The first sample is fine, if we are speaking about “return”. If not -
if
“goto” is used instead of “return”, and the function continues - then
sorry,
lock(Lock) {} stuff does not work.
Apparently you just don’t understand how lock(Lock) works. It locks the
object before the first statement of the block is executed, and releases the
lock when the execution flow leaves the block, regardless of whether it was
because of return, goto, exception or the closing curved brace. Assuming
lock(Lock) refers to the C# statement.
“AcquireSpinLock asl(spinlock)” releases the spinlock once “asl” goes out of
scope or if asl.Release() is called.
–
“Maxim S. Shatskih” wrote in message
news:xxxxx@ntdev…
> You cannot sleep under a spinlock, forget this.
>
> The first sample is fine, if we are speaking about “return”. If not -
> if
> “goto” is used instead of “return”, and the function continues - then
> sorry,
> lock(Lock) {} stuff does not work.
>
> And sorry, I will not establish the BOOLEAN variable with the only
> purpose
> of getting rid of “goto”.
>
> Maxim Shatskih, Windows DDK MVP
> StorageCraft Corporation
> xxxxx@storagecraft.com
> http://www.storagecraft.com
>
> ----- Original Message -----
> From: “cristalink”
> Newsgroups: ntdev
> To: “Windows System Software Devs Interest List”
> Sent: Wednesday, April 26, 2006 12:57 AM
> Subject: Re:[ntdev] Re:Placement new operator in a driver
>
>
>> I might still be sleeping, but what’s wrong with
>>
>> (1a) lock(container)
>> {
>> foreach(c in container)
>> {
>> if( IsOurObject(c) )
>> {
>> container.Detach(c);
>> return c;
>> }
>> }
>> return null;
>>
>> or
>>
>> (1b)
>> AcquireSpinLock asl( container );
>> for( container::iterator it=container.begin(); it != container.end();
>> it++)
>> {
>> Object* pObject = *it;
>> if( IsOurObject(pObject) )
>> {
>> container.erase(it);
>> return pObject;
>> }
>> }
>> return NULL;
>>
>> or
>>
>> (2a) for(;
>> {
>> lock( container )
>> {
>> if(check_condition) break;
>> }
>> Sleep();
>> }
>>
>> or
>>
>> (2b) for(;
>> {
>> AcquireSpinLock asl( container );
>> if(check_condition) break;
>> asl.Release(); // asl is smart enough not to release when goes out
>> of
>> scope
>> Sleep();
>> }
>>
>> or
>>
>> (2c) for(;
>> {
>> {
>> AcquireSpinLock asl( container );
>> if(check_condition) break;
>> }
>> Sleep();
>> }
>>
>> –
>>
>>
>> “Maxim S. Shatskih” wrote in message
>> news:xxxxx@ntdev…
>> >> lock(that) {… }
>> >
>> > What about the “unlock-wait-lock-retest_condition” pattern? rather
>> > frequent,
>> > and not supported by this syntax.
>> >
>> > What about:
>> >
>> > Lock(container);
>> > for each c in Container
>> > {
>> > if( IsOurObject(c) )
>> > {
>> > container.Detach(c);
>> > Unlock(container);
>> > return c;
>> > }
>> > }
>> > Unlock(container);
>> > return null;
>> >
>> > - again a very common find-and-detach pattern, and again not supported
>> > by
>> > the
>> > syntax (except using callbacks/delegates).
>> >
>> > Alexandrescu is good, but he will never list all patterns we are
>> > meeting
>> > in our
>> > real work.
>> >
>> > Also looks like all these “pattern inventors” are not good friends with
>> > threads
>> > adding threads to their patterns introduces the new patterns not in
>> > their
>> > books, like the 2 above one.
>> >
>> > 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
>
>
>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? May I
guess that the failures were because of the programmers who just “didn’t
have it”?
–
“Pavel A.” 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?
>
> 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
>
>
>
> -----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
>
Doron Holan wrote:
Basically, the only workaround is to have a completely non pageable
driver.
At least for the last 10 years or so, this has been a perfectly
reasonable thing to do for 99% of all 3rd party drivers (Microsoft has
different constraints).
At which point templates, virtual destructors, default copy
constructors, etc., etc. are parts of the language that you can use
without worrying about this particular problem (leaving only their
inherent complexity... always an engineering tradeoff with their
usefulness).
Ray