It’s mostly for historical reasons. Some parts of the windows kernel were originally written in C, because 1983, over three decades ago, when Windows 1.0 was unleashed, C++ was barely released.
Now these C-libraries will stay there “forever”, because Microsoft made backward-compatibility a selling point and rewriting a bug-compatible version of the C-parts in C++ requires an awful lot of effort for no effective benefit.

As most people have pointed out, reasons are by far historical, but there is something else no one is mentioning and I believe it is the reason people still write C code for low-level.

C is a small language in the sense that the spec is (relatively) short. C++ is huge and that’s an understatement. This may not matter that much to the programmer (although I think it does), but it is extremely important if you want to do formal verification. Furthermore there are established tools for C code analysis, that could help prevent bugs, etc.

And this is very important in embedded software, where the cost of a bug that is deployed is extremely high, relative to the rest of the industry (compare Web, where you can apply a patch immediately to all users). Not to mention mission-critical software and medical stuff.

There have been attempts to displace C from its dominant place in low-level programming with languages that are even better at this, like BitC, but they haven’t been successful so far.

1. The C runtime is much smaller.
2. The translation of C++ into lower-level constructs is less transparent than in C. (See references and vtables, for two quick examples)
3. C usually has a stable ABI. C++ usually does not. This means that at the bare minimum, the system call interface should be C style. In addition, if you want any sort of dynamic modules, having a consistent ABI helps greatly.

The reasons aren’t technical. A little bit of assembly is unavoidable, but they aren’t forced to use the occasional C, they want to. My company uses its own proprietary kernel, written almost entirely in C++, but we don’t need to support a C interface to the kernel like most everyone else, because our embedded kernel is monolithically compiled with our C++ applications. When you have a C interface, it’s often easier to write the interface code in C, even though it’s possible to use extern "C" to write it in C++.

Even we have a smattering of C files, mostly due to third-party code. Third-party low-level code is almost always provided in C, because it’s much easier to incorporate C code into a C++ app than the other way around.

Kernel developers are often the kind of people, who feel happier, when it is immediately evident from the source, what the code actually does.

C++ has many more features, which hide what the code does more than plain C code hides it: overloads, virtual methods, templates, references, throws… C++ also has vastly more syntax you have to master in order to even understand the C++ code using it.

I think power of C++ is very powerful tools to create libraries and frameworks, which then make application development a snap. Very often C++ application developer would be totally lost in the template-filled innards of a library, even when he is very competent at creating applications using that library. And writing a C++ library right is a very challenging programming task, and only done in order to provide a great framework for the benefit of application developer. C++ libraries are not internally simple, they are (or can be…) just powerful yet simple from application programmers point of view.

But kernel API can not be a C++ API, it must be a language-agnostic API, so most of the nice things in C++ would not be directly usable at that interface. Furthermore, kernel is not really divided into “library” and “application” parts developed independently, with more effort logically going to one library, to make creation of a mass of applications easy.

Also, security and stability is more critical inside a kernel, and virtual methods are much more dynamic and therefore much harder to isolate and verify, than plain callbacks or other C-like mechanisms.

In short, while you could of course write any C program including a kernel as C++, most of the power of C++ is not well used in kernel. And many would argue, that programming tools should prevent you from doing things you should not do. C++ would not.

Bjarne Stroustrup, in an interview in July 1999:

None of these languages was radically different or dramatically
better than other contemporary languages. They were, however, good
enough and the beneficiaries of luck and social factors

C is a very low-level language, by its design. It’s one step away from assembler; knowing the chipset you’re targeting, you could, with a little knowledge, manually “compile” C into ASM. This kind of “close-to-the-metal” language is key for high levels of optimization (for performance, memory-efficiency, etc). However, because it’s this close to the metal, you don’t get much for free with this language; it is a procedural, non-object-oriented language, and thus to work with such constructs involves a lot of boilerplate code to create and consume multi-value constructs in memory.

C++ is “C one better”, adding a number of ease-of-use features such as dynamic memory allocation, built-in structure marshalling, a large library of predefined code, etc, at the expense of some efficiency losses (still much better than managed-runtime environments). For the average coder, the advantages far outweigh the disadvantages in areas of the codebase that don’t need anal-retentive control of memory allocation etc.

The combination of the two is a pretty traditional one; you use C to write the most performance-critical, memory-efficient areas of the codebase, which you can then work with in a more abstracted fashion via method calls from C++ code, which can be more elegantly organized and designed than the uber-performant, uber-oogly optimized C code.

It could be that with C you spend most of your time thinking about the problem at hand and how to code the solution. In C++ you end up thinking about C++ and its myriad of features, functions and obscure syntax.

Also in many C++ shops your code get monitored by the “fashion police” who are enthralled by the latest set of design patterns, or, the latest unintelligible pronouncements of the great god Stroustrup. Pretty code becomes more valued than working code, finding a use for the latest set of Boost templates is admired more than finding a working solution for the business.

My experience is that for all the clever features and OO purity of C++, coding in plain C gets the job done quicker and more effectively.

It’s possible that the C parts are not nicely portable to the C++ compiler that is used for the C++ parts. Maybe the C code is chummy with the C compiler in ways that break with the C++ compiler.

If you have a quality C++ compiler, there is almost no reason to mix C and C++ in a project. Almost.

The one reason would be that your project shares C code with other projects, the code does not compile as C++, and you don’t want to maintain a C++ fork of that that code.

I think you have it backwards — the extern "C" block ensures that the C calling conventions are used for all functions within the block. So you can call pure C functions from C++, not C++ functions from C. Regardless, I imagine that the reason people use both C and C++ is because a lot of low-level libraries are written using C, and it’s easier to use something that already exists (and is presumably debugged and optimized) than writing your own. OTOH, C++ offers a lot of nice high-level features that people would rather work with, so they use that for the rest.

There are various level of embedded platforms using C as programming language
( of course it is your freedom to use assembly language at any time )

For ‘Level’ I am talking about the Internal SRAM and ROM resource level for a system.

These platforms sometimes are resource constrained ( e.g. some 8051 platforms only have 128 bytes of User SRAM ).

It is meaningless to support dynamic memory allocation with such a small amount for RAM. (new/delete) or even malloc in C.

One of the main improvement from C to C++ is Object-oriented paradigm. C++ is suitable in software with larger memory footprint

but not in embedded firmware that have its size limitation up to 32KB. (e.g. in a 16-bit MCU plaform )

There is no need to have a C++ compiler which is generally more complicated than C compiler.
( at least SDK providers won’t bother to do this ).

In fact I can hardly find a C++ compiler over an 32-bit ARM7 platform.

It just doesn’t worth the complexity

In Some
8051(8 bit) : 1MB ROM, 128B RAM

TI MSP430(16 Bit) : 32KB ROM , 4KB RAM

ST Microelectronics ARM 32-bit Cortex™-M3 CPU Core ( STM32F103T4 ) :
16 or 32 Kbytes of Flash memory
6 or 10 Kbytes of SRAM

I see a couple of possible reasons:

• C is a little bit more efficient if compared to the C++ equivalent.
• Some libraries they use are written in C.
• They use some parts of Linux kernel, which is written in C.

Edited:
As it turns out, third argument is not true (see comments).

Because C is arguably a better language than C++. And because some of the code was written before C++ became popular and people haven’t had a reason to replace it.

And because C++ has lots of features that can break your code if you’re not careful when using it in a kernel.