> But if exceptions are not supported, then this seems to suggest that
exceptions are supported. You seem to have confirmed both “yes” and “no”
in the same email, so I remain confused as to what is true.
Let’s clear some internals - NT environment implements the support of structured exception handling (SEH), available by using __try{}__except{} construction as supported by the MS C compiler.
Briefly speaking the one part of SEH resides in the kernel: RtlRaiseException() spawns the SEH-exception (processor’s software exception) that is handled by the dispatcher placed at the idt trap, the dispatcher in turn uses the unwinding mechanics provided by RtlUnwind()/RtlUnwindEx(). Another part of SEH is provided by a compiler/linker/rtl-library toolset - these are the SEH-handlers and function’s stack frames unwind information.
The full SEH support is available for using in NT kernel by your drivers all the time, because of it is uses SEH-handler ‘__except_handler()’ placed in ‘ntoskrnl.lib’ or ‘ntdll.lib’ or ‘wdm.lib’ or somewhere else standardly linked to the driver and the MS C compiler generates unwind information by defualt.
But when you use the C++ exceptions the compiler generates the invokes to the compiler internally pre-declared entry points assumed to be implemented by the run-time library (these points are a kind of CxxFrameHandler and CxxThrowException). And the library implementation uses SEH facilities to implement the raising of exception and the stack unwinding.
As a summary: NT kernel provides SEH, C++ compiler provides all the necessary unwinding information and the RTL library uses both them for the handling C++ exceptions.
The use of 8-bit strings for exception messages in the STL is profoundly
offensive. There might be a worse way to do it, but I’m not sure I can
think of one.
C++ doesn’t force you to strictly use something you don’t want to. You can build the exeption architecture to be used in the driver on your own preferences.
So even if C++ exceptions are supported in
the kernel (and what happens if an exception occurs and no suitable
“catch” exists? BSOD?), the STL is not really well-matched to the needs
of “embedded” programming (which drivers strongly resemble).
If the driver allows the C++ exception out of its’ scope the BSOD is to occure unless someone executes your driver in __try{}__except(1){} handler, because it is propagated up the stack as the SEH exception with specific code.
And you are right, the STL in common case seems to be less suitable for using in the kernel being compared with facilities ddk/wdk provides. But in some cases it may be very convenient and useful as not all the drivers are used for high performance and minor resource using tasks.