When writing windows kernel drivers some headers that I would expect to work in kernel mode cannot be imported, and give very inscrutable errors. Headers such as:
- type_traits
- array
- span
- utility
- variant
All give lots of errors with undefined symbols, invalid template arguments, error directives about _HAS_EXCEPTIONS == 0 not supported, etc. On one hand, this makes sense, the kernel environment is very different from usermode and the STL relies on exceptions, which the kernel doesn't have - duh stuff will break. On the other hand, if I am smart about using containers that don't allocate, I can compile a static library with C++ exceptions off, disable the /GS security and SDL checks, apply /NODEFAULTLIB, etc and then link this static library to my driver and everything works fantastic.
It is unfortunate that it seems these headers don't work. I'd very much like to use non-allocating features such as std::span, std::array, std::enable_if, std::remove_reference, and lots of other things from type_traits especially in my driver but I cannot!
I expect things like std::vector std::string and other containers with allocator requirements to never work, but I would expect these headers which are pure C++ to work just fine. And I can prove that as long as I can get them to compile in a static library that they really do execute just fine there! As a workaround for this I've had to do something very wild, where I compile my 'drivers' as free standing .DLLs then manual map them into the kernel, just so that I can use the C++ features I need easily. See:
C++ DLL with fancy header usages
C++ driver mapping dll into kernel
My question, why do these headers not work as I'd expect in a driver, but do work when I compile as a free standing DLL. And, will this situation ever be improved, at least for the core utility stuff like type_traits
When writing windows kernel drivers some headers that I would expect to work in kernel mode cannot be imported, and give very inscrutable errors. Headers such as:
All give lots of errors with undefined symbols, invalid template arguments, error directives about _HAS_EXCEPTIONS == 0 not supported, etc. On one hand, this makes sense, the kernel environment is very different from usermode and the STL relies on exceptions, which the kernel doesn't have - duh stuff will break. On the other hand, if I am smart about using containers that don't allocate, I can compile a static library with C++ exceptions off, disable the /GS security and SDL checks, apply /NODEFAULTLIB, etc and then link this static library to my driver and everything works fantastic.
It is unfortunate that it seems these headers don't work. I'd very much like to use non-allocating features such as std::span, std::array, std::enable_if, std::remove_reference, and lots of other things from type_traits especially in my driver but I cannot!
I expect things like std::vector std::string and other containers with allocator requirements to never work, but I would expect these headers which are pure C++ to work just fine. And I can prove that as long as I can get them to compile in a static library that they really do execute just fine there! As a workaround for this I've had to do something very wild, where I compile my 'drivers' as free standing .DLLs then manual map them into the kernel, just so that I can use the C++ features I need easily. See:
C++ DLL with fancy header usages
C++ driver mapping dll into kernel
My question, why do these headers not work as I'd expect in a driver, but do work when I compile as a free standing DLL. And, will this situation ever be improved, at least for the core utility stuff like type_traits