WDK 8 compilation failure

I can’t figure out how to get this to compile in my drivers:

#include

Works fine in WDK 7.1 and earlier.

New declares and uses native eh. Native eh has never been allowed in kernel mode. Win8 is now enforcing this rule. Declare your own operator new() that can returns null on failure instead of throwing

d

debt from my phone


From: xxxxx@gmail.com
Sent: 7/4/2012 5:30 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] WDK 8 compilation failure

I can’t figure out how to get this to compile in my drivers:

#include

Works fine in WDK 7.1 and earlier.


NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

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

Doron Holan wrote:

New declares and uses native eh. Native eh has never been allowed in
kernel mode. Win8 is now enforcing this rule. Declare your own
operator new() that can returns null on failure instead of throwing

Note that you can borrow one from <kcom.h> in the WDK.


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

Over the last 20 years it has been at times awkward working around kernel header files being incompatible with user mode header files, but now they are incompatible with some of the standard header files too. That’s unfortunate. I wonder how many percent of drivers this is going to break. Searching around I see I am not the first or second to bump into this problem.

They were never standard not supported for km. That is what happens when you use unsupported headers and patterns . Like Tim pointed out, this is not a showstopper, there is a simple fix. Same for every dev who wants to use boost or STL in km. Just because ot compiled does not mean it is supported

d

debt from my phone


From: xxxxx@gmail.com
Sent: 7/5/2012 5:31 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] WDK 8 compilation failure

Over the last 20 years it has been at times awkward working around kernel header files being incompatible with user mode header files, but now they are incompatible with some of the standard header files too. That’s unfortunate. I wonder how many percent of drivers this is going to break. Searching around I see I am not the first or second to bump into this problem.


NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

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

>incompatible with user mode header files, but now they are incompatible with some of the standard

header files too.

Sorry, C++ exceptions are not (and were never) supported in Windows kmode, and I think in Linux kmode too.

So, forget STL (until you want to do a massive rewrite of it). Forget C++ standard.

The kernel is not a standard programming env. This is a special programming env with only 1 language and 1 compiler supported. Sorry.

That’s unfortunate. I wonder how many percent of drivers this is going to break

I think the number of drivers using C++ “new” is like 1% or so.


Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

>every dev who wants to use boost

Actually I have lots of compassion to developers who use this pile of dirt in any serious multi-year maintenance-heavy projects.

Some morons, for instance, really used boost’s serialization as marshalling engine in their proprietary RPC-style solution, just to have it broken by the boost’s version upgrade, which caused them lots of pain.

Surely non-morons would never ever rely their serious project on such kind of stuff, or, in worse case, immediately start their proprietary fork of older boost’s serialization to do this.

C++, STL and especially Boost are not standards, at least not the reliable industry standards really supported by the Big Influential Names.

Stroustrup is free to declare any his ivory-tower stuff as “standard”, but this is not what the people use.

On the other hand, POSIX is standard. Win32 is. Even MFC is. Qt is. .NET is, so is Java.

And yes, MFC (Windows) and Qt (Linux) are by far more important things for developers then most of Boost.


Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

Maxim S. Shatskih wrote:

Sorry, C++ exceptions are not (and were never) supported in Windows kmode, and I think in Linux kmode too.

So, forget STL (until you want to do a massive rewrite of it). Forget C++ standard.

You mean “C++ standard library”, I think.

There is a version of STL in the WDK that can be made to work in kernel
drivers, for some value of the word “work”. I’ve never been confident
enough in its safety to use it in a production driver, and remember
that’s coming from someone who is an outspoken advocate of C++ in the
kernel.

> That’s unfortunate. I wonder how many percent of drivers this is going to break

It is going to break 0% of drivers. Any kernel driver that used “new”
already had their own implementation.

I think the number of drivers using C++ “new” is like 1% or so.

That’s too bad. It is trivial to write “operator new” and “operator
delete” replacements that Do The Right Thing in kernel mode (as I said,
there’s even an implementation included in the WDK). All of my C++
drivers use them, because I find it more expressive than calling
ExFreePool and casting the result.


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

The other option you have is to forego STL and such altogether and just use
some of the raw C++ language features. This means implementing your own
operator new and limiting yourself in what C++ features you use such that
you are not relying on any C++ runtime or library support.

  • Danilo

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
Sent: Friday, July 06, 2012 9:26 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] WDK 8 compilation failure

Maxim S. Shatskih wrote:

Sorry, C++ exceptions are not (and were never) supported in Windows kmode,
and I think in Linux kmode too.

So, forget STL (until you want to do a massive rewrite of it). Forget C++
standard.

You mean “C++ standard library”, I think.

There is a version of STL in the WDK that can be made to work in kernel
drivers, for some value of the word “work”. I’ve never been confident
enough in its safety to use it in a production driver, and remember
that’s coming from someone who is an outspoken advocate of C++ in the
kernel.

> That’s unfortunate. I wonder how many percent of drivers this is going to
break

It is going to break 0% of drivers. Any kernel driver that used “new”
already had their own implementation.

I think the number of drivers using C++ “new” is like 1% or so.

That’s too bad. It is trivial to write “operator new” and “operator
delete” replacements that Do The Right Thing in kernel mode (as I said,
there’s even an implementation included in the WDK). All of my C++
drivers use them, because I find it more expressive than calling
ExFreePool and casting the result.


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


NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

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

That is basically what /kernel enforces, no eh, no rtti. Just raw c++.

d

debt from my phone


From: Danilo Almeida
Sent: 7/6/2012 5:43 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] WDK 8 compilation failure

The other option you have is to forego STL and such altogether and just use
some of the raw C++ language features. This means implementing your own
operator new and limiting yourself in what C++ features you use such that
you are not relying on any C++ runtime or library support.

  • Danilo

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
Sent: Friday, July 06, 2012 9:26 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] WDK 8 compilation failure

Maxim S. Shatskih wrote:

Sorry, C++ exceptions are not (and were never) supported in Windows kmode,
and I think in Linux kmode too.

So, forget STL (until you want to do a massive rewrite of it). Forget C++
standard.

You mean “C++ standard library”, I think.

There is a version of STL in the WDK that can be made to work in kernel
drivers, for some value of the word “work”. I’ve never been confident
enough in its safety to use it in a production driver, and remember
that’s coming from someone who is an outspoken advocate of C++ in the
kernel.

> That’s unfortunate. I wonder how many percent of drivers this is going to
break

It is going to break 0% of drivers. Any kernel driver that used “new”
already had their own implementation.

I think the number of drivers using C++ “new” is like 1% or so.

That’s too bad. It is trivial to write “operator new” and “operator
delete” replacements that Do The Right Thing in kernel mode (as I said,
there’s even an implementation included in the WDK). All of my C++
drivers use them, because I find it more expressive than calling
ExFreePool and casting the result.


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


NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

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


NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

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

Cool!

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
Sent: Friday, July 06, 2012 6:03 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] WDK 8 compilation failure

That is basically what /kernel enforces, no eh, no rtti. Just raw c++.

d

debt from my phone


From: Danilo Almeida
Sent: 7/6/2012 5:43 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] WDK 8 compilation failure

The other option you have is to forego STL and such altogether and just use
some of the raw C++ language features. This means implementing your own
operator new and limiting yourself in what C++ features you use such that
you are not relying on any C++ runtime or library support.

  • Danilo

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
Sent: Friday, July 06, 2012 9:26 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] WDK 8 compilation failure

Maxim S. Shatskih wrote:

Sorry, C++ exceptions are not (and were never) supported in Windows kmode,
and I think in Linux kmode too.

So, forget STL (until you want to do a massive rewrite of it). Forget C++
standard.

You mean “C++ standard library”, I think.

There is a version of STL in the WDK that can be made to work in kernel
drivers, for some value of the word “work”. I’ve never been confident
enough in its safety to use it in a production driver, and remember
that’s coming from someone who is an outspoken advocate of C++ in the
kernel.

> That’s unfortunate. I wonder how many percent of drivers this is going to
break

It is going to break 0% of drivers. Any kernel driver that used “new”
already had their own implementation.

I think the number of drivers using C++ “new” is like 1% or so.

That’s too bad. It is trivial to write “operator new” and “operator
delete” replacements that Do The Right Thing in kernel mode (as I said,
there’s even an implementation included in the WDK). All of my C++
drivers use them, because I find it more expressive than calling
ExFreePool and casting the result.


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


NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

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


NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

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


NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

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